How to choose a developer after a bad experience
You've already paid for this once. Somewhere behind you is a half-built product, a developer who went quiet, or a bill that kept growing while the thing you actually asked for never quite arrived. Now you're looking again, and every green tick on every portfolio site reads a little hollow, because the last one had those too.
That wariness is doing its job. The mistake would be turning it into paralysis, or worse, into picking whoever seems least likely to disappear rather than whoever's actually right. A bad experience is useful precisely because it tells you what to check for this time — you just need to know which signals to trust.
Here's what changes: not the general advice everyone gives about "communication" and "portfolios", but the specific things that go wrong on a first product build, and how to catch them before you've signed anything.
It probably wasn't your idea that was the problem
Worth saying plainly, because it rarely gets said: a failed first build is usually not evidence the idea was bad or that you're difficult to work with. Most troubled projects go wrong for a handful of repeatable reasons, and none of them are about you.
The scope was never actually fixed — it grew a little at a time, every addition reasonable on its own, until "four weeks" quietly became four months. Nobody agreed what "finished" meant, so there was always another thing to tweak and never a moment to call it done. Or the pricing model rewarded the wrong thing — a day rate means every extra day is revenue for the person billing it, which is not a conspiracy so much as an incentive nobody named out loud.
Knowing which of those happened to you is the fastest way to spot it happening again.
What actually predicts trouble
Portfolios and glowing testimonials are table stakes — almost everyone has them, including the developer who let you down last time. What separates the ones worth trusting from the ones worth avoiding shows up earlier, in how they talk about the work before you've paid anything.
Signs it's heading the same way:
- They agree to everything in the first call — every feature, every "and could it also…" — without once saying no or asking what it would cost you elsewhere.
- The quote is a day rate with an estimated number of days, not a fixed price for a fixed thing.
- Nobody asks what "done" looks like, or what the one thing version one has to prove actually is.
- References exist but you're not given the option to actually speak to one.
- The contract, if there is one, doesn't say what happens if the scope changes — because everyone's assuming it won't.
Signs it's a different kind of developer entirely:
- They push back on something in the first conversation — tell you a feature isn't needed for a first version, or that your timeline doesn't match your scope.
- The quote is fixed, tied to a specific, written-down list of what you'll have at the end.
- They ask what you're trying to prove with version one, before they ask what you want it to look like.
- You can actually message a past client, not just read a curated quote.
- There's a plain answer, in writing, for what happens if you want to add something mid-build.
None of these individually is proof. Together, across one conversation, they're close to it.
Fixed scope beats a day rate for a first build
This is the one that matters most and gets argued about least. A day rate isn't dishonest — it genuinely suits work where nobody yet knows how long something will take, which describes a lot of software. But a first version of a product is different: the whole point is that it's small enough to define completely before anyone starts.
If it can be defined completely, it can be quoted as a fixed price for a fixed list of things — and that single shift changes who carries the risk. Under a day rate, every unknown that turns up costs you more. Under a fixed scope, every unknown that turns up is the developer's problem to absorb, because they set the price against a list they agreed to before they started. That's not a technicality. It's the difference between a developer who's incentivised to finish and one who's incentivised to keep going.
The trade-off is real: fixed scope only works if the scope is actually fixed, in writing, before work starts — which means the discovery conversation matters more than the build itself. A developer who skips straight to "sure, let's start" without pinning down what "started" and "finished" mean is setting you up for the same drift that got you here.
The questions worth asking before you sign anything
- What's the one thing this version has to prove? If they can't answer in a sentence, they haven't scoped it yet — they're planning to work it out as they go, on your clock.
- What exactly do I have at the end, and what happens if I want to add something after we start?
- Is this a fixed price for that list, or an estimate of hours?
- Can I speak to someone you've built for recently — not read about, actually speak to?
- What does a normal week of contact with you look like while this is being built?
A developer worth hiring answers all five without flinching, usually before you've finished asking.
Most troubled build projects were never short of talent — they were short of a definition of done. For a first version of anything, every incentive should point at "finished and in front of real users". If nobody can say in one sentence what done looks like, the project hasn't started yet; it's just spending. That's the pattern behind almost every version of this story, whatever the last developer's actual skill level was — and it's exactly what a real fixed-scope quote forces into the open before anyone's paid for a single line of code.
It's the pattern one of our own clients pointed at without naming it. Their Woodville project review says it plainly: "after working with previous developers who always seem to prove problematic," what they got instead was someone with "the right attitude" who saw it through "from start to finish." That's not a compliment about charm — it's what a properly scoped, properly finished project looks like from the client's side of the table.
Where that leaves you
You don't need a bigger developer this time, or a cheaper one, or one with a longer portfolio. You need one who'll tell you what "done" means before you've paid for a single day of work, and price against that instead of against the clock. Ask the five questions above in your very next call and you'll know within the hour which kind you're talking to.
If you'd rather skip the vetting and start with a fixed scope, fixed quote from the outset, that's what our MVP development work is built around — one idea, one build, four weeks, with "done" defined before we start rather than discovered along the way.
The same instinct that catches a vague developer quote is worth turning on the rest of the business too. We've written before about what actually separates a well-scoped project from a drifting one in the context of automation — the pattern is the same whether the thing being built is a product or a process: nothing gets finished until someone writes down what finished means.
← All posts