The third app was the fastest

Earlier I wrote here that at a contractor we first had to build the source. There was no data, so we made three small things: an app to count stock, an app for job site surveys, and a planning board.

Last week that planning board went live. Of the three, it took the least time. That is remarkable, because it is not the simplest. Things get dragged around in it, bars run across weeks, and four crews have to be able to work in it at the same time.

The reason is mundane. We put almost nothing new into it.

What we did not build again

The planning board had to sit behind a code. The office has no accounts and does not want them. That lock already existed in the job site survey app: a shared code, a signed cookie that lasts a year, and a gatekeeper in front of every page. Taken over in half an hour.

It had to be possible to order material per job site, with an order form as a PDF. That order form already existed in the stock app, with the suppliers and the layout. Taken over.

And the quote for a job site had to be visible. The link with the invoicing package already existed, including one painful detail: when you fetch a file, that package wants a key but no party number, while that same party number is mandatory elsewhere. Send it anyway and you get a refusal that explains nothing. The first time that cost half a day. The second time zero minutes, because it was written down.

All three run on the same platform, Vercel, with the same database behind them. Putting a new app online there is no longer a project, but a matter of minutes.

Why that was possible

Not because copying code is easy. Copying code is always easy. The problem is that six months later you no longer know why something was the way it was, and then you copy the form without the reason.

Each of those three projects contains a file that says why. Not what the code does, you read that in the code. But why the cookie stays valid for a year: because otherwise a salesperson on a roof without signal gets stuck. Why there are no prices on the order form: because prices go stale and the supplier fills them in himself. And why a date comes out of the database as text.

That last one is the best example.

The mistakes were never in the hard part

A date in a database is a day on the calendar, not a moment in time. But many systems turn it into midnight, and midnight in Belgium is ten o'clock the evening before in universal time. Read that wrong and you see 28 September where 29 September was meant.

That mistake turned up twice in this project. First in the schedule itself, later in the date of a quote. The second time it was found in five minutes, precisely because the first time had been written down.

That is how it went with almost everything that went wrong. Never the dragging, never the calculating with working days. But a technical checkpoint that gave away the name of the database to anyone who knew the address. That was found by requesting it from a browser without any login, instead of assuming it was protected.

And the quote from the invoicing package turned out not to be a list of items but one block of running text. The plan to extract a materials list from it automatically could go straight in the bin. That is better than building it and finding out afterwards.

Update October 2026: what did not work with a fixed rule did work later with AI. An assistant in the planning board reads the running text and proposes a materials list, which the office checks and confirms. More on that in do you need Fabric?

What we deliberately left blank

The order form the app produces today still literally says this:

VAT [fill in number]
[fill in street and number]
Customer no. [fill in customer number]

That is not sloppiness. Nobody knew those numbers when the form was built, and an invented customer number on an order to a supplier is worse than a visible gap. A gap asks to be filled in. A plausible invention is never noticed again.

We keep that rule in all three apps: what is unknown stays visibly unknown.

What it comes down to

For a smaller company this is the difference between "we will do that some day" and just doing it. The first app is expensive, because you build everything around it as well. The second is cheaper. The third cost a fraction.

That only works if you write down one sentence about the why for every decision. That is not documentation in the heavy sense. No manual, no diagrams. One file per project that says what you do not want to figure out again next time.

What it delivers is not tidiness. It is speed.