How small should the first version of a custom tool be?
Small enough to ship, but complete enough that someone can stop doing the old thing. That is the real test. Half a workflow is worse than none, because it forces double entry and guarantees abandonment. Pick one group of users and one loop from start to finish, then build the riskiest integration first rather than last so the unknowns surface while there is still room to change course.
The wrong way to cut scope
Most teams cut scope horizontally: version one gets a little of everything. A partial intake form, a partial dashboard, a partial mobile view. The result is a tool where no one can complete their job, so everyone keeps the spreadsheet open next to it. Now you have two systems and one of them is wrong.
Cut vertically instead. One user group, one process, all the way through, including the unglamorous end — the save, the notification, the record that the next person needs. If dispatch can run a whole day inside it, you have something. If they can run half a day, you have nothing.
Build the scary part first
The natural instinct is to start with screens, because screens are visible and satisfying. That is backwards. Start with whatever you are least sure about: the API that might not expose the field you need, the data quality in the legacy system, the volume assumption.
Discovering in week two that a vendor's API does not return the job cost you were planning to report on is a scoping conversation. Discovering it in month four is a rebuild. This is the main reason a serious integration effort begins with a read-only probe of the actual data rather than a design mockup.
A first version that earns the second
- One complete loop. A record can be created, worked, finished, and found again later.
- One real audience. Not "the company" — a named set of people whose day it changes.
- Real data. Loaded from the actual systems, not seeded samples, so data problems appear now.
- An exit. Export, or an API, so nothing is trapped if you change direction.
- Something to watch. Basic logging and an alert when the thing stops, because silent failure is how pilots die quietly.
The trap of read-only phase one
A very common first phase is "just show us the data" — a reporting view with no actions. It feels low risk. It is also the version most likely to be looked at twice and then ignored, because it does not change anyone's work.
If reporting really is the goal, make it arrive where people already are rather than in a new place they must remember to visit. A number that shows up in the morning routine gets used; a dashboard someone has to log into does not. That distinction drives how we build reporting tools and why alerting usually beats browsing.
Topics: MVP · phasing · adoption · risk
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.