Build, buy or configure: how to decide, and what goes in version 1
Most teams pick the tool before they define the problem. A short decision path, and how to scope a first release that ships.
- A spreadsheet that works is a legitimate answer.
- Buy when your process is standard. Build when it is your edge.
- Version 1 needs a written out-of-scope list as much as an in-scope list.
- Anything not on either list is a change request.
Quick answer
Start with the problem, not the tool. Configure what you already own if it nearly fits. Buy SaaS if the process is standard. Build only when the process is your edge, or no tool fits. Then scope version 1 tightly: write down what is in, what is out and why, and treat everything new as a change request.
The decision path
- Define the problem in one sentence, with who has it and how often.
- Can something you already own do it? A well-built workbook, a tool you pay for. If it nearly fits, configure it.
- Is the process standard? Payroll, invoicing, email. Buy.
- Is the process your edge, or does no tool fit? Then build, and scope small.
For a coaching institute we built a 16-sheet Excel operations system, covering syllabus tracking, attendance, timetables and test records. A custom platform would have cost more than the problem was worth, and a stage-1 system solved it. We have not measured hours saved. Details: build custom software or buy SaaS.
Scoping version 1
The seven parts of a first-release scope, in short: the problem, the users and their five daily tasks, the in-scope list, the out-of-scope list with reasons, the floor of non-negotiables such as account deletion in an iOS app, the rule for change requests, and the status labels you will use.
For a clinic-queue platform the first release was scoped to a 30-day MVP by a written feature map. Payments and WhatsApp were out. Anything new was treated as a change request. Full detail: what should go in version 1.
If you already know you need a custom system and have a clear spec, skip the decision path and read the vendor chapter. And a small scope doesn’t fix an unclear problem.
Next chapter: Choosing and vetting a vendor.
More by GarunaCDX
Keep going with the next handbook.
Chapter-by-chapter guides from the engineers who build these systems for clients.
