The prototype is almost always the easy part
AI coding creates a particular effect: the first results arrive unusually fast. Work that used to take several days of development often becomes a clickable interface in one afternoon. That is also the idea behind many vendors. Cursor, Lovable, Replit and similar tools sell the visible quick win. The screenshot that gets applause internally is their product. Maintenance, testing, outages and responsibility stay with the business.
That is why it feels as if the remaining 20 percent cannot be hard, once the first 80 percent were this easy. In software, the opposite is often true. As soon as real people use the app, it grows. Multiple users, permissions, mobile use, integrations, failure cases, backups, data protection, monitoring, updates. A small app becomes a production system. Complexity does not rise evenly. Past certain thresholds it jumps.
Building software and running software are two jobs
A working prototype answers only one question: can this process be represented at all? Production software in a business has to survive many more.
- What happens if an integration is down, or its shape changes?
- What happens if a record arrives twice, or someone deletes data by accident?
- What happens after an update, with ten people working at once, or after a wrong AI output?
- What happens if the model or the hosting provider disappears overnight?
That is where software operations start. Not at the first screenshot that gets applause internally.
The most dangerous homegrown system is the successful prototype
A bad prototype is rarely a serious problem. It is tested, it is not enough, and it is thrown away. The successful one is more interesting. An internal app works. One person uses it, then three, then ten. After a few months, customer data, automations and the morning routine depend on it. The architecture was often never designed for that.
The important question is therefore not: does the software work today? It is: what happens when the business depends on it tomorrow?
Testing, maintenance and support get sharply more expensive as the software grows
AI reduces the cost of writing code. It does not reduce the cost of checking, maintaining and explaining that code when something breaks. At the start, an app has a few functions. A change is easy to try. Every extra form, field and automation adds interactions. A change to a form can hit database records, PDFs, permissions, integrations or existing customer data.
At some point it is no longer enough to check the new feature. You also have to check that everything that used to work still works. That is regression testing. After larger AI edits you often also have to understand what changed: which files were touched, which logic was rewritten, which new security hole appeared. Add manual tests, test data and time from people who know the real workflow. That effort grows faster than the app itself.
Costs therefore rarely rise in a straight line. They jump. The first user is cheap. The tenth needs permissions, training and someone reachable on Monday morning when nothing works. The first internal test records are simple. Real customer data brings data protection, deletion rules, access requests and backups. The first outage at 7:15 does not cost the same as the tool subscription. It costs missed jobs, support, recovery and trust.
- Maintenance: updates, dependencies, broken integrations, model changes.
- Regression: after every larger AI change, check what used to work.
- Data protection: grows with real data, not with the first screen.
- Outages and support: who responds when ten people cannot work?
The monthly price of an AI coding tool is therefore not the price of the software. Subscriptions, tokens, hosting, databases, APIs, backups, internal time, debugging, support, training and later migrations all count. The quick win on day one is cheap and visible. That is what the tools are built for. The jump comes later, when the demo has become a system.
Who maintains it, and who owns the access?
Many homegrown systems hang on one person. A digitally fluent employee knows the prompts, the database, the API keys, the workarounds and the known bugs. If that person leaves, or the freelancer disappears, you meet the bus factor: how many people can drop out before nobody can run the system?
Ownership looks like a side issue during experiments. Which email owns the hosting? Who owns the repository? Whose credit card is billed? Where do the API keys live? Once the app is business-critical, accounts, code and access must belong to the company. Not to a private ChatGPT account.
Data protection starts when real business data flows in
A login is not a security concept. As soon as names, addresses, job-site photos, readings, staff data or contract details sit in the app, you need answers: which vendors process the data, in which country, what is sent to AI models, how long it is stored, who can see what, whether backups exist and how deletion works.
In the trades those are often the same records that later have to stand as evidence, toward insurers or toward the customer. “It kind of worked” is not enough then.
AI agents need boundaries, not just a password
A classic AI system answers a question. An agent can act: change files, call APIs, write to databases, send mail or trigger other systems. Permissions then become an architecture problem. Not every agent should reach every customer record and every company system.
In July 2026 it became public that autonomous OpenAI test agents left their intended sandbox during a cybersecurity evaluation and reached Hugging Face infrastructure. That was a specialist security test with very capable systems and deliberately reduced safeguards. It does not mean an everyday chatbot will break out of a business. It does show something basic: the more an agent is allowed to do, the more isolation, permissions, monitoring and human approval matter. In August 2026 AIBase reported that OpenAI then paused part of its own training work for two weeks, isolated sandboxes more tightly and tightened monitoring. Even the vendor has to stop when the boundaries do not hold.
Dependence on models and platforms is a business risk
If you build on external AI models, you inherit their availability. In June 2026 the US government placed export restrictions on Claude Fable 5 and Mythos 5. Anthropic turned access off globally for a short time because it could not reliably check user nationality in real time. The restrictions were lifted at the end of June. Your own app can therefore be technically fine and still stop.
Vendor lock-in appears just as quietly. Many AI platforms bundle database, hosting, login, model and deploy into one surface. That is productive. It gets expensive if you later need to move and those pieces are not portable. A useful question at the start is: could we theoretically take this to another vendor? If the answer is “yes, but at considerable cost”, that cost should be accepted on purpose.
YouTube did not replace the trades
The wrong conclusion would be that businesses should stop building their own software. The opposite is likely. AI lowers the barrier the way YouTube lowered access to knowledge. Almost anyone can now watch how to plaster a wall or swap a tap in a few minutes. Trade businesses did not disappear. Access to knowledge does not replace experience, liability and clean execution.
Software is starting to follow the same pattern. Businesses will be able to do much more themselves. The question will less often be “custom build or standard software”. It will be: which parts do we customise, and which infrastructure do we not want to run ourselves?
Customise without starting from zero every time
Businesses want their own workflows. They rarely want to reinvent users, permissions, databases, PDF generation, mobile use, integrations and basic security for every internal tool. A durable middle path is a platform that already provides that foundation, while still letting the business shape its own documents, fields, data and automations.
That is how ProtocolHero started. First as digital protocols and records for the trades. We do not assume every shop works the same way. And we do not assume the future is only rigid standard software. A business should be able to model its own forms, data structures, approvals and AI-supported steps. On a foundation that does not make it reinvent users, permissions, on-site capture, signatures, PDFs and archives every time.
What that can look like in a shop
An electrician inspects a system at a customer site. That produces customer data, system data, readings, photos, defects, assessments, signatures and finally a document. The individual part is the shop’s process: finish the inspection, create a PDF, send it to the customer, store defects as structured data, update the job in the ERP, hand data to another tool, maybe start a draft invoice.
The shop should be able to own that process. The layer underneath, rights, storage, traceability, mobile capture and a document that holds up, does not have to be a new custom build every time.
Conclusion
AI coding is not a fad. The barrier to custom software will keep falling, and businesses should use that. The most important question is still not: how fast can we build this? It is: who maintains it, who tests after changes, who handles support during an outage, where does the data live, how dependent are we on one person or one vendor, and what happens when the cost does not keep rising in a straight line, but suddenly jumps?
The future is probably neither rigid standard software only, nor starting a software company for every workflow. It is customisation on a foundation someone actually operates. Customise: yes. Starting from zero every time: not necessarily.