Skip to content

Apps and prototypes built with AI, taken properly to production

Anyone who has built a working prototype with ChatGPT, Claude Code or Codex has already proven the hard part: that the idea solves a real problem. We take that app to production with authentication, real data and integration, and the code stays in your company's hands.

What separates a convincing prototype from an app running in production

More and more teams are building their own apps with ChatGPT, Claude Code, Codex or Gemini, and that is good news. Instead of taking a decision maker a document proposing an improvement, they take the process working, with data in front of them and results in plain sight. It is the fastest way there is today to validate a business idea, and anyone doing it is doing the right work.

What comes next is not rewriting what already works. It is the layer no prototype has, because that is not what a prototype is for: authentication and permissions by profile, real data instead of test data, a link to the ERP or the CRM, backups, tests, and a record of what happened when someone reports an error. We take what already exists and add that layer, with the code, the database and the infrastructure ending up in your company's hands.

What we add to what already exists

  • Identity and permissions: everyone signs in with the company account they already use and sees only what concerns them, with a record of who did what.
  • Data for real: a stabilised data model with migrations, a database of your own, backups tested by restoring them, and migration of what is already in the prototype.
  • Integration and operation: a link to the ERP, the CRM or the production database, monitoring, alerts and a test environment kept separate from the live one.

The problem: the demo went well and the move to production stalled

The presentation worked, management gave the green light, and from there the questions changed in nature. Who is allowed in? Where does the data sit? What happens if this fails on a Tuesday morning? Who answers if one client shows up on another client's screen? These are fair questions, and none of them is about the idea, which is already proven. They are about the foundation the app needs in order to be used across the company, and that foundation does not get built in the same session as the prototype.

Signs you are at this point

  • The app runs on someone's computer, or in a personal account on an external service, and the data is either test data or a copy exported three months ago.
  • The access keys for the ERP, for email or for the AI model are written inside the code.
  • Everyone signs in with the same password and, when someone reports an error, there is no log to go back to.
  • IT has blocked the move to production, and rightly so.

What comes under control

Nothing starts over. What already works gets the pieces it is missing so that ten, fifty or two hundred people can use the app every day without surprises.

Access

Who gets in, and what they can do once inside

Authentication tied to the Microsoft 365 or Google accounts the company already uses, with permissions by profile and by area. Each person sees what concerns them, and there is a record of who viewed or changed what.

Data

Real data, with the model stabilised

A database of your own, with versioned migrations so the model can change without breaking what is already there. Whatever exists in the prototype is migrated, and backups are tested with an actual restore rather than just configured.

Integrations

A link to the ERP, the CRM and the rest of what is already in place

The app stops working off manual exports and starts reading from and writing to the systems where the data lives, with error handling for when the system on the other side does not respond.

Operations

Credentials, logging and somewhere to test

The keys that ended up inside the code during the prototype move into a secrets manager, and any that have been passed around get replaced. We add monitoring, usage logging, automated tests on the flows that cannot fail, and a test environment separate from the live one.

With what you already use

An app in production is only worth as much as its connections. We connect to what the company already has, including whatever runs on your own servers with no modern API, and we keep the tools the prototype already uses whenever that makes sense.

  • ERP and invoicing: Primavera, PHC, Sage and Moloni, including on-premise installations
  • Company authentication: Microsoft 365, Google Workspace and Active Directory
  • Production databases: SQL Server, PostgreSQL, MySQL and Oracle
  • AI models the prototype already uses: OpenAI, Anthropic, Google and alternatives hosted in the European Union
  • The prototype's services and infrastructure, such as Supabase, Firebase, Vercel, Make or n8n, kept as they are or moved to Azure, Google Cloud, AWS or your own servers when the technical case justifies it

Ownership and continuity

The app was born inside your company and that is where it goes back. It does not end up dependent on us, on accounts of ours, or on one person being the only one who knows how it works underneath.

  • Code, database and infrastructure owned by your company, in your own repositories and accounts.
  • Usage and change logs, with date and author, for when you need to understand what happened.
  • Permissions by profile, defined with whoever is responsible for each area rather than assumed by us.
  • Data hosted in the European Union, with backups tested by restoring them.
  • Technical documentation and training included, so that whoever built the app and the internal team can carry on developing it.

