Everyone Can Build Now. Here's How to Actually Ship.

Something fundamental changed in the last two years.

A teacher in Birmingham built a classroom management app over a half-term holiday. A physiotherapist in Leeds built a patient booking system in a weekend. A university student in Manchester built a marketplace for second-hand textbooks between lectures. A charity worker in Bristol built a volunteer coordination tool in an evening.

None of them can write code. All of them built working software. Vibe coding made this possible — tools like Cursor, Lovable, Bolt, and Replit that turn plain English descriptions into functional applications. The barrier to building software hasn't just lowered. It's gone.

If you can describe what you want clearly enough, you can build it. Two years ago that sentence would have been absurd. Now it's just Tuesday.

But here's what nobody tells you: building the app was the easy part.

The gap

There's a moment that every vibe coder hits. The app works. It looks good. You've shown it to friends and they're impressed. You've iterated on the design, added features, polished the interface. You're ready to let real people use it.

Then you try to launch, and the questions start.

Is the app secure? Can someone steal your users' data? What happens when two people use it at the same time? What if the database goes down? Are your API keys exposed? Will it handle 100 users? 1,000? What about GDPR? What happens when someone submits a malicious string into your contact form? What if an API call fails at 2am and nobody is watching?

These aren't hypothetical concerns. They're the exact problems we see in every single app that comes through our door.

We've audited 50 vibe-coded apps built by real founders, most of them weeks from launching. The numbers are sobering: 94% had at least one critical security vulnerability. 86% had API keys exposed in client-side code. 82% had no input validation on user-facing forms. 76% had no rate limiting on any endpoint. 68% had no error handling whatsoever.

The apps worked. They just weren't safe for real people to use.

This gap shows up in every AI-built app we've looked at. It's not a reflection of the builder's competence. It's how the tools work.

Why AI tools build demos, not products

This isn't a failing of AI tools. It's a design choice. Every vibe coding tool is optimised for the same thing: getting you to a working prototype as fast as possible. That's the metric they compete on. "Build a SaaS in 10 minutes." "From idea to app in one prompt." "Ship your MVP this weekend."

Speed requires shortcuts. The AI skips input validation because it slows down development. It puts API keys in client-side code because that's the fastest way to make the feature work. It disables database security because setting up row-level policies adds complexity. It builds for the happy path — one user, perfect network conditions, every API call succeeding — because handling edge cases would triple the generated code.

These shortcuts are reasonable during prototyping. You're testing whether the idea works, not building a fortress. The problem is that the AI never goes back and closes them. It doesn't have a "now make this production-ready" mode. It doesn't say "great, the feature works — now let me add error handling, input validation, and security policies." The prototype is the output, and it's up to you to turn it into a product.

So you end up in a weird spot. The person who knows best what the app should do — the founder, the domain expert — is also the person least equipped to handle the technical hardening. The AI gave them the power to build. It didn't give them the knowledge to ship.

This is the gap. AI tools democratised building but not shipping. Everyone can create software now. Getting that software safely into the hands of real users still requires the kind of work that AI isn't doing for you.

What "production-ready" actually means

"Production-ready" isn't a feeling. It's not "it works when I test it." It's not "my friend tried it and nothing broke." It's a specific set of properties that separate software people can safely use from software that will eventually fail in ways that hurt your users and your reputation.

Secure. Every piece of user data is protected. Secrets are server-side only. Inputs are validated and sanitised. Database access is restricted to authorised users. Rate limiting prevents abuse and cost overruns. One security incident and your users are gone — along with their trust, and potentially your legal standing under GDPR.

Your app also needs to handle failure. When an API call fails, it shows a helpful message, not a white screen. When a session expires, it redirects to login, not into an error loop. When a third-party service goes down, the core app keeps working. Things will go wrong in production. The app needs to handle it without panicking.

You need visibility. Error monitoring catches issues before users report them. Analytics tell you which features matter and where users drop off. Uptime monitoring alerts you when the app goes down. Flying blind is how you find out your app has been broken for three days when a user emails you.

