AI to Production

AI changed who can build software. It didn’t eliminate the need for software engineering.

Tools like Cursor, Lovable, Bolt, Replit, v0, ChatGPT, and Claude have done something remarkable: they’ve made it possible for a founder, product person, or entrepreneur with a clear idea to build a working application — without a team of engineers.

That’s a genuine shift. What used to take months and significant budget can now take days.

But there’s a gap between working and production-ready that AI tools don’t close. This service is designed specifically to bridge that gap.

The problem with AI-built prototypes

AI is very good at helping you build things quickly. It is less focused on the engineering discipline that makes software reliable when it matters.

An AI-built application often works well in development, in demos, and with a small number of test users. It starts to show real problems when you need:

More users — the application slows down, times out, or crashes under load
Real data — database queries that were fast with 100 rows collapse with 100,000
Proper authentication — login flows built by AI often have gaps in session handling, access control, or protection against common attacks
Security — hardcoded credentials, missing input validation, overly permissive access, unpatched dependencies
Reliable deployments — no automated process, manual changes, no way to roll back
Observability — when something goes wrong, there’s nothing to look at. No logs, no metrics, no way to understand what happened
Multiple developers — the codebase was optimised for getting things working, not for being understood by another human
Real growth — the architecture that worked for 100 users was never designed for 10,000

None of this means you built something badly. It means you built a prototype. Prototypes and production systems are different things, and they require different kinds of engineering.

Getting an application to work is not the same as engineering it for production.

Is this for you?

This is for you if

You built an application using AI tools and it actually works — but you don’t know what happens when real users hit it
You’re about to launch and want confidence that the system won’t fall over
You have an MVP but no senior engineer to review the architecture
Your application works with 100 users and you’re worried about what happens at 10,000
You need to start charging customers and want to be sure the infrastructure can handle it
The codebase is getting difficult to change without breaking things
You want to bring in a developer but the code is too tangled to hand over cleanly
You need someone to take ownership of the technical side while you focus on the product

Probably not for you if

You need a small website built from scratch
You’re looking for generic AI strategy advice
You’re looking for the cheapest possible development option

Before and after

AI-built prototype

Works locally and in demos
Fast to build
Little or no automated testing
Manual, fragile deployments
Security posture unknown
Breaks under real load
Difficult to change safely
No monitoring or alerting
No backup strategy
Hard to hand to another developer

Production-ready system

Secure and hardened
Tested with confidence
Automated, repeatable deployments
Handles real traffic
You know when something goes wrong
Scales to the next stage
Maintainable by a team
Backed up with recovery procedures
Documented
Ready to hand to another developer

How the engagement works

1 — Assess

Before touching any code, understand what was built and where the real risks are.

The assessment covers architecture, codebase structure, database design, authentication, security, infrastructure, dependencies, deployment process, and observability. The output is a Production Readiness Report — a concrete document with:

Critical issues that need fixing before going live
Security vulnerabilities and risks
Scalability bottlenecks
Architectural problems
A prioritised improvement roadmap

This is a standalone deliverable. You can act on it independently, use it to brief a technical hire, or continue with the following phases. It reduces the risk of committing to a larger engagement before you understand the scope.

2 — Stabilise

Fix the issues that could prevent the application from safely handling real users.

This typically includes: locking down authentication and session management, adding the authorisation checks that are missing, validating inputs and protecting against the most common attacks, moving secrets out of the codebase, improving error handling so errors don’t crash the application or expose internal details, adding basic logging so there’s a record of what happened, addressing dependency vulnerabilities, and ensuring there are database backups.

The goal here is not perfection. It’s eliminating the risks that could cause a serious incident in production.

3 — Engineer

Improve the underlying application so it’s maintainable and reliable — not just functional.

This is the real engineering work: refactoring fragile architecture, improving the database design, introducing proper boundaries between components, cleaning up the API design, adding automated tests for critical paths, and making the codebase understandable by a human developer rather than dependent on the original AI prompts.

Not every application needs all of this. The work is driven by what the specific codebase actually needs, not by a template.

4 — Productionise

Build the operational foundations required to run software seriously.

Automated deployments so releases are repeatable and reliable — no more manual changes to production. Infrastructure defined in code so environments can be reproduced. Proper separation between development, staging, and production. Monitoring and alerting so you know when something is wrong before your users tell you. Centralised logging so you can understand what happened when an incident occurs. Backup and recovery procedures so a failure isn’t a disaster.

5 — Scale

Only when there is an actual need.

Scaling prematurely is its own form of technical debt — it adds complexity without adding value. Once the application is stable and in production, assess the real traffic patterns, database growth, and bottlenecks, then adapt the architecture to handle the next stage of growth.

Don’t over-engineer an MVP. Engineer it for its next stage.

What you get

Production Readiness Report — a technical review of the existing application with prioritised recommendations. Concrete and actionable, independently useful even if you don’t continue further.

A hardened application — the security, reliability, and architectural issues that matter most, addressed. The kind of thing that keeps you out of the news.

Production infrastructure — automated deployments, proper environments, monitoring, alerting, and the operational foundations that make running software manageable rather than stressful.

A maintainable codebase — code that a developer can read, understand, and change without fear. Not dependent on re-running the original prompts.

A scalable foundation — the architecture adapted to the expected workload, without premature optimisation for a scale you haven’t reached yet.

Documentation — architecture decisions, deployment procedures, infrastructure overview, and the operational runbooks needed to keep things running when you’re not available.

On AI-generated code

AI tools are genuinely impressive at producing working software quickly. The applications that come through this process are often more capable than anything a non-technical founder could have built a few years ago.

The gap isn’t quality. It’s engineering discipline.

AI optimises for producing working code. Production engineering optimises for reliability, security, operational simplicity, and maintainability over time. Those are different goals, and they require different expertise.

You did something impressive by building a working product. This engagement takes it the rest of the way.

How to start

The right starting point is a Production Readiness Assessment.

It’s a fixed-scope engagement: a thorough review of your application, delivered as a prioritised report of what needs to change before you can safely go to production. You get something concrete and actionable at the end of it, regardless of whether you continue.

From there, you decide whether to proceed with stabilisation, engineering, and productionisation — or use the report to brief someone else.

The assessment is the lowest-risk way to understand what you’re working with.