We first published a version of this in 2016. Ten years and a lot of builds later, the argument holds up, so we’re restating it for the way we work now.
All software projects have some elements of risk. Even a straightforward port of a well-understood system to a newer platform turns up surprises that cost time and money. A custom build has more unknowns than that, and the software is usually critical: it runs orders, billing, dispatch, or the field. There’s no beta with a million users to shake the problems out. It has to work when it ships, and getting it wrong is expensive.
Roughly 70% of software and data projects fail or run over. What separates the ones that don’t is rarely the technology. It’s how the work is set up before anyone writes code, and who is holding the risk while it happens.
Who holds the risk is a choice
The engagement model you and your development partner agree to decides where the risk sits. Understand the options before you sign anything.
Fixed price. The firm commits to a scope and a number, and carries the risk of estimating wrong. That sounds ideal for you. In practice it depends on the scope being right on day one, and it rarely is. When the scope moves, and it always moves, you end up in change-order negotiations, or the firm quietly cuts quality to protect its margin.
Time and materials. You pay for hours. The firm carries no cost risk and you carry all of it. A consultant will happily accept T&M, because they get paid whenever they do something. It can be appropriate when requirements are well defined and stable, or when your purchasing department has rules about rates. It’s a poor fit for a build with real unknowns, because there is no natural stopping point.
Dedicated team. You retain a team for a period, and the scope is whatever they can get through. This is right for a product that will keep evolving for years and has an owner on your side directing it. It’s wrong for a company that needs one defined system built and then wants to get back to running the business.
Is one better than the other? It really depends on the situation. That’s why we don’t ask a client to pick a model from a menu on the first call. We decide it together after the Deep Dive, once we know what the work actually is.
Start with value, not with a quote
One thing we’ve learned across a hundred-plus builds: clients tend to have more ideas than money. That’s not a criticism. It’s the normal condition of a growing company. It’s also why the budget has to be anchored to value rather than to a wish list.
Before you ask what a system will cost, work out what it’s worth. Some of it is easy to put a number on:
- Hours of manual work removed each week
- Faster order-to-cash or quote-to-close
- Errors, rework, and write-offs eliminated
- Headcount you won’t have to add in order to grow
Some of it is real but harder to quantify up front: customer or partner satisfaction, employee turnover, the feature a competitor now offers and you don’t. These are ultimately quantifiable, even if they aren’t obvious at the start. Think them through anyway. The value of a project should dictate what you’re willing to spend on it, and a firm that doesn’t ask about value before quoting is estimating in the dark.
Fixed budget, controlled scope
Our default is what we’ve called fixed budget, scope controlled since the first version of this post. You set the budget based on the value the project holds for the business. We control the scope to fit inside it.
The second half is the hard part. Clients come to us with good ideas that would cost more than they want to spend. So we work through the scope carefully, looking for the version that solves the real problem and delivers the value, not the version that includes every feature anyone mentioned.
A common example: a client says they need an iPhone and Android app so customers can check order status. The right answer is often a mobile-friendly web interface instead. Same outcome for the customer, at a fraction of the cost, easier to maintain, and less risky to ship.
Fixed budget with controlled scope reduces risk on both sides:
- Tight scope control avoids the “boil the ocean” project that runs into complexity nobody foresaw.
- A fixed budget means you are not going to run wildly over.
- Spend is tracked against milestones, so a mismatch between what’s done and what’s been spent gets caught early instead of at the end.
- We put the hardest, riskiest pieces first, so the thing most likely to break the plan is found in week two rather than month five.
- You see working software early and often, which is the only honest progress report there is.
It also changes the relationship. When the firm isn’t billing by the hour, you don’t feel the need to micromanage the process to control cost, and the work gets more productive for everyone.
Start small and earn trust
The single best risk reducer is not committing to the whole project on day one.
Every new build we take on starts with a VDP Sprint: Validation, Design & Planning. It runs three to four weeks at a fixed fee. It opens with a two-day face-to-face workshop, continues with design sessions about twice a week, and ends with click-through mockups of the key screens, written requirements, a tech-stack recommendation, and a roadmap with the investment attached.
At the end of it you know what should be built, what it should cost, and what it’s like to work with us. You can take that plan to us or to anyone else. You get experience with the firm, the process, and the quality of the results before the large commitment, and we get a scope we can actually stand behind.
If the system already exists and the question is whether to fix, extend, or replace it, the equivalent first step is a System Evaluation: one to four weeks, fixed fee, and a plain-English read on what you have and what it needs.
Before you sign
Before you engage any software development team, ask how they think about risk and what they do to reduce it. Ask what happens when scope moves. Ask when you’ll first see working software. Ask whether they’ll decide the engagement model with you after understanding the work, or whether the answer is whatever they were going to say anyway.
If they try to push all of the risk on you then just walk away.
If you want a sense of the numbers before you talk to anyone, start with what custom software costs. When you’re ready, book a discovery call. It’s 30 minutes, and we’ll tell you honestly whether the project is a fit.