There are plenty of good reasons to build custom software. You’ve outgrown the platform you run on. Your competitors are doing something you can’t. Your people spend half their day working around the system instead of in it. Customers or partners need something you can’t give them.
There are also plenty of ways for the project to go down the rat hole. Everyone has heard of the software project from hell, and most of them started with the same enthusiasm yours has now. We wrote the first version of this checklist in 2016. Ten years and a hundred-plus builds later, the questions haven’t changed. What’s changed is that we now run a structured process to answer them before anyone writes code. This post is the list. The process is at the end.
Understand the value
What is the big picture?
It sounds obvious, but the overall goal gets lost surprisingly often, buried under technology choices, competitive pressure, and personal agendas. A retailer decides it needs a mobile app that tells customers about in-store specials when they walk in. Maybe it does, especially if a competitor just launched one. But the better question is “how do we best tell customers about in-store specials as they walk in?” The first is a solution that may or may not address a problem. The second is a problem, framed. The answer might be the app. It might also be a sign, a text message, or nothing at all.
Start with the problem. If you can’t state it in one sentence without naming a technology, you’re not ready.
Who is it for, and how will they be better off?
Employees, customers, suppliers, partners, a channel. Name the group. Then describe, specifically, how their day changes when the system exists. If you can’t picture a person and a task, the value is theoretical.
How will you measure it?
Some projects have a clean return: hours saved, errors eliminated, revenue that couldn’t be booked before. Some don’t, and that’s fine as long as you say so up front. A system that puts company procedures in front of every employee on any device may show no productivity gain in the first quarter and a real one in the fourth. Long-term value is a legitimate reason to build. Vague value isn’t. Pick the one number you’ll look at in twelve months and write it down before the project starts, not after.
Know the risks
Is the organization ready for the change?
If the system changes how work gets done, the people doing the work have to be ready for it. That includes customers and partners if they touch it. A technically perfect system that nobody adopts is a failed project.
What happens if it doesn’t work?
A new system in a support center with a few glitches can take down the business’s ability to serve customers. Is there a fallback? Can you run the old way for a week? Has anyone planned to test at real scale before cutover? These need answering before launch, not during it.
Is the deadline real or emotional?
An executive announces a date. Sometimes that’s a useful rallying cry for a slow organization. Sometimes it’s a number that was said out loud and now can’t be taken back. A deadline that isn’t backed by a realistic plan and enough resources doesn’t make the project faster. It makes it fail on schedule.
Could a competitor leapfrog you while you build?
Yes. You can’t prevent it, but you should know how you’d respond, and that answer should shape what you build first.
Do you believe the estimate?
Estimating what you know how to do is often hard to get right. Estimating what you don’t know how to do is really hard. And estimating what you don’t know that you don’t know is where most of the trouble lives. You can’t have every answer before you start, but you can build a plan with room for the unknowns, and you can sequence the work so the riskiest parts get proven first. We do the hardest things first for exactly this reason. A plan that puts the easy screens up front and the scary integration last is a plan to run out of money at the worst moment.
Fund it responsibly
Do you have a realistic budget, and does it survive the budget cycle?
Custom software is expensive and most projects run over. A build that spans two budget years needs to survive the second year’s planning meeting, which means someone who wasn’t in the room at kickoff has to still believe in it.
Our answer to overruns is structural, not heroic. We work to a fixed budget with controlled scope. That means the budget is agreed before the build, and when new ideas show up mid-project (they always do) they’re traded against existing scope rather than added to the bill. If you want to understand what drives the number, what custom software costs walks through it without the sales pitch.
Confirm the commitment
How committed is leadership, really?
The project needs a sponsor senior enough to commit the money and the people, and to keep committing them when the project hits its inevitable hard month. The test is simple: can they explain the value of the project in their own words? If they can’t articulate it, they won’t defend it, and if it needs more support later the answer will be no.
The second test is whether there’s a single person with the authority to make decisions weekly. Not a committee. One person. Projects without one stall on the first real trade-off.
Signs you’re not ready yet
- The problem statement includes a product name
- Nobody has talked to the people who’ll use the system
- The budget is a hope, not a line item
- The sponsor is enthusiastic but couldn’t pass the “explain it” test
- The deadline came before the plan
None of these are fatal. They’re just work to do before the build, and it’s much cheaper to do it now.
The first step
If you can answer most of the questions above and still want to build, you’re ready for a VDP Sprint: Validation, Design & Planning. It’s a three-to-four-week, fixed-fee engagement that starts 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, functional and non-functional requirements, a tech-stack recommendation, and a roadmap with the investment. It answers every question on this list with evidence instead of opinion. Some VDP Sprints end with a recommendation not to build, and we count those as successes.
If you can’t answer most of them, start earlier. Read Is your company outgrowing its systems?, ask your employees the ten questions in it, and come back when the problem is clear. Then we’ll talk about a new build.