The deployment story matters too. Code lives in version control. Changes go through a pipeline that checks for errors before deploying. You can deploy a fix in minutes, not hours. You can roll back a broken deployment without losing data.

And finally, it has to work for actual humans. The landing page explains what the app does. Legal pages are in place. The app has been tested on real phones, not just a laptop browser. Error messages are written for people, not developers.

This work is boring. It feels like going backwards. But it's what separates a demo from a product.

The last 20% takes 80% of the effort

Every developer knows this ratio, and it applies with particular force to vibe-coded apps. AI tools get you to 80% at remarkable speed. The remaining 20% — security, error handling, performance, testing, deployment configuration — takes disproportionately longer, and it requires a fundamentally different kind of thinking.

Building is creative. You're describing features, iterating on design, seeing your vision take shape. It's addictive. Every prompt generates something visible. The feedback loop is immediate and satisfying: describe what you want, see it appear, refine, repeat.

Shipping is operational. You're auditing environment variables, writing validation schemas, configuring CI/CD pipelines, adding error boundaries to components that already work, writing database security policies, setting up monitoring dashboards. Nothing looks different when you're done. The app does exactly the same thing it did before — it just does it safely. There's no visual reward for adding rate limiting. Nobody notices when error handling works correctly. The work is invisible by design.

This is why so many vibe-coded apps never launch. The founder finishes building, hits the shipping phase, and doesn't know how to cross it. Or they know what needs to happen but don't have the skills to do it themselves. Or they hire a developer who's never worked with AI-generated code and spends three weeks trying to understand the codebase before fixing anything. Or — and this is the most common outcome — they keep building instead. More features. More polish. More prompts. Because that feels like progress in a way that configuring security headers doesn't.

The gap isn't a knowledge gap or a skills gap alone. It's a phase transition — from building to shipping — that requires different tools, different expertise, and a different mindset. And right now, nobody's optimising for that transition.

The security crisis nobody's talking about

There is a wave of insecure software about to hit the internet. Millions of apps are being built by people who don't know what input validation is, don't know their API keys are visible in the browser, and don't know that their database is open to any authenticated user.

This isn't their fault. They followed the AI's lead. The AI said the app was ready. It compiled. It ran. The features worked. There was no warning, no flag, no moment where the tool said "by the way, your Supabase tables have Row Level Security disabled, which means any user can read every other user's data."

It is ready — if you're the only person using it.

The moment real users sign up, real money flows through payment processors, and real personal data gets stored in databases, the stakes change entirely. And the tools that built the app aren't going to protect it.

We see this firsthand in every audit we run. The founders aren't careless. They're talented, motivated people who built genuinely useful applications. A fitness coach who built a client tracking app. A recruiter who built an applicant management system. A teacher who built a student progress dashboard. These are real problems being solved by people who understand their domain better than any developer ever could.

They just don't know what they don't know. The tools never told them anything was wrong. The app compiled, it ran, the features worked — so why would they suspect their database is wide open?

The security checklist we published covers the 15 most common vulnerabilities. But a checklist only helps if you know how to interpret it. "Enable Row Level Security" is straightforward advice. Actually writing the RLS policies, testing them across different user roles, and verifying they work correctly for every table and operation requires expertise the checklist can't provide.

This isn't the builders' fault. It's a hole in the toolchain. The tools that enable building don't enable secure building. That gap needs closing — either by the tools themselves or by people who specialise in closing it.

Why we started Last Hurdle

This is the problem we exist to solve.

We didn't start Last Hurdle because we think vibe coding is bad. We started it because we think vibe coding is a genuine shift in who gets to make software — and the gap between building and shipping is the only thing holding it back.

The name is literal. You've cleared every other hurdle. You had the idea. You validated it. You built the app. You designed the interface. You tested it with friends. The last hurdle is getting it production-ready, and it's the one that stops most people.

We're a small, specialist team. Every person here has spent years building and shipping software, and the last year specifically working with AI-generated codebases from every major tool. We've seen the patterns. We know where Lovable puts the secrets. We know which Cursor prompts produce inconsistent architecture. We know why Bolt apps break under concurrent users. We know what Replit apps need to migrate off-platform. We know how to take a v0 frontend and add the backend layer it's missing. We know how to harden a Windsurf project without rewriting it.

