If you're a founder or operator about to hire someone to build software, the biggest risk isn't the technology choice. It's the delivery model you agree to before a single line of code gets written. A lot of traditional agencies still sell the same shape of engagement: a long discovery phase, a fixed quote covering the whole project, and a launch date sitting comfortably six to twelve months out. You pay a deposit, you wait, and mostly you hope.
We're not saying every agency operating this way is doing something wrong on purpose. Some of it is just how the industry organized itself a decade ago, before weekly shipping became normal practice elsewhere in software. But the model has real costs for you as the buyer, even when everyone involved has good intentions.
What tends to go wrong with this shape of engagement
- You see decks, mockups, and "definitely almost final" wireframes for weeks — sometimes months — before any production software exists that a real user could touch.
- Scope gets locked early, back when everyone knew the least about what the product actually needed. Every change after that point becomes a formal change order, complete with its own negotiation.
- Quality work — tests, CI/CD, real documentation — quietly becomes optional, or shows up later as a billed extra you didn't budget for.
- You genuinely cannot tell whether the team is stuck, coasting, or crushing it, because there's nothing running that you can look at yourself. You just get told things are "on track."
That last one is the quiet killer. Status updates are words. A working demo is evidence. Most agencies give you the first and call it transparency.
We've talked to founders three months into an engagement like this who genuinely couldn't say whether the project was on track — not because anyone lied to them, but because "on track" had never been defined against anything visible. That's not a communication failure you fix with better meeting notes. It's a structural one, baked into the model before the contract was even signed.
What a better partner actually looks like
Ask for weekly working deliverables — something you can click through, poke at, and reject if it's wrong. Not a status call where someone describes progress you can't verify yourself. Require open, continuous access to the repository from day one, not "we'll grant access at project close." And when requirements are still evolving — which, be honest, they almost always are — prefer flexible sprint pricing over one inflated fixed number meant to cover every possible surprise.
If you can't see progress every week, you're not managing a product. You're funding a promise, and hoping the promise holds.
There's a version of this that sounds harsh but isn't meant to be: agencies that need six months of "discovery" before showing anything real are often protecting themselves from uncertainty they haven't resolved, and passing the cost of that uncertainty straight to you in the form of a bigger number and a longer wait.
Why the old model still sells, even though it's slower
It's worth understanding why the six-to-twelve-month shape persists, because it's not pure incompetence keeping it alive. A big fixed number, delivered after months of discovery, is genuinely comforting to present internally — it's one line item, easy to explain to a board or a finance team, and it feels like risk has been transferred entirely to the vendor. In reality, the risk didn't go anywhere. It just got hidden behind a curtain until the reveal date, and you find out how much of it was real when the reveal happens.
There are edge cases where a longer, more structured engagement genuinely makes sense — heavily regulated industries with compliance sign-off gates, or a system with so many existing integrations that a proper technical audit has to happen before anyone can responsibly commit to a sprint plan. Even then, the audit itself should be a short, visible, time-boxed piece of work — not a black box that happens to also take six months.
What weekly delivery actually costs you, in trade
To be fair to the traditional model, sprint-based delivery isn't free of trade-offs either. You'll need to show up weekly, review real output, and make decisions faster than a "we'll get back to you next month" cadence allows. Some buyers find that uncomfortable at first — it's more visible, which means there's nowhere to hide if your own priorities are unclear. We'd argue that discomfort is the point. It surfaces problems in week two instead of month eight, when they're still cheap to fix.
Questions worth asking before you hire anyone
- What will I actually be able to use, myself, after the first sprint — not describe, use?
- Who owns the code, the credentials, and the cloud accounts, starting when?
- Are automated tests and a CI pipeline included by default, or are those a separate conversation?
- How do we change priorities midstream without restarting the entire contract and renegotiating from zero?
If the answers come back specific and fast, that's a good sign about how the actual engagement will go. If they come back vague or deflected to "we'll cover that in the kickoff," that vagueness is itself useful information.
ConaiSoft works in short sprints with senior architecture from day one, visible weekly progress, and full code ownership that's yours from the start rather than handed over at the end — so you can validate what you're building faster, without the multi-month agency lock-in that made this whole conversation necessary in the first place.