Choosing a development partner is one of the few early decisions that is genuinely hard to reverse. You cannot inspect code quality from a pitch deck, and by the time architecture problems surface you have usually paid for most of the build.
This is how we would evaluate a partner if we were the ones hiring, including the questions that separate teams who build products from teams who write code to spec.
- The cheapest quote is rarely the cheapest project. Rework and rebuilds are where the money actually goes.
- A partner who agrees with everything is not being accommodating. They are not engaging with the problem.
- Ask about failures, not just wins. How a team handled something going wrong tells you more than any portfolio.
- Architecture decisions made in month one determine what is affordable in year two.
- Launch is the midpoint of the relationship, not the end. Agree what happens after it before you sign.
Section 01
Why this decision goes wrong so often
Founders are asked to judge technical capability without technical background, under time pressure, from teams who are all presenting their best work. It is an information problem, and the usual response is to fall back on the two things that are easy to compare: price and promises.
Both are poor signals. A low quote often means scope has been understood narrowly, or that the plan is to win the contract and negotiate later. An enthusiastic yes to every requirement usually means nobody has thought hard enough about the requirements to have a reservation.
Section 02
Technical expertise and evidence of it
Portfolios show what shipped. They do not show what it cost to get there or whether it still works. Push past the screenshots.
- Ask for a project similar in complexity to yours and have them walk you through the architecture and why they chose it.
- Ask what went wrong on it and how they handled it. A team with no failure stories is either inexperienced or not being candid.
- Ask who specifically will work on your project, and whether those are the same people who built the work in the portfolio.
- Speak to a past client directly, and ask about communication and post launch support rather than the finished product.
- Where possible, have an independent engineer review a code sample. An hour of that is cheap insurance.
Section 03
Communication and process transparency
Troubled projects tend to have a communication failure before they have a technical one. Problems exist for weeks before anyone tells the client, because the process has no natural moment to raise them.
What you want is a rhythm you can rely on and a team that raises risk early, when it is still cheap to respond to.
- A weekly update with working software, not a status document describing progress.
- Access to the same board the team works from, so you are not dependent on a summary.
- Technical trade offs explained in plain language, with the cost of each option stated.
- Bad news delivered early. A delay flagged in week three is a scheduling problem. The same delay flagged in week eleven is a crisis.
A partner who tells you what you do not want to hear in month one is the one who will still be worth having in month twelve.
Section 04
Design that is part of the build, not decoration on it
Plenty of development shops treat design as an input they receive rather than a discipline they practise. That works if you already have a strong design partner. If you do not, you will get an app that implements your wireframes faithfully and converts badly.
- Check whether designers are involved from discovery or only handed requirements at the end.
- Look at their apps on a real device. Polish shows up in transitions, empty states and error handling, not in marketing screenshots.
- Ask how they validate a design. If the answer is that the client approved it, there is no user in the loop.
- Ask what they would change about a design you show them, and whether the reasoning is about outcomes or taste.
Section 05
Architecture and whether it will still fit in two years
Early architecture decisions are cheap to make and expensive to unwind. A team optimising purely for the fastest possible version one can leave you with a product where every subsequent feature costs more than the last.
You do not need to evaluate the technical detail yourself. You need to hear whether the team has thought about it and can explain the trade offs they took.
- Ask what breaks first if usage grows by a factor of fifty, and what it would cost to fix.
- Ask how they structure code so a new developer can be productive without them.
- Ask what is being deliberately deferred in version one, and whether deferring it creates a rebuild later.
- Ask about testing. A team with no automated tests is quietly moving cost into your maintenance budget.
- Ask who owns the repositories, accounts and infrastructure. The answer should be you, from day one.
Section 06
What happens after launch
Apps are not projects that finish. Operating systems update twice a year, dependencies need patching, certificates expire and users report bugs from devices you never tested. If none of that is in the agreement, it will become an emergency conversation at the worst moment.
- Agree a support arrangement in writing, including response times for critical issues.
- Confirm who handles OS releases and store policy changes, which arrive on someone else's schedule.
- Establish how new features are scoped and priced once the initial build is done.
- Make sure handover documentation exists, so switching partners is a decision rather than a catastrophe.
Section 07
Red flags worth walking away from
Some signals are reliable enough that we would treat them as disqualifying regardless of how good the rest of the pitch looks.
- A fixed quote given without a discovery conversation. Nobody can price what they have not scoped.
- Agreement with every requirement, including the contradictory ones.
- Unwillingness to name the people who will do the work, or a sales team you never see again after signing.
- Any reluctance to give you ownership of the code, accounts or infrastructure.
- Timelines that assume nothing goes wrong. Every real project has slack in it somewhere, and a plan without any is a plan that will slip.
Section 08
How we approach the relationship
For transparency, here is our own answer to the questions above, so you can hold us to the same standard.
- Weekly updates with working builds, and direct access to the engineers rather than an account manager in between.
- Flutter specialists, with production work across fintech, marketplace, legal, auctions and point of sale products.
- Scope pushback as part of the service. We will tell you which features we think are not worth building yet.
- Code, repositories and infrastructure in your ownership from the first commit.
- Ongoing maintenance and iteration after launch, priced up front rather than negotiated under pressure.
Frequently asked questions
Should we hire an agency, freelancers, or build an in house team?
For a first product an agency or a small specialist team is usually fastest, because you get design, engineering and delivery without recruiting for each. Freelancers work well for a bounded piece of work with clear specification, less well for an entire product. In house makes sense once the product is validated and the roadmap justifies permanent capacity.
How much should a first mobile app cost?
It depends far more on scope than on rates, which is why quotes across teams vary so widely. A focused MVP with one core workflow sits in a very different band to a multi role product with payments and integrations. The useful comparison is not the number but what each team has assumed is included.
Is offshore development a false economy?
Not inherently. Location correlates with rate, not with quality. What matters is overlap in working hours, communication discipline and whether the team engages with your product decisions. Poor outcomes usually trace back to those factors rather than to geography.
What should be in the contract?
Scope with explicit exclusions, a payment schedule tied to deliverables, code and infrastructure ownership assigned to you, a defined change request process, and post launch support terms including response times. Any of those left informal will be the one you argue about later.