Our job is simple: take the thing you built and make it safe, stable, and ready for real users. Not rewrite it. Not redesign it. Not take it over. Just close the gap between where the AI left off and where production begins.

We don't think the answer is "hire a full development team." That defeats the purpose of vibe coding. The whole point is that you shouldn't need a team of engineers to build software. The answer is a focused sprint of hardening work — security, error handling, deployment, monitoring — performed by people who've done it hundreds of times and can do it fast because the patterns are the same every time.

The stories that keep us going

Every week, someone comes to us with a variation of the same story. They built something real. Something that solves a genuine problem they've experienced firsthand. And they're stuck.

A personal trainer built an app to manage client programmes and track progress. The UI was excellent — better than most apps built by professional teams. But the Supabase database had RLS disabled on every table, meaning any client could see every other client's data, including health information. One afternoon of hardening work fixed it.

A recruitment consultant built a candidate tracking system that automated half their workflow. Brilliant concept, clean interface, genuinely useful. But the API keys for the email service and the AI integration were both in client-side code. Anyone who opened browser dev tools could have used them to send emails on the company's behalf or run up the AI API bill. A few hours to move everything server-side.

A small charity built a donation management platform. It worked, it looked professional, and the team loved it. But there was no error handling, no input validation, and no rate limiting. The first time it got shared on social media, a bot hit the donation form thousands of times in a few minutes. A weekend of hardening prevented it from happening again.

These aren't stories about bad apps. They're stories about brilliant apps that needed the last 20% of work before they were ready for the real world.

What this means for you

If you're reading this and you've built something — genuinely built something, not just thought about it — you're further along than 99% of people with app ideas. That matters. The hard part of entrepreneurship used to be execution. Now it's shipping.

You've already done the creative work. You've already solved the problem. You've already built the thing. That takes vision, persistence, and more iteration than most people realise. Don't underestimate what you've accomplished.

But don't launch without closing the gaps either. The stories that give vibe-coded apps a bad reputation — the data breaches, the crashes under load, the exposed API keys — aren't stories about bad apps. They're stories about apps that launched too early, without the hardening work that makes them safe.

Here's where to go from here:

If you want to assess your own app, start with our production readiness checklist. It's a 15-point scoring system that tells you exactly where you stand. Pair it with the security checklist for a thorough self-assessment.

If you want to understand the cost, read our honest breakdown of fixing costs. Most apps cost between £500 and £5,000 to get production-ready. The range depends on complexity and how many issues the AI left behind.

If you want to do it yourself, follow the production checklist. It's five phases, in order, covering everything from security to launch readiness. It's the same process we follow with clients, made public because we believe the knowledge should be accessible to everyone.

If you want help, request a free audit. We'll review your app and send a 5-point security snapshot within 48 hours. No commitment, no sales pitch. Just an honest assessment of what needs fixing.

If you're ready to ship, tell us about your project. We'll send a scoped proposal within 48 hours — fixed price, clear deliverables, and a timeline measured in days, not months.

The future is building

We believe something genuinely important is happening right now. The ability to create software is being distributed to everyone. Designers are building their own tools. Domain experts are building solutions for their own industries. Teachers are building educational apps. Healthcare workers are building patient management systems. Founders are testing ideas at the speed of thought.

The constraint is no longer "can you build it?" The constraint is "can you ship it?"

That constraint is solvable. The work required to take a vibe-coded app from prototype to production is well-understood, repeatable, and finite. It's not a rewrite. It's not a six-month project. It's a focused sprint of hardening work that follows the same pattern every time because AI tools make the same shortcuts every time.

AI tools will get better at this. Probably soon. But "soon" doesn't help the teacher in Birmingham who's trying to launch her classroom app next week. The apps being built today — by people with real problems to solve and real users to serve — can't wait for the tools to catch up.

Today, if you've built something and you're stuck at the last hurdle, we're here. That's the whole pitch. Not "we'll build it for you" — you've already built it. Just: we'll help you ship it.

Everyone can build now. We're here to make sure they can ship.