Find the bottleneck. Build the smallest thing that clears it.
Dashboards are easy to pitch and easy to ignore, so we do not start there. We start with whichever part of the week burns the most hours or produces the most mistakes, because that is the piece you feel the day it gets better.
Watch the workflow
Where the platform is genuinely the source of truth, where side systems have crept in, and which steps only work because one experienced person quietly patches them.
Ship something narrow
The first release solves one costly problem and nothing else. Your team should feel it in the first week, not at the end of a long build.
Make it hold up
Permissions, audit history, sensible failure behaviour, and a support path. This is the phase people skip, and the one that decides whether the tool survives the year.
Expand on evidence
Only once the first workflow has been stable for a while do we extend into neighbouring processes, further integrations, or customer access.
Three rules we hold to
Operators decide
If the people doing the work dread opening the tool, it is not finished — whatever the requirements document says.
Keep it maintainable
Software that needs constant babysitting has only moved the manual work somewhere less visible. Fewer moving parts, every time.
Make ownership obvious
Anyone should be able to say who can do what, who administers it, and what happens when it breaks at the worst possible moment.
Start with a conversation, not a proposal.
Thirty minutes is usually enough to tell whether there is a project here and roughly what it would take.