AI App to Production
Built an App with AI? We'll Help You Ship It.
If you built a prototype or a working app with Lovable, Cursor, Replit, Bolt, Claude Code, v0 or a similar tool, and it now has to handle real users, real data and real payments, Peregrine's engineers can assess it, fix it, finish it, secure it and launch it. We work with founders and product teams mainly in the US and Canada.
AI-assisted development is a legitimate way to get a product this far. What is left is the engineering a demo does not exercise: access rules, data isolation, payments, background work, tests and deployment. Keep what works. Fix what does not. Rebuild only where the review shows it is justified.
Both open a short form. Please do not send code, passwords or API keys through it: access to your repository and hosting is arranged securely after the scope is agreed.
Common blockers
Does This Sound Familiar?
These are common blockers when an app built with AI tools moves from a demo to production. Each one is a specific engineering problem, and none of them means the work so far was wasted.
- It works on your machine or in the builder's preview, but the production deployment fails or behaves differently.
- Sign-up and login work, but password reset, email verification, roles or session expiry are incomplete.
- You are not sure who can read or change which rows in the database, or whether one customer can see another customer's data.
- A third-party API works most of the time, then times out, hits a rate limit or returns something the code does not handle.
- Payments succeed in testing, but subscriptions, refunds or webhook events do not reliably update the app.
- Emails, imports, reports or AI calls that should run in the background fail silently or hold up the page.
- Each AI-generated change fixes one thing and breaks another.
- There are no meaningful automated tests, so nobody knows what a change will affect.
- The code uses several different patterns for the same job, and it is hard to tell which one is current.
- Pages that were fast with test data are slow with real users and real data volumes.
- You cannot tell whether to keep improving this code or start again.
At a glance
AI App to Production at a Glance
| What's delivered | A scoped review with written findings and fix-or-rebuild recommendations, then the agreed work: authentication and access rules, backend and payments, tests and CI/CD, production deployment, monitoring and handover |
|---|---|
| Engagement model | Fixed-scope projects, monthly retainers, or a combination, agreed after the discovery call |
| How it starts | A 30-minute technical discovery call with an engineer |
| Pricing | Pricing is scoped per project after the discovery call. |
| Related case studies | None published yet. Browse all case studies |
Fit
Is AI App to Production the Right Fit?
A good fit when
- You have a prototype or a working app built with an AI coding tool or app builder, and it now has to be ready for real users, data or payments.
- The app works in a demo, but something specific blocks launch: deployment, authentication, data access, payments or reliability.
- You want an engineering view of what to keep, fix or rebuild before spending more on the current code.
- You plan to keep developing after launch, with AI tools or without, and want tests and a deployment pipeline under the product.
Probably not the right fit when
- You are still testing whether the idea works with users. Keep building in the AI tool; it is the cheaper way to learn.
- You want a new product designed and built from the start, with no existing code to keep. That is a new build: SaaS development.
- You want AI features such as natural-language search, assistants or document extraction added to a product. See AI automation.
- You need a formal penetration test report or a compliance attestation. That comes from a specialist security firm; this is an engineering review and remediation, not a certification.
What we build
What Does Peregrine's AI App to Production Service Include?
Peregrine's AI app to production service takes an app you built with an AI tool and prepares it for real users: a review of the code and infrastructure, written findings, then the agreed work on authentication, database access rules, backend and payments, tests, deployment, monitoring and handover. We keep what works and replace only what cannot be made reliable.
Code and architecture review
Engineers read the code, schema, configuration and integrations, run the app the way users will, and write down what is sound, what is risky and what blocks launch, in order of priority.
Authentication and authorization
Complete sign-up, login, password reset and session handling, and permission checks enforced on the server for every action, not only hidden buttons in the interface.
Data model, database permissions and tenant isolation
A data model that matches how the business works, database access rules on every table, and isolation so one customer can never read or change another customer's records.
Backend and API completion
The server-side logic the prototype skipped: validation, error handling, rate limits and the endpoints the interface calls but nothing yet implements properly.
Payments and webhook reliability
Payment flows where subscriptions, refunds and failed charges keep access and records correct, with webhook handlers that verify signatures, ignore duplicates and cope with events arriving out of order.
Background processing
Emails, imports, reports and AI calls moved out of the web request into a job queue with retries, so slow or failing work is retried and visible instead of lost.
Security hardening
Secrets kept out of the browser and the repository, input validation, dependency updates, and checks against published guidance such as the OWASP Top 10.
Performance with real data
Profiling the slow pages and queries, then adding the indexes, caching or query changes that make the app fast with real users and real data volumes.
Automated tests and CI/CD
Tests around sign-up, permissions, payments and the other paths that must not break, run on every change by a pipeline before anything reaches production.
Production deployment, monitoring and backups
Separate staging and production environments, a repeatable deployment, error and uptime monitoring, and database backups that have been restored at least once to prove they work.
Documentation, handover and continued development
Notes on the architecture, environments and how to release, then either a handover to your team or continued maintenance and feature work on a retainer.
Industries: All industries
Timeline
How Long Does an AI App to Production Project Take?
Peregrine does not quote a timeline before the assessment, because two apps built with the same tool can need very different amounts of work. The scoped review comes first and ends in written findings and priorities. The schedule for the agreed fixes follows from those findings, and the work runs in two-week sprints with weekly demos.
Initial discussion
A 30-minute technical discovery call with an engineer about what the app does, what it was built with, where it stands and what launch means for you. No code or credentials are needed.
Scoped technical assessment
We agree what the review covers: which parts of the app and which environments, and the questions it has to answer, such as whether customer data is isolated or payments are reliable.
Review of code and infrastructure
With access you grant through your own accounts, engineers review the code, the database and its access rules, hosting and deployment, and the third-party integrations.
Written findings and priorities
A written report ordered by risk to your users and your launch, separating what must be fixed before launch from what can wait.
Fix-or-rebuild recommendations
For each problem area, a recommendation to keep, fix, redesign or replace it, with the reasoning, so you decide with the trade-offs in view.
Agreed scope
You choose what goes into the work: only the launch blockers, everything in the findings, or a staged plan. Scope and engagement model are agreed before work starts.
Implementation and QA
The fixes, in two-week sprints with weekly demos, with tests added around each change so later changes, including AI-generated ones, do not quietly undo it.
Production verification
The app is released through the pipeline and the critical paths, such as sign-up, payment and access for each role, are checked in the live environment.
Handover or continuing support
Documentation of the architecture, environments and release process, then a handover to your team or continued development on a retainer.
Fix or rebuild
Fix or Rebuild?
Vibe coding cleanup is rarely one decision for the whole app: the answer is usually different for different parts of it. This table shows how we would typically approach common situations. It is a starting point for the conversation, not a verdict: the review of your code decides, and no outcome is promised before it.
| Situation | Typical approach | Why |
|---|---|---|
| The interface works and users like it, but the backend is unreliable | Keep the frontend. Fix or rebuild the backend behind a stable API | A working interface is worth keeping. If the API it calls stays the same, the backend can be replaced without redoing the screens. |
| The database schema is sound, but authorization is missing or only enforced in the interface | Keep the schema. Add access rules on the server and in the database, with tests for each role | Access control only works where users cannot modify it. A good schema makes the rules straightforward to add. |
| Customer data is not isolated: one account can reach another account's records | Redesign the tenancy model, and migrate existing data if the app has users | Isolation is a data-model decision. Patching individual queries tends to leave gaps, so this is one place where redesign is often justified. |
| Payments work in testing, but webhook handling is unverified or not idempotent | Keep the payment provider. Rework the webhook handler: signature checks, duplicate handling, ordering and retries | Stripe, for example, documents that events can be retried, delivered more than once and arrive out of order. The handler has to be written for that. |
| Slow or failing work runs inside web requests | Move it to a background job queue with retries and monitoring | Requests time out and failures disappear. A queue retries the work and shows what failed. |
| Every change breaks something else, and there are no tests | Add tests around the critical paths before changing more code | Tests make every later change safer, whether a person or an AI tool writes it. |
| The code is inconsistent but works | Refactor where the code is being changed anyway, not as a separate rewrite | Consistency matters most in the parts that change often. Rewriting stable code adds risk without adding value. |
| The data model cannot represent the business, security problems run throughout, or nothing can change without breaking | Partial replacement or a rebuild may be justified, reusing the interface and what the prototype taught you | When fixing costs more than replacing, rebuilding is the honest recommendation. The prototype remains a working specification. |
Typical approaches only. What applies to your app depends on what the review finds.
Published guidance
What the Platforms' Own Documentation Says
The requirements below come from the standards bodies and vendors themselves, including the AI app builders. A production review checks an app against published guidance like this. Each item links to its source.
Scope
What Determines the Scope of an AI App to Production Project?
These are the inputs that change the effort. None needs a final answer before the first call, but each one you can answer makes the estimate tighter.
- Distance from launch
- Whether the app runs only locally or in the builder's preview, is deployed but unused, or already has paying users. Live users add staging, migrations and staged releases.
- Size and roles
- The number of screens, workflows and user roles. Each role multiplies the access rules to write and test.
- Data and tenancy
- Whether customers share one database, and how sensitive the data is. Personal, health or financial data raises the bar for access control, logging and backups.
- Integrations
- Each payment provider, email service, AI API or other third-party system is its own piece of work, sized by how it fails and how it is called.
- How much can be kept
- The review decides how much of the code stays. Keeping more means less work, but only where the kept code can be tested and trusted.
- Hosting
- Staying on the platform the app was built on, or moving to your own hosting and database, changes the deployment and migration work.
- Launch requirements
- What must be true on launch day, and what can follow later. A short must-have list keeps the first phase small.
A sensible first phase
A sensible first phase is the scoped review, followed by the fixes that block launch: access control and data isolation, payment handling, and a deployment pipeline with tests around those paths. Further improvements can follow once real users are on the app and you can see what they actually use.
Cost
What Does AI App to Production Cost?
Peregrine takes on this work as fixed-scope projects, monthly retainers, or a combination, agreed after the discovery call. Cost depends on what the review finds: how much code can be kept, and how many roles and integrations the app has. We do not publish a price list. For one common rework area, read Building Reliable Webhook and Event-Driven Integrations.
Building Reliable Webhook and Event-Driven Integrations
How to receive and send webhooks reliably: signature checks, idempotency, ordering, retries with jitter, the outbox pattern, reconciliation and SSRF defenses.
Read the guideVibe-Coded App Security Checklist: What to Check Before Launch
What to check before an AI-built app takes real users and data: access rules, Supabase RLS, secrets, webhooks, backups and monitoring, each with a safe test.
Read the guideDesigning Reliable Background Jobs with Redis and BullMQ
How to run BullMQ on Redis in production: retries and backoff, concurrency, stalled jobs, idempotent handlers, Job Schedulers, Redis settings and failure modes.
Read the guideBuilding a Multi-Tenant Real Estate SaaS Platform
How to design tenancy for a real estate SaaS: tenant hierarchy, data isolation with row-level security, custom domains, per-tenant MLS licenses and lifecycle.
Read the guideGetting started
How Does an AI App to Production Project Start?
A Peregrine AI App to Production project starts with a 30-minute technical discovery call with an engineer, not a salesperson. Larger builds then begin with a discovery sprint that maps requirements, designs the architecture and produces a written technical plan. Smaller, well-defined tasks can use the quick project form for a scoped estimate.
What to bring to the scoping call
- A short overview of what the app does and who uses it.
- The tool or platform it was built with, such as Lovable, Cursor, Replit, Bolt, Claude Code or v0.
- Where it stands: running locally, on a preview link, or live with users.
- The main blockers, in your own words.
- What must work on launch day.
- The hosting and database, if you know them.
- Your timeline, and any date that cannot move.
- No code, passwords or API keys. Access to the repository and hosting is arranged securely after the scope is agreed.
Partial answers are fine. Whatever is missing becomes the first item on the call.
Case studies
Which Case Studies Show Peregrine's AI App to Production Work?
Peregrine has not published a case study about an app built with an AI coding tool. The closest published work is a real estate SaaS platform whose first version worked for 5 agents: the case study describes a full codebase audit, then a rebuild of search, the MLS sync and multi-tenant isolation, and reports growth to 200+ agents.
Stack
Technology We Use
Related services
Services Often Scoped With AI App to Production
FAQ
Frequently Asked Questions
Do we have to rebuild the app from scratch?
Not by default. Most of the decision is made part by part: an interface that works is usually worth keeping, while a missing access model or broken data isolation may need redesign. The written findings give a keep, fix, redesign or replace recommendation for each area, with the reasoning, before any work is agreed.
Can we keep using Lovable, Cursor or other AI tools after the app is fixed?
Yes. What changes is that every change, whoever or whatever wrote it, goes through version control, automated tests and the deployment pipeline before it reaches production, so a regression is caught before your users see it.
What access do you need, and how do we share it safely?
Nothing for the first call. Once the scope is agreed, we ask for access to the repository, hosting and database through your own accounts, ideally as individual user invitations with only the permissions the work needs, which you can revoke at the end. Please never send passwords, API keys or code through a website form or email.
Which stacks do you work with?
The tool you used matters less than the code it produced. Our engineers work with React, Next.js, TypeScript, Node.js, PostgreSQL and Supabase, with Stripe for payments, on hosting such as Vercel and AWS. If your app uses something else, say so on the first call and we will tell you plainly whether we are the right team.
Our app already has users. Can it stay live while you work on it?
That is how we would plan it. Changes are tested in a staging environment first and released in steps, and data migrations are rehearsed on a copy before they run in production. If a change needs a maintenance window, for example a tenancy redesign, the findings say so in advance.
How is the review priced?
The scope of the review, and how it is charged, are agreed after the first call, as a fixed-scope project, a monthly retainer or a combination. We do not publish a price list, because the effort depends on the size of the app and the questions the review has to answer.
Who owns the IP rights to what Peregrine builds?
You do. Once the work is paid for, the client owns the intellectual property (IP) rights to what Peregrine builds for the project, whether it is delivered as a fixed-scope project, a monthly retainer or a combination of the two.
Questions about the team, contract models and how progress is shown are answered on the services page.
Technical consultation
Book an AI App Launch Review
Tell us what you built, what you built it with and what is stopping launch. Your first conversation is with an engineer. Please leave out code and credentials; access is arranged securely after the scope is agreed.
- A 30-minute technical discovery call with an engineer, not a salesperson.
- Fixed-scope projects, monthly retainers, or a combination, agreed after the call.
- Small, well-defined tasks get a scoped estimate. We reply within 1 business day.
Prefer to pick a time? Book a call on Calendly
