How long does a custom internal tool take? A real build log

The build

The client is a franchise group with 150+ stores across several restaurant brands. Every week, their finance manager exported order data from the ordering system, rebuilt pivot tables in Excel, converted pack sizes into standard units, computed ingredient-compliance ratios, and emailed filtered spreadsheets to five district managers. The question the whole exercise answers is simple: are stores ordering ingredients in proportion to what they sell, and if not, who and how bad?

The replacement: a web dashboard. The finance manager uploads the weekly export; the system parses, classifies, converts, and scores every store; each district manager logs in and sees only their own stores; anomalies get flagged automatically, with AI summaries on demand. Stack: Next.js, Supabase, Vercel, with AI calls metered per request.

Here is what building it actually looked like, week by week.

Day 0 to day 2: in production

First commit on 30 April. On 1 May, the deploy-breaking bug was fixed and the app was live on the client's own URL, with login, role-based access, the upload flow, the scoring engine, dashboards, and a mobile layout, because district managers live on their phones. By 4 May, day five, the permission model was enforced everywhere: five district managers, each seeing only their own 9 to 50 stores, three admins seeing everything.

Speed like this is the part AI genuinely changed, and it would be dishonest to pretend otherwise. It is also the least important part of this story.

Weeks 3 to 7: the tool just ran

Five weeks, near-zero commits. Weekly uploads went in, district managers checked their stores, nobody needed us. If you are evaluating a builder, this stretch matters more than the fast start: a tool that needs constant attention to stay upright was not finished, it was demoed.

Weeks 8 to 14: what maintenance actually is

Then the business moved, as businesses do, and the commit log records exactly what it looks like when reality hits an internal tool:

Look at what these are. A supplier changed a case size, which silently skewed a ratio. A new packaging type appeared in the sales data and had to be mapped before the ingredient estimates drifted. The year boundary raised the question of whether a year has a week zero. An API returned at most 1,000 rows and quietly truncated a dropdown.

No feature list would ever contain these, and they are the entire difference between a tool people trust and a tool people quietly stop opening. When we say the demo is the easy half, this log is what the hard half looks like.

The part worth copying

Notice also what the client did right, because it is repeatable:

• One named owner. The finance manager who owned the spreadsheet owns the tool. Every rule in the scoring engine traces to a decision they confirmed, in writing.
• Feedback in batches. The week-11 spike of 27 commits is a single feedback session applied all at once: thresholds, rolling averages, label changes. Ten scattered requests cost more than one honest hour of "here is everything that annoys me."
• The AI is metered and tested. Every AI call has per-request cost tracking, and the anomaly summaries have an accuracy eval behind them. If a builder cannot tell you what their AI features cost to run or how often they are right, they do not know.

What this means if you are scoping one

Budget the calendar in three phases, because they are different products. Days for a working version. A week or two to real daily use. Then a quarter at low intensity while the tool absorbs the business, which is where the trust gets built. The business case calculator prices the status quo this replaces; the number is usually not close.

And when a vendor shows you their two-day demo, ask them the question this post answers with a git log: show me week eleven.