How to scope your first internal tool
The single biggest reason internal tools fail isn't engineering , it's a vague brief. Here's the scoping process we use on every PROVENIQ° engagement.
Most teams brief an internal tool the way they'd brief a website: a feature list. Six weeks later, the build is technically complete and nobody uses it. The fix isn't more features , it's a sharper scope.
We've inherited dozens of these projects. The pattern is almost identical every time: a forty-page requirements doc, a Gantt chart that looked sensible in January, and an operations team that quietly went back to the spreadsheet in March. The engineering was fine. The scoping was the problem.
Start with the one painful workflow
List the three workflows your team complains about most. Pick the most painful one. Don't try to fix all three. The job of v1 is to make ONE workflow visibly, measurably faster , within 8 weeks.
Picking is harder than it sounds. There's always pressure to bundle: "while we're at it, can we also...". Resist it. Every workflow you add doubles the surface area, halves the focus and triples the risk that nothing ships at all. The discipline of picking ONE is most of the job.
A good test: if the v1 only solved this one workflow, would the business be measurably better off? If yes, you've picked correctly. If you find yourself saying "well, only if we also do X", X is the real workflow , go pick that one.
Map the current state in five minutes
Sit with the person who does the work. Get them to walk through it on a real example. Note: every system they touch, every copy-paste, every place they wait for someone else, every place they second-guess.
Don't redesign yet. Just map. The temptation to leap to solutions in this meeting is enormous , especially if you're technical. Park it. The first draft of the map is for understanding, not for building.
You're looking for three things in particular: swivel-chair work (the human acting as integration glue between two systems), waiting states (where the workflow stalls on someone else), and silent rework (the bits people redo because the upstream data was wrong). Those three categories account for most of the time you can give back.
Find the one decision that matters
Most internal tools are really decision-support systems. The dashboard exists so someone can decide what to do next. The form exists so someone can decide whether to approve. Identify the decision, and the rest of the UI almost designs itself.
Once you know the decision, you know the information the screen has to make obvious, the actions it has to make one click away, and , just as importantly , the things it should NOT show, because they're noise at the moment of choosing.
Cut ruthlessly
For every feature on your list, ask: does this directly speed up the one workflow we picked? If no, defer to phase 2. You can always add. You can rarely remove.
A useful framing: imagine the v1 is going to be reviewed by a board who only care about the one success metric. Every feature has to justify its existence against that metric. Nice-to-haves don't survive that filter, and that's the point.
Define done in a number
Not "easier to use". Not "better reporting". A number. "Reduce monthly close from 5 days to 2." "Cut new-hire onboarding from 4 hours to 30 minutes." If you can't define done in a number, you're not ready to build.
The number does two jobs. It tells the build team when to stop adding features (the moment the metric is hit, ship it). And it tells the business whether the investment paid off , which is the conversation that determines whether phase 2 ever gets funded.
What a good scope looks like
- One workflow, named and owned
- One success metric, with a baseline
- One user role for v1 (not three)
- A 6–8 week target
- A list of things explicitly NOT in v1
That fits on a single page. If yours doesn't, keep cutting.
A worked example
A recent client came to us wanting "a full operations platform". Forty-plus modules on the wishlist. We spent a morning mapping and landed on this v1: one workflow (job sheet creation and dispatch), one metric (time from customer call to engineer notified, baseline 47 minutes, target under 10), one role (the dispatcher). Shipped in seven weeks. The metric hit 6 minutes by week three of live use. Phases two and three got funded on the back of that single number , and they were much easier to scope, because everyone had now seen what "done" actually looked like.
If you remember one thing
A vague scope is a slow, expensive way of discovering what you should have decided up front. An hour of cutting saves a month of building. Do the cutting.