The dashboard trap
The first thing a 40-person firm asks for, when they decide to build internal software, is a dashboard. A real-time view of the business. KPI tiles. Trend lines. A weather report for the operation, projected on a TV in the conference room.
We have built exactly one of those that anyone still looks at. The TV is showing a Slack feed now, and the dashboard's data pipeline costs three hundred dollars a month to keep alive for nostalgia.
Find the three forms
What a small firm actually needs is rarely visible at the executive level. It lives in the inbox of the operations manager. It looks like this:
- A request that arrives by email and gets retyped into three systems.
- A status check that requires opening four tabs and asking one specific person.
- An approval that is technically logged in a SharePoint folder no one can find.
That is your first project. Not all of them. One of them. The most painful one. Build the form, the workflow behind it, the audit trail, and nothing else. Resist every adjacent feature. Ship it.
Scope is the whole product
The cheapest internal tool we ever built was a single-page Power App with seven fields, two buttons, and a Power Automate flow behind it. It replaced a 19-step process that lived across email, Excel, and a paper form that someone had to walk down the hall to deliver.
Total build time: nine days. Total cost: under fifteen thousand dollars. Annual savings, by the client's own measure: somewhere north of forty hours per week, every week, of senior operations time.
A small, sharp tool that does one thing well will outlive every dashboard you ever ship.
What we say no to
- Login pages. Federate to Entra ID. Always. The day you build a username and password screen, you have signed up to maintain it forever.
- Mobile apps. A responsive web app, served from a real domain, runs on every phone in the building. The native app store is a tax we do not pay.
- Configurability. If you need a different version of the form, we will build a different form. We do not build a form builder.
Build it to be handed off
We do not run the software we build. The client does. That single constraint shapes everything: the language we choose (boring), the framework (mainstream), the host (theirs), the runbook (written), and the documentation (in the same repo as the code, not a wiki nobody opens).
If a competent generalist on the client's team cannot make a small change six months after we leave, we have built the wrong thing. The whole point of small, sharp tools is that they are sized to be owned. Owned, run, and eventually replaced. By the people who use them.