Watch the workflow
We work out where Sortly is genuinely the source of truth, where side systems have crept in, and which steps only work because one experienced person is quietly patching them.
Approach
Find the bottleneck first. Build the smallest thing that clears it.
Dashboards are easy to pitch and easy to ignore, so I do not start there. I start with whichever part of the week burns the most hours or produces the most mistakes, because that is the piece you will feel the day it gets better.
Ship something narrow
The first release solves one costly problem and nothing else. Your team should feel the difference in the first week rather than at the end of a long build.
Make it hold up
Once the workflow earns its place, we add permissions, audit history, sensible failure behavior, and a way to support it when I am not around.
Expand on evidence
Only after the first workflow has been stable for a while do we extend into neighboring processes, further integrations, or customer-facing access.
Principles
Three rules I 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 just moved the manual work somewhere less visible. Fewer moving parts, every time.
Make ownership obvious
Anyone should be able to answer who can do what, who administers it, and what happens when it breaks at the worst moment.
Next step
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.