Someone in your firm already built it. Here is why it is still not live.

Matt Murphy at Faction Group makes a point I keep coming back to, which is that every business is a software company now and most of them have no idea about it. I think he is right, and the part that stuck with me is what it means for the people already doing it, because in most firms of ten to fifty people there is now somebody quietly building things that nobody asked them to build.

What is already going on in your business

You probably have an office manager who has wired up something that reads what comes in, files it against the right client, and nudges anyone who has not replied by Thursday. You might have a partner who spent a weekend on a client dashboard because they were fed up asking three different people for the same numbers before every Monday meeting. And somewhere in bookkeeping there is a spreadsheet pulling the month end together out of the accounts package, the bank and the job system in one go instead of three.

None of that was signed off by anyone, and none of it is a problem. It is probably the best thing happening in your business, and the instinct to shut it down is the wrong one.

Why your own people are the right ones to be building

Anyone can build the version that works when everything is normal. The person who knows that two clients get invoiced differently, and that the Tuesday run has to wait for the site sheets to come in, is the person who should be deciding what gets built, because the exceptions are not a detail on top of the job, they are most of the job.

That is also why rebuilding it from scratch is usually the wrong instinct. Start a fresh build and you spend the first three months explaining the exceptions all over again, whereas the thing already sitting on somebody's laptop has them baked in, and that is most of the work already done.

So why is it still not live?

Because building something and running it for real are two different jobs, and it is the second one that stops. In practice it stops on three questions that nobody in the room can answer, and they are usually asked by whoever has to carry the risk.

• What happens if it breaks on a Sunday? Nobody is watching it, nobody gets told, and the first you hear about it is Monday morning when somebody cannot do their job.
• Who can see the data that is in it? If the honest answer is anyone who has the link, that is the answer that stops it going live, and quite right too.
• What happens when the person who built it leaves? It runs off one laptop, one login and one person's head, and none of that is written down anywhere.

Notice that none of those is a complaint about the thing itself. It works. The gap is everything around it, and that gap has a shape.

The thirteen layers, one at a time

This is the list Matt Murphy's team audit against, and it is worth saying that none of it is exotic. These are the standard categories any engineer would recognise, which is rather the point, because the reason a prototype stalls is not that it needs something clever, it is that it needs thirteen fairly ordinary things and it currently has about three of them.

The thing itself, layers one to four

1. 1.Front-end foundations. The interface people actually touch, working on a real phone on a bad connection, and behaving sensibly while it is loading, when there is nothing to show, when something worked, and when something failed.
2. 2.APIs and backend logic. The part that checks what has been typed in, keeps your keys and passwords out of reach, works out who is asking, and applies the same business rules every time rather than whenever somebody remembers.
3. 3.Database and storage. Data laid out properly with the relationships between things written down, indexed so it stays quick as it grows, backed up, and changed through migrations rather than somebody editing a table by hand.
4. 4.Authentication and permissions. Establishing who somebody is, and then separately what that particular person or role is allowed to see and allowed to change.

Getting it live and being able to change it, layers five to seven

1. 1.Hosting and deployment. Moving it into production safely, with a staging copy to try things on, health checks that say whether it came up properly, and a way to put it back the way it was in a minute if it did not.
2. 2.Cloud and compute. Machines that suit the actual work, including the background jobs, the scheduled overnight runs, the file processing and the longer AI operations that do not fit in the time a web page is allowed to take.
3. 3.CI/CD and version control. A record of every change anybody made, and a pipeline that refuses to deploy when the build breaks, the tests fail or a security check trips.

Surviving real users, layers eight to eleven

1. 1.Security and row-level security. Protecting the secrets, the endpoints and the records themselves, so the separation between one client and another is enforced by the database rather than by the screen politely not showing it.
2. 2.Rate limiting. Capping how often any one person or address can hammer it, which is what stops bots, brute-force attempts, scraping and a runaway bill on a paid API.
3. 3.Caching and a CDN. Reusing the things that have not changed, so pages come back faster, the database does less work and the running cost comes down.
4. 4.Load balancing and scaling. Coping when everybody arrives at once, through pooled connections, queues, machines that come and go with demand, and sensible restraint when something upstream has its own limits.

Knowing when it broke, layers twelve and thirteen

1. 1.Error tracking and logs. Failures that announce themselves, with enough context to tell you what happened, so you find out before a client does.
2. 2.Availability and recovery. Keeping it running, watching that it is running, and having a restore you have genuinely rehearsed rather than a backup nobody has ever tried.

What it actually costs when one is missing

The reason those thirteen are hard to argue for is that skipping one does not show up as a bug. Nothing looks broken. It shows up later, and usually as money or as a phone call, so here are four of them made concrete.

• Skip rate limiting and one bot finds it and hammers it all night, and because every request costs you a fraction of a penny somewhere, you meet the bill at the end of the month.
• Skip record-level security and the login works perfectly well, but underneath it every row is readable, so one client can pull up another client's file.
• Skip error tracking and it fails quietly on a Friday and carries on looking fine, so you find out a fortnight later when somebody finally complains.
• Skip a tested backup and there is still a backup, but nobody has ever restored from it, so the day you need it is the day you learn whether it works.

What the second job looks like on a real one

We built a members' community a bot that answers questions out of their own documents. The working version came quickly and it was genuinely useful. What follows is not a list of things that were wrong with it, it is the second job that came after, and every item maps onto one of the thirteen above.

• Somebody could hide an instruction inside one of the documents and the bot would read it as an order and follow it, so the documents got fenced off and it now reads them without ever taking instructions from them. That is layer eight.
• One set of keys reached every source, so nothing in the design itself stopped one client's material reaching another. It now has its own credentials per source, which means the separation holds even when something else goes wrong. That is layer four.
• The first question each morning was slow, because nothing had run overnight and everything had to warm up. It gets kept warm and it sits next to its own database now, so the first answer lands like all the rest. That is layer six.
• A bad change could go out without anybody noticing until members hit it, so releases are pinned with checks in front of them and a broken one stops before it ships. That is layer five.

None of that changed what the bot actually did, it just changed whether you could put real members in front of it, and that is the whole distinction in one example.

What we would do

We come in and sit with the people who are already building things, because they are the ones who know what the business actually needs, and then we work out which of the thirteen layers the thing in front of us is missing and finish it properly. You own it at the end, which is the part that matters, because it is yours rather than another subscription you use a fifth of.

So if you have got something half finished sitting on somebody's laptop, that is the conversation worth having, and the thing to bring is not a specification. Just bring the person who built it.