From prototype to production

AI built the prototype. Now let’s make it dependable software.

You have a working demo from Lovable, Bolt, Replit, v0 or Claude, but cannot tell whether it is secure, maintainable or ready for real users. I review the prototype, separate reusable work from risk and map the shortest responsible path to production.

Describe your prototype

When a takeover makes sense

  • Every new change breaks something that worked before.
  • The app now handles real data, payments or user accounts.
  • You do not know where keys, data, backups and access are controlled.
  • The product needs to pass an investor, client or developer review.
  • The AI builder reached its limit and progress has stalled.

What I assess

Code and architecture

What can stay, what needs repair and what is safer to rebuild.

Authentication and access

Whether users can only reach data they are actually authorised to see.

Data and secrets

Data model, backups, API keys, personal data and account deletion.

Tests and reliability

Critical flows, failure states, monitoring and safe deployment.

Ownership and handover

Repository, hosting, database, domain and accounts must remain under your control.

Path to production

An ordered repair plan, estimate and an honest build-versus-rebuild decision.

The audit ends with one of three recommendations

Continue

The foundation is usable. We fix specific risks and prepare a controlled release.

Rebuild selected parts

The product flow stays, while sensitive or unstable components are replaced.

Start again

Continuing would cost more or create more risk than a new foundation. We retain validated learning, not faulty code.

Checklist before real users arrive

  • Permissions are tested for every user role.
  • Secrets are absent from the browser and repository.
  • Personal data can be located, exported and deleted.
  • Payments and webhooks handle retries and failure.
  • A backup and tested restoration path exist.
  • Critical user journeys have automated or repeatable tests.
  • Errors reach monitoring and have a clear owner.
  • The client controls the repository, hosting, database and domain.

What the audit output looks like

Illustrative example, not a claim about a specific client project:

  • Keep: the interface and validated user journey.
  • Fix before launch: data permissions, secret management and payment failure states.
  • Add: backups, monitoring and a critical-order test.
  • Decision: rebuild the data layer and continue with the rest.

Audit pricing without guesswork

I first need repository access, a description of the current deployment and the list of critical functions. I then confirm the scope and fixed audit price before work begins. Remediation is a separate decision — the audit does not lock you into continuing with me.

The first output is a decision, not another promise.

After the initial audit, you receive a concise risk summary, a list of reusable work, a recommended path and a work estimate. If continuing does not make sense, I say so before you pay to add more layers to the wrong foundation.

Describe your prototype