The most common way a first custom build goes wrong is not technical. It is that the scope was set by listing everything anyone wanted, and the result was a project too large to finish while anyone still cared.
What follows is the method we use to cut a brief down to something that ships, without cutting the part that made it worth building.
Start from the question you cannot answer today
Not from features. Features are a solution, and starting there means committing to an answer before stating the problem.
Instead, write down the questions that currently take too long: what is outstanding right now, who is over-allocated next month, which jobs are over budget, how many appointments did we lose last week. Pick the one that costs you the most to not know. That question is your first requirement, and everything in version one should exist to answer it.
Four modules, and why four
A module is a thing with its own records that people create, edit and close. Projects. Invoices. Patients. Matters. Four is not a magic number, but it is a useful ceiling for a first build, for two reasons.
The first is that complexity grows through connections, not counts. Four modules have six possible relationships; six modules have fifteen. The build does not get half again as big, it roughly doubles.
The second is that four is usually enough to answer one real question end to end, which is what makes a tool worth opening. Three often leaves a gap that sends people back to the spreadsheet.
A module is not a chart
Worth being firm about this, because it is where scope quietly inflates. A chart displays data that already exists somewhere. A module is where the data comes from: screens to create a record, edit it, move it through states, and close it.
If your brief is mostly charts, you may not need a build at all. You may need a reporting layer on data you already have, which is a much smaller job. If your brief is mostly modules, the charts will come nearly free once the data exists in one place.
What to leave out of version one
Leaving things out is the actual skill. These four are the most common candidates, and cutting any of them meaningfully reduces both cost and time to launch.
- Roles and permissions. If your team can all see everything for now, defer it. This is frequently the single largest saving available.
- A native mobile app. A responsive dashboard works on a phone browser. A native app is a separate project with its own release process.
- A reporting suite. Build the two or three numbers you actually check. General-purpose report builders are enormous and mostly unused.
- Integrations you do not need yet. Each one is real work. Two well-chosen ones beat five speculative ones.
The two integrations usually worth having on day one
Whatever holds your money, and whatever your team already lives in. In practice that means an accounting or payments system, so financial data does not get retyped, and a notification channel like email or a chat tool, so the dashboard can tell people something happened without them having to check it.
Notifications are consistently underrated. A tool people have to remember to open gets forgotten; a tool that tells them when something needs attention gets used.
Four tests for whether your scope is too big
- Can you describe it in two sentences? If it takes a paragraph, it is two projects.
- Does every module serve the question you started from? Anything that does not is version two.
- Would you use it if it launched with only these features? If not, something essential is missing. If yes, stop adding.
- Can you name who opens it every morning? A tool with no daily user is a report, and reports are cheaper.
A worked example
A small architecture studio wants "an operations system." Everything is on the list: projects, timesheets, invoicing, CRM, document management, resourcing, expenses.
The question they actually cannot answer is whether a project is over on fee before it is too late to act. Working backwards from it: they need projects with contracted fee, time logged against project and phase, resourcing for who is on what, and an approvals queue so the things that change a fee stop getting lost in email.
That is four modules and answers the question end to end. Document management and expenses are real needs, and they are version two. This is close to what we actually built for a six-person studio, and the discipline of leaving things out is why it shipped.
If you are earlier than this and still deciding whether to build, start with the build-versus-buy question. If you want to understand what your choices here do to a quote, the cost drivers map onto them almost directly.