How to choose a development partner

Why the choice looks different now

Choosing a development partner is not the same decision it was a few years ago. Three things have changed the picture:

AI has made competence more unevenly distributed. Experienced developers using AI effectively deliver far more than before. Inexperienced developers without good routines produce code that looks fine but does not hold up over time. You need to assess both the people and how they work.

Platforms change faster. Apple, Google and Microsoft change SDKs and policies more frequently than before. Older apps often require significant upgrades to keep working. Operations and further development can no longer be deferred.

Regulatory pressure is increasing. GDPR was only the beginning. Privacy, security and industry-specific requirements, particularly in healthcare and finance, mean that compliance work is now a large part of a development project, not a small appendix.

In sum: the choice of partner matters more today than before. A poor choice costs not just money, but time and market position.

The four options

There are four real options when you need to build something complex:

1. Freelancer

One person, low hourly rate, flexible start. Works best when the assignment is short, clearly defined, and requires only one discipline.

The risk is well-known: one bottleneck, no redundancy, vulnerable to illness or career decisions. For an MVP where you have strong internal technical leadership, a freelancer can be right. For a product that needs to live for three or more years, it quickly becomes a challenge.

2. Large consultancy

Many resources, broad competence, established processes. Works best when you need 50 or more developers in parallel on a short time horizon.

The biggest problem we see clients disappointed by: the sales team is not the delivery team. You meet experienced people in the sales phase and get junior staff on the project. The overhead in the hourly rate is often 40 to 60 per cent compared with a partner; you pay for intermediaries, offices in several cities, and a sales organisation.

3. Development partner

A smaller team (typically 8 to 30 people) that takes genuine ownership of the project over time. The same people from the sales meeting through delivery, operations and further development. Fixed price after a pre-project. You own everything from day one.

Works best when you are building something that needs to live for three or more years, requires several disciplines, and you want to avoid building an internal technical department.

4. In-house team

Full control, builds internal competence, can deliver the lowest long-term cost at high volume. Works best when you have 20 or more developers' worth of work, and a clear technological vision.

What people underestimate: 12 or more months to build up, continuous recruitment, sick leave, turnover, and a leader with a technical background who can maintain direction. For companies under 100 employees, it is rarely right.

What a development partner is, in practice

The term "partner" is overused; every supplier calls themselves one. Here is how we distinguish a partner from an agency in practice:

A partner has the same team throughout the relationship. Not a sales team, a delivery team, and an operations team. The people who deliver are the same ones who will answer your call two years later when something needs changing.

A partner makes you independent, not dependent. You own the source code, databases, infrastructure and documentation from day one. Any competent developer should be able to take over if you want to switch. If the contract makes it difficult to leave, it is not a partner.

A partner takes genuine financial risk. A fixed price means the partner has skin in the game. Time-and-materials billing without a fixed-price option shifts all risk to you.

A partner says no. If you propose something that does not make sense, because it is too complex, because a ready-made solution already exists, or because it does not match the business's needs, a good partner speaks up. A supplier says yes and invoices.

Twelve questions you must ask

When we have sat on the other side of the table helping clients evaluate suppliers, these are the questions that have decided it.

About the team:

1. Who specifically works on our project? Can I see their CVs?
2. Will the same people be involved from the first meeting through to ongoing operations?
3. What is a typical sick-leave or turnover rate for you?

About scope and price: 4. What is the difference between hourly billing and fixed price in your model? 5. Can I see a fixed-price proposal from a previous project (anonymised)? 6. How do you handle changes along the way? Show me an example.

About ownership: 7. Do we own the source code, infrastructure and data from day one? 8. What happens if we want to stop after six months? Can someone else take over without friction?

About references: 9. Can I call three reference clients, not the ones you suggest, but ones I choose from the list? 10. Show me a project where something went wrong and how you handled it.

About the long term: 11. What is your longest client relationship? Why has it lasted? 12. What is the shortest client relationship that was ended by the client, and why?

If you get unclear, defensive, or evasive answers on three or more of these, be careful.

Red flags

After many conversations with clients who have chosen the wrong supplier, these patterns recur:

Sales teams who do not know the technology. If you do not get a genuine technical answer in the sales conversation, but keep hearing "we have a team that can do that", it is because the sales team is not technical.

Contracts that lock you in. Long tie-in periods, clauses stating they own the data model, or code hosted on their infrastructure without a clear exit strategy; all of these are red flags.

Vague answers on fixed price. "It is too early to say" on an MVP where the scope is obvious, or estimates that are three times lower than every other quote you have received, means someone is taking a risk that will later become yours.

No willingness to say no. If everything you propose is met with "yes, we can do that", it is often because they hope to sort it out later once the contract is signed.

Rotating resources. "We have a core team and bring in specialists along the way" is often code for: you will get junior staff as the main workforce, and nobody owns the whole picture.

The new question: the AI angle

The most important new question you must ask is: how does the partner use AI?

This is not a hype question. It is a productivity and quality question.

Experienced teams using AI tools such as Claude Code, Cursor and context-aware assistants deliver substantially more per month than they did previously. For you as a client that means two things:

• A small, experienced team can now deliver what previously required a large team.
• A partner who has not integrated AI into their workflow is billing for work that no longer requires as many hours.

Ask: which AI tools do you use daily? How do you manage quality and security around AI-generated code? Which specific projects have you launched in the past year that were built with significant AI assistance?

If you get vague answers, they are probably billing on an old hourly model in a changed landscape.

Pre-project: the only insurance that works

The biggest difference we see between projects that succeed and those that do not is whether a genuine pre-project was done.

A pre-project is one to two weeks of paid work where the partner:

• Maps users, processes and goals
• Creates wireframes or a prototype
• Identifies integrations and dependencies
• Assesses risk (technical, regulatory, organisational)
• Sets a realistic scope
• Provides a fixed price you can trust

A pre-project typically costs 50,000 to 150,000 NOK. You own the result, even if you choose a different supplier to proceed.

If a potential partner is unwilling to do a pre-project, or wants to jump straight to "we start next week", that is a red flag. It means they either lack a methodology for setting scope, or they hope to resolve it along the way with hourly billing.

The right question to ask yourself

When you have spoken with three or four potential partners, the real question is not "who is cheapest" or "who seems most professional". It is:

"Who can I see myself sitting in a meeting with three years from now?"

That encompasses everything: chemistry, trust, ability to hold scope, willingness to speak up, and whether they will still be there when something goes wrong. That is not a question you can answer from a proposal; it is a gut-feeling question after a couple of real conversations.

If you have doubts, ask for a paid two-week trial. A genuine partner will say yes.

How STUDIO X works as a development partner

To be concrete, this is how it works to be a client with us:

• You meet the team in the first conversation. The same people deliver.
• We carry out a pre-project over one to two weeks, and give a fixed price you can trust.
• You own source code, databases, infrastructure and documentation from day one.
• Sprint delivery every two weeks. Demo and status report every time.
• After launch: a monthly agreement for operations and further development with three months' notice. Same team.
• We speak up when something does not make sense, even when it means a shorter invoice for us.

Want to know more? Read about how we work as a development partner, what we offer, or send us a short note about the project you are considering.

We reply personally, within a short time.