How it is implemented

It starts with what already exists. The first thing we do is watch the app working as it is, instead of designing another one on paper.

  1. 01

    Diagnosis

    30 to 45 minute session, free

    We watch the app working, see who uses it today and what has already been validated. You leave knowing what is missing before it can go into production, and in what order. No commitment to proceed.

  2. 02

    Technical review

    1 to 2 weeks

    We go through the code, the data model, the integrations and the credentials in place. At the end, scope, timeline and investment are fixed, with what gets reused and what gets added identified point by point.

  3. 03

    First version in production

    4 to 8 weeks

    The app starts running on your company's infrastructure, with authentication, permissions, backups, usage logging and one real integration. The people already using it keep working through the switch.

  4. 04

    Scale and evolution

    Depends on scope

    More teams, more modules, links to the remaining systems, automated tests on the critical flows and whatever compliance requirements the company has. From there, the app evolves at the pace of the business.

Investment

Reference bands upfront. The exact figure is fixed in the proposal, after the technical review, and does not change midway. The diagnosis is free and comes with no commitment.

First version in production

€7,500 to €15,000

The app you already have starts running on company infrastructure, with authentication, permissions by profile, backups, usage logging and one real integration. Includes reviewing the credentials that almost always ended up inside the code. 4 to 8 weeks.

Scale and integration

€15,000 to €35,000

Data model stabilised with migrations, a link to the ERP, the CRM or the production database, migration of what is already in the prototype, automated tests on the flows that cannot fail, monitoring and a test environment separate from the live one. 8 to 14 weeks.

Ongoing evolution

From €35,000

The first 3 months of support are included in the bands above. After that, extending to more teams and more modules, tougher compliance requirements, volume and availability.

Frequently asked questions about taking AI-built apps to production

It is worth keeping, and it is the starting point. The prototype carries decisions nobody can reconstruct from a document: which screens the team actually uses, which cases come up in practice, what management approved after seeing it work. We keep the solution and the design that have been validated and we work on the code that already exists. If there are parts to replace, we tell you which ones and explain why before touching anything.
Yes, and it makes a difference. Whoever built it knows the business rules inside it better than anyone, and those rules are worth more than any specification written after the fact. We work with that person or team, and we leave documentation and training behind so the work can carry on internally.
It is common, and it gets fixed. In a prototype, putting the key in the code is the shortest route to seeing the idea work, and at that stage it makes sense. Before going into production we move the credentials into a secrets manager, revoke and replace any that have been passed around, and clean the repository history. That is days of work, not weeks.
Often, yes. Supabase, Firebase, Vercel, Make and n8n hold up in production in plenty of scenarios, and swapping for the sake of swapping only adds risk. We propose a change when there is a concrete reason, such as a requirement to host in the European Union, a cost that scales badly with volume, or an integration that service simply cannot handle. The reason always goes in writing in the proposal.
The first version usually takes 4 to 8 weeks, after 1 to 2 weeks of technical review. If the app is already being used by a small group, a phased switch is normally possible: the current users carry on working while access, data and integrations move over to the final version.
It happens, and it is not a failure on the part of whoever built it. A prototype is optimised for proving an idea quickly, not for fifty people using it at the same time with real data. In the technical review we say clearly what gets reused as it is, what gets rebuilt and what each option costs. The decision is yours, and it never shows up as a surprise halfway through the project.
Next step

Want to know what this would do in your operation?

Free diagnosis, no commitment. We look at your process and come back with a plan covering scope, timeline and investment. Reply within 48 business hours, NDA included by default.

  • 100% free diagnosis
  • No commitment to proceed
  • Reply within 48 business hours
  • NDA included by default

Request free diagnosis

Two minutes to tell us the essentials. We reply within 48 business hours with a first read on your case and, if it makes sense, a proposed session.

0 / 4000