A client showed me an app a few weeks back. He built it himself. No engineering background, no team, a couple of evenings and a weekend. It tracked something his department had been keeping in a spreadsheet for years, and it did the job better than the spreadsheet did.
He was a bit sheepish about showing me, as though he had wandered onto our patch. My honest reaction was the opposite. He was right to build it. He should build the next one too.
That is not the most sales-friendly thing for a software company to say, so let me explain what I mean by it, and where it stops being true.
The difficulty never went away
Every generation of this industry has removed a layer of difficulty, and every generation has been told that what it built does not really count.
Compilers arrived and the people who understood the machine said the compiler crowd did not understand computers. Frameworks arrived and the people writing their own memory management said the same thing again. Then cloud, so you no longer needed to know what a rack looked like. Then SaaS, so you no longer needed to install anything at all. Now AI, and somebody with no formal training can describe an app in plain English and have it running before lunch.
Every one of those steps was real, and every one of them removed the same kind of difficulty: the difficulty of making the thing exist. That is the part that keeps getting cheaper. It was never the expensive part.
What got cheap is producing software. What did not get cheap is being responsible for it.
What stayed hard
Ask any of these questions about an app and you will see the difference straight away
- Who is allowed to see what, and who decides that?
- What happens when two people change the same record at the same time?
- Where does the data physically sit, and whose law applies to it?
- Who finds out when it breaks at three in the morning, and who fixes it?
- What did this record look like six months ago, and who changed it?
- What happens to all of the above when the person who built it leaves?
- Who is responsible?...
None of those are coding problems. AI has not made a dent in a single one of them, because they are not questions about syntax. They are questions about consequence, and consequence is not something you can prompt your way out of.
Build it yourself
Here is a test worth applying honestly. Build it yourself if all of the following are true.
- It serves you, or a small team who all sit within shouting distance of each other.
- It holds nothing you would have to report on if it leaked.
- Nothing in it moves money, grants access, or certifies a person as competent to do something.
- If it stopped working tomorrow, the consequence is irritation and a temporary spreadsheet.
- If it vanished entirely, you could rebuild it over a weekend.
If that is your app, build it. You will learn more about how your own process actually works in two evenings of building than in a month of workshops, and you will end up with something better than what you had.
Most software in most organisations sits in this category and always has. The spreadsheets, the shared trackers, the little tools somebody made because the official system was painful. The only thing that changed is that those tools now look like proper applications.
The line, and why nobody notices crossing it
There is a point where an app stops being yours and becomes the company's. It is not a technical threshold and nobody sends a memo when it happens. You find out afterwards.
The symptoms are easy enough to recognise once you know to look for them.
Somebody outside your team starts relying on it. Somebody asks who else has access. Somebody asks what happens when you are on annual leave. It starts holding data you would have to declare in a breach. It touches a certificate, a permit, an invoice or a competency record. An auditor asks how you know the number on the screen is correct, and you realise the honest answer is that you know because you wrote it.
Here is the awkward part. An app almost always crosses that line because it worked. Nothing punishes a good prototype quite like being useful.
The words that turn out to be load-bearing
We put together a glossary of the vocabulary you run into on the other side of that line. It is not there to make anyone feel incapable, quite the opposite.
What catches people out is rarely a word they have never heard. It is a word they have been using loosely which turns out to be doing serious work.
"We have a backup" usually means a copy exists somewhere. It rarely means anyone has ever tested restoring from it. "It has a login" is not the same thing as an identity model, and a list of permissions per person is not the same thing as role based access. "It is on the cloud" says nothing at all about which country your data lives in or who else can reach it. "It is finished" and "it is in production" are two different states carrying two very different sets of obligations.
Read the glossary the way you would read a survey on a building you already own. Not to become a surveyor, but to work out which findings you can live with and which ones mean you need somebody in.
.png&w=3840&q=75)
Two bad options, and a third
Once an app has crossed the line, people are usually offered a choice between two things, and both of them are poor.
The first is to carry on patching it yourself. That works for a while. Then maintaining it quietly becomes the job you do instead of the job you were hired for, and every change carries a small risk you cannot properly assess.
The second is to bin it and commission a proper enterprise build. Eighteen months, a steering committee, and a requirements document that spends half its length describing the thing you already built.
Both of those throw away the most valuable asset in the room, which is a working system that has already proved the idea is worth having.
The third option is to keep what you proved and change what it stands on.
Where Radax comes in
Radax is our enterprise delivery platform, and its entire purpose is that we never rebuild the same foundations twice. Multi-tenancy and data isolation, the authentication and SSO chain, role based access, an audit trail on every action, a consistent data contract, deployment and monitoring. All of it is there on day one.
None of that wins a demo. All of it becomes mandatory the moment an app belongs to the company rather than to you. And none of it is your competitive advantage, so there is no sense in you paying to invent it.
That is why our builds run in weeks rather than quarters. The plumbing is already done, so the effort goes into the workflow and the business logic, which is the only part that is genuinely yours.
What the build journey actually looks like
We start with whatever you have, including the thing you made yourself. We keep what is proven, we are direct about what will not survive contact with the rest of the organisation, and we are clear about which stage you are at, because a proof of concept, a pilot and a production system have three different definitions of done and confusing them is how budgets disappear.
We will also tell you when not to build something. That happens more often than you would expect and it has never once cost us a client worth having.
Back to the client
We did not throw his app away. We took it apart, kept the logic he had already worked out, and put it on foundations that could carry the whole company instead of one department. Two evenings and a weekend of his own effort turned into the clearest specification any delivery team could hope for.
That is the part worth remembering. The best brief we ever get is something somebody has already built themselves.
So build the first one. Build the second one as well. Just know which one you are on, and talk to us before it quietly becomes the company's.