You Vibe-Coded It. Now Make It Secure, Shipped and Sold.

Your app works. Most people never get that far, so take the win.

What is missing is one layer. It runs for you and three friends. It is not yet something a stranger can sign up for, pay for, and trust with their data while you are asleep. That layer is what this service covers. We read the code you already have, then fix auth, data isolation, payments, performance and deployment in place, then run the launch. It is not a rebuild. If you want it built from nothing, that is our software development engagement under Build and AI, a different scope and a different timeline. If what you want is an AI feature that does not exist yet (designed, evaluated and built into the product), that is AI integration. That work is open-ended engineering and this one is a bounded pass. Sustained demand after launch is the SaaS growth service. This page ends at live, paid for, and measured.

We start by reading the repository. Not scanning it. Reading it.

What is usually missing, and why

AI coding tools are good at producing the thing that was described to them. They are weaker at the parts nobody describes, because nobody prompts for the second click, the hostile user, or the refund. Those gaps come from how the code was produced. So this runs off a fixed checklist instead of a hunch.

Who can see what

The first thing we look for is a route that checks whether you are logged in and never checks whether the record belongs to you. Change the id in the URL and you are reading someone else’s data. Broken access control is the number one category in the OWASP Top 10. It is also the category a generator is most likely to leave behind. The prompt said “let users see their orders”, and the happy path satisfies that sentence completely.

Close behind it, three more. Row-level policies left permissive on a hosted database. An admin screen guarded only by hiding the button. A service credential shipped in the client bundle, where view-source reads it.

Money

Prices decided in the browser can be edited in the browser. Webhooks that are not signature-verified will accept a forged “payment succeeded” from anyone who finds the endpoint. Fulfilment that is not idempotent will grant the plan twice when the provider retries, which providers do by design. We wire checkout so card details never touch your server, verify every callback and make fulfilment safe to repeat. Then we test the paths nobody builds first. Failed card, refund, cancellation, and the customer who pays twice in four seconds.

Data

We establish where personal data actually lives and whether the backups restore or merely exist. Then whether logs are printing tokens, and whether a user who asks to be deleted can be. These are cheap to fix before launch and unpleasant afterwards.

The model call that is already in there

If the app talks to a language model, this section starts with the key and nothing subtler. A provider credential left in the client bundle is the cheapest attack there is. View-source, copy, spend. The meter runs in your name until somebody notices. A bug that only embarrasses you is one thing. This one costs real money while you sleep, so it gets checked before anything clever does.

From there the pass answers five questions in writing and stops there. Is the key on the server, or in the bundle. Is there a ceiling on what one account can spend in a day. Does the call time out, or does it hold a request open until something upstream gives up. If the model can reach tools or your database, what is the worst thing a hostile input could talk it into doing. We report that blast radius and close the obvious doors. We do not redesign the feature around it. And what does the model cost per active user, because that number decides whether your pricing survives contact with usage.

That is triage: bounding and securing a feature that already exists, inside a time-boxed pass over the code you already have. Sometimes the read says the feature needs designing instead. An eval set so you can tell whether a prompt change helped. Schema validation on every output. A defined degraded mode for the hours your provider is down. That is a build, and it is our AI integration service. We tell you which of the two you are buying after reading the code. Saying it then beats letting you pay for the wrong one.

What happens once other people are using it

Queries that are instant against fifty rows are not instant against fifty thousand. We find the missing indexes and the loops issuing one query per item, and set up error tracking. A failure then reaches you before it reaches a review.

What we keep

Your architecture survives unless it is the actual problem. The framework your tool chose, the database it picked, the naming, the structure: all of it stays if it works. We change the smallest number of things that make the app safe to sell. You should still recognise the repository when we hand it back. You built this. We are making it durable, not making it ours.

Launch, and the first channel

Going live is a step, not a finish. We ship it behind a rollback, watch the first real traffic, and open exactly one acquisition channel with measurement that works on the first visit. One channel, properly instrumented, tells you something true in a fortnight. Five channels opened at once tell you nothing for a quarter, and cost more doing it.

What we turn down

A working app does not get rewritten into a stack we happen to prefer so that we can bill you for the translation. Nor do you get a findings document and a wave goodbye. An unimplemented fix is not a fix. Nobody here will tell you the app is now secure, because that sentence is not available to anyone about any software. What we can tell you is which classes of defect were found, fixed and tested, and which we did not go looking for.

And the launch waits if the payment or deletion path is untested. Failures on those two cost trust, and a discount does not buy it back.