It is happening more and more in Portugal, and almost always the same way. Someone in the company, often from outside the IT department, opens ChatGPT, Codex, Claude Code or Gemini and, after a few afternoons, has a working application. Time tracking, request management, a portal where clients can check their orders, a dashboard that finally pulls together numbers that lived in four different spreadsheets. It works. People use it. And a process that had been on the waiting list for two years is no longer on it.
Our position on this is simple: whoever built it did the right thing. For a long time, the distance between a good business idea and being able to show it working was wide enough to kill the idea along the way. That is no longer true today. Bringing a decision maker a prototype that already runs, with visible results and a concrete sense of what it does, is a real advantage. It is worth more than any thirty-page document describing the same thing.
What follows is not a list of reasons to distrust what your team built. It is the list of what changes when that application starts serving the business for real.
The short answer: the prototype is not wrong, it is incomplete
A prototype answers one question very well: does this make sense? It answers by showing the flow, the screens, the fields that matter and what people think once they finally have the thing in front of them.
There is another question it does not answer, because it was never built to: can this carry the company's work? This is where issues appear that stay invisible while the only user is one person who knows the system from the inside and knows what not to touch.
The question stops being "does this work?" and becomes a different one: what happens when it fails on a Thursday afternoon, with fifteen people depending on it and the person who built it nowhere to be found?
Professionalising a prototype means answering that second question without losing what the first one already proved.
What the prototype has already proved, and it is worth money
In a conventional software project, the longest and riskiest phase is not writing code. It is discovery: understanding how the process actually works, which exceptions exist and what people will really do once the system is in front of them. That is where weeks disappear into meetings, and where the misunderstandings that only surface at the end are born.
When a working prototype exists, much of that work is done, and done in the best way possible: in software, with real usage. Concretely, you already know that:
- the process is real and there are people who want it, because they used it without anyone making them;
- the data structure is sketched out, with the entities and fields the operation actually uses, and not the ones someone imagined in a meeting;
- the rules and the exceptions have surfaced, because a prototype in use finds in two weeks the odd cases a specification takes months to anticipate;
- the screens have been validated by the people who work in the process, which is the only validation that counts;
- there is a demonstrable business case, with a before and after that you can explain to whoever decides.
That is why we almost never recommend starting over. The code can change completely and the value stays, because the value sits in the knowledge of the process that ended up inside it.
What changes when the prototype becomes a company system
Who gets in and what each person can see
In a prototype it is normal to have no individual accounts, or a shared password, or access controlled by an address that "nobody outside knows". As soon as the application handles client data, financial figures or personnel information, that has to change: individual accounts, role-based permissions, and the guarantee that a user cannot see what does not belong to them just by changing a number in the address.
Where the data and the credentials live
Two things almost always show up together in the first audit. The first is where the data sits: a database on the computer of whoever built the application, or on a personal service, with no tested backups. The second is access keys written inside the code, which means anyone holding the code holds everything, including the billing account for the AI model.
The fix is well known and not dramatic: data on infrastructure controlled by the company and hosted in the European Union, credentials in a secrets manager, backups with a tested restore, and separate permissions for development and production.
What happens when it fails
A prototype fails silently, and whoever built it notices only because they happen to be watching. A system in production needs error handling, a record of what went wrong, and someone being alerted when a process did not finish. The problem is not the failure itself, it is the time that passes before anyone notices and the work of reconstructing afterwards whatever was left half done.
Who can work on this six months from now
This is the point that worries management most, and with good reason. A prototype tends to have a single author, no tests to confirm that a change does not break the rest, no organised version history and nothing written down about the decisions that were taken. It works well as long as that person is available and remembers everything. It stops working the day they move to another role, take holiday during a closing week, or simply no longer remember why that particular rule is there.
What it costs to run
Applications that use AI models carry a cost per use. In a prototype with three users, that cost goes unnoticed. With fifty, and with no consumption limits or control over who calls what, the monthly bill becomes a surprise. Setting limits, storing repeated results and choosing the right model for each task usually cuts that cost significantly, and makes it predictable, which is what matters to whoever approves budgets.
Signs the prototype has reached its limit
It is worth going through this list honestly. Two or three of these points are normal. Five or more mean the application is already a company system, but is not yet being treated as one:
- there are people who depend on it to get their daily work done;
- if the application stops for a day, someone has to go back to Excel;
- only one person knows how it works inside;
- there is no backup that has ever been successfully restored;
- the data includes client, employee or financial information;
- external clients or suppliers are using the application;
- nobody can say what it costs per month to keep running;
- a change has already broken something that used to work.
Three wrong answers to this problem
Throw it away and start from scratch. This is the most common reaction from someone who looks at the code and does not like what they see. It is also the most expensive, because it discards discovery work that has already been paid for and puts the company back into requirement meetings, months behind.
Leave it as it is and wait. This happens too, almost always for lack of time, and it is the option that ends worst. An informal system grows: more users, more data, more dependence. The moment when the fix is cheapest is now, not after an incident.
Hand maintenance to whoever built it, on top of their day job. It is unfair to that person and fragile for the company. Whoever built the prototype is usually the one who understands the process best, and that is the contribution worth keeping. Being responsible for security, availability and integrations as well, on top of the work they already have, is something else entirely.
How a prototype gets to production
1. Audit of what exists
One to two weeks looking at the code, at the data and at how the application is actually being used. By the end, three things are clear: what can be reused, what has to be rebuilt and what is urgent for security or compliance reasons. This phase starts with a free diagnosis, and it needs no decision from you to happen.
2. Agreeing the scope with whoever built it
We sit down with the person or the team who built the prototype. It is the most productive conversation in the whole project, because it is where the intent behind each decision becomes clear, and where deliberate choices get separated from shortcuts taken to get the idea across. The plan, the timeline and the investment come out of this.
3. Hardening the foundations
Authentication, permissions, data on proper infrastructure, credentials out of the code, error handling, usage logging and tests on the parts that cannot fail. At this stage users see little difference, and that is precisely the aim: the behaviour stays the same, the foundations change.
4. Integrating with what the company already runs
Most prototypes live in isolation, with data typed in by hand that already exists somewhere else. This is where the ERP, the CRM, invoicing or email get connected, so the application stops being an island and becomes part of the process.
5. Production, handover and continuity
Go-live with real users, close support through the first weeks and a formal handover: code, infrastructure, documentation and training. The system belongs to the company, with no dependence on licences from us to keep running.
What it costs and how long it takes
For a prototype with a contained scope, one process, one type of user and one or two integrations, the investment typically sits between €7,500 and €20,000, with 6 to 12 weeks to production. When the application spans several areas of the company, has external users or needs connections to systems without a usable API, the scope goes up and the timeline follows.
Two things move the figure more than anything else. The first is the quality of the prototype's data structure: if the entities and relationships are well thought out, almost everything can be reused; if the data is scattered with no structure, there is migration work. The second is the number of external systems to integrate, and whether those systems have a documented way of getting at the data.
As a rule, professionalising comes out cheaper than building the same system from nothing, because the definition phase is already done and validated against real usage.
What to decide before moving forward
Before talking about technology, it is worth answering five questions:
- How many people depend on this application to do their work today?
- What sensitive information does it store or handle?
- If it stops tomorrow, what is the real impact on the operation?
- Which systems should it be reading from and still is not?
- Who, inside the company, has the authority to decide the scope?
Anyone who can answer these already has half a specification, and it makes for a very different conversation from one that starts with a blank page.
AI-built applications taken to production are exactly this work: taking what your team built, making it safe for internal use and preparing it to grow with the operation. If you already have a prototype in use, you can request a free diagnosis. We look at what exists, without commitment, and return a proposal with scope, timeline and investment defined.