Skip to main content

Secure Hosting for Vibe-Coded Apps

It works. That's not the same as it being safe.

AI coding tools will happily build you something genuinely useful in an afternoon. They will just as happily leave the admin page unauthenticated. We find what the model missed, fix it, and host the result properly.

Building software stopped being the hard part somewhere around last year.

You describe what you want, the model writes it, and within a day or two there is a working application with a login page, a database and a deployment. That is a genuine change and it is not going away.

What has not changed is that software facing the internet gets probed by automated scanners within hours of going live. And the failure mode of AI-assisted development is specific and consistent: the code does what you asked, and nothing more. You asked for an admin dashboard. You did not think to ask that it check who is looking at it. Neither did the model.

None of that is an argument against building this way. It is an argument for having somebody adversarial read it before your customers' data is sitting behind it.

The review

What we actually look for

A structured pass over the codebase and the running application, weighted towards the mistakes AI-assisted projects make most often.

Authentication and authorisation

Is every protected route actually protected? Can one user reach another user’s records by changing a number in the URL? Are roles enforced server-side or only hidden in the interface?

Secrets and credentials

API keys, database passwords and tokens in the repository, in client-side bundles, or logged in plain text. Rotation of anything already exposed.

Input handling

Injection into queries and commands, unrestricted file upload, template injection, and output that is rendered without escaping.

Rate limiting and abuse

Login, registration, password reset and any endpoint that costs you money when called in a loop — including the ones that call a paid AI API.

Data exposure

API responses returning more fields than the interface displays, verbose errors leaking stack traces, and debug modes left enabled in production.

Dependencies

Packages with known vulnerabilities, abandoned libraries, and versions the model recalled from its training data rather than chose deliberately.

How it goes

From “it's on my laptop” to “it's live and I can sleep”

  1. 1

    You send us the code

    A repository link or an archive, plus a sentence about what the application is meant to do and who is supposed to be able to do it. That last part matters more than it sounds — most authorisation bugs are a mismatch between what you assumed and what the code enforces.

  2. 2

    We read it adversarially

    A structured review of the codebase and the running application, looking for the categories above. Anything serious we tell you about immediately rather than holding until the end.

  3. 3

    You get a plain-English report

    Findings ranked by what could actually happen, not by scanner severity score. Each one says what the problem is, what an attacker could do with it, and what we recommend.

  4. 4

    We fix and harden

    We fix the issues that need fixing for the application to run safely, and set up the platform underneath it — TLS, firewalling, backups, rate limiting, monitoring and secrets handling.

  5. 5

    It goes live, and stays looked after

    Hosted on our platform with deployment pipelines, dependency monitoring and the same phone number as every other customer. Re-review when you make significant changes.

What this is

  • A thorough, human security review of your codebase
  • Fixes for the issues that matter, done by engineers
  • A hardened platform underneath the application
  • Ongoing hosting, monitoring and deployment
  • A written report you can show a client or an insurer

What it isn't

  • A guarantee that nothing will ever go wrong — nobody can offer that honestly
  • A formal penetration test or a certification
  • A rewrite of your application into something else
  • A one-off that covers you forever, if you keep changing the code

If you need a formal penetration test or a certification such as Cyber Essentials, Coffee Cup Solutions can arrange that separately.

FAQs

Questions about the review

Not at all — we build with these tools ourselves. The point is narrower than that. AI assistants are excellent at producing working software and much weaker at the adversarial thinking security requires, because "it works" and "it cannot be abused" are different questions and only one of them shows up in testing.

No, unless you ask us to. The default is that we find the problems, fix the ones that matter for safe operation, and hand you a list of the rest with our recommendations. It stays your application.

We tell you straight away rather than saving it for the report, and we tell you what the practical exposure is. Sometimes the right answer is to fix it before launch; sometimes it is to launch behind a login while we work through it. What we will not do is host something we believe is actively dangerous without saying so.

It depends on the size of the application, but a typical small-to-medium project is a matter of days rather than weeks. We will give you a timescale once we have seen the codebase.

For the review, yes — we cannot assess what we cannot read. We will sign an NDA if you would like one, access is limited to the engineers doing the work, and we do not retain the code afterwards beyond what is needed to host and deploy it.

Expected, and fine. Ongoing hosting includes the deployment pipeline and dependency monitoring, and we can re-review on a schedule or when you make significant changes. The initial review is a starting point, not a certificate.

Send us the repository

Tell us what you've built and what it's meant to do. We'll tell you what we'd want to look at, how long it would take, and what it would cost — before you commit to anything.

Or email hello@coffeecupsolutions.com