← Back to the blog

How to hire custom development without it spiraling out of control

Almost every custom project I've seen go wrong didn't fail because of a bad technology choice. It failed over something decided badly in the first week that nobody looked at again until fixing it had already gotten expensive.

This is the guide I'd give anyone before their first meeting with a developer or a studio, whichever side of the table they're on.

Before talking price, talk about the question

Every project worth doing has a business question behind it, not a feature list. "I want an app for my gym" isn't a question. "Can I stop chasing my members for payment?" is.

If the first meeting only covers features — login, admin panel, notifications — and nobody asks what the underlying problem is, that's a red flag. A developer who understands the problem will propose fewer features, not more, because they'll know which ones matter.

You can read more about how that question turns into scope in from idea to MVP.

The three questions to ask in the first meeting

What is explicitly left out of this first version? If the answer is "everything's in", the budget and timeline you're given will be fiction. Real scope always comes with a list of exclusions as clear as its list of inclusions.

How is the work delivered, in what cycles? The right answer describes short, reviewable deliveries — two weeks, not two months. If the only delivery is at the end, you have no way to correct course in time, and by the time you see the result, the whole budget is spent.

What happens if halfway through I realize I need something different? Every project changes along the way. The question isn't whether it will happen, it's how it gets handled when it does. If the answer is "that breaks the contract", you're about to sign something rigid for a process that isn't.

How to structure payment without giving up control

Never 100% upfront. No exceptions. Full upfront payment removes any incentive on the other side to deliver on time or well.

Never 100% on final delivery either. This pushes the developer to quietly stretch the work for months without you seeing anything, because all the payment is tied to the end.

What works is paying against verifiable milestones. A reasonable deposit to start (30-40% is common), and the rest tied to concrete deliverables you can see working, not to calendar dates. "I pay when the billing system processes a real transaction" is a milestone. "I pay on the 15th of every month" isn't.

The red flags I've learned to recognize

A quote nobody can explain how it was calculated. A serious quote can be broken down by feature or by stage. If the answer is a number with no breakdown, that number probably has too much padding in it, or not enough.

Nobody asks about your real users. If at no point in the conversation does anyone ask who's going to use the product and what that person knows how to do, the product they build will be designed for the developer, not for whoever uses it every day.

The answer to everything is "yes, we can do that". A developer who never says no, or never shows you a trade-off, isn't protecting you from anything. Everything has a cost, and someone who doesn't show it to you will charge you for it later, in time or in quality.

The timeline doesn't move even when scope does. If you add something halfway through and the original timeline stays intact, something else is being cut without you being told — usually quality or testing.

What is a good sign

Someone who asks "why do you want this?" before asking "how do you want it?". Someone who tells you a feature you requested isn't necessary for the first version, and explains why. Someone who shows you working software every two weeks, even if it's still missing things.

None of those signs have anything to do with the tech stack. They have to do with whether the person on the other side is thinking about your business or their next sprint.

A guide, not a guarantee

None of this removes risk entirely — no software project is free of surprises. But it reduces the most common risk, which isn't technical: it's discovering halfway through that nobody had the same project in mind.

If you're evaluating a custom development and want the first conversation to be about these questions, get in touch.