# Built it with Claude Code, Lovable, or Cursor? Let's make it production-ready.

> You've built something real with Claude Code, Lovable, Cursor, or Bolt. Before it goes in front of your customers, it needs to survive them. We find the edge cases, close the security gaps, and add the testing, hosting, and support that make it ready to launch.

- URL: https://www.happen.software/prototype-to-production
- Publisher: Happen Software (https://www.happen.software/)

> You know your business and your customers. We know how to build software. Let's make magic together.

## The demo worked. Now what?

Maybe you're a founder who built your product in Lovable over a few weekends, and the first users love it. Maybe someone in operations built a tool with Claude Code that now saves the team hours. Either way the demo works, and the step from there to something real customers rely on is where it stalls.

- **You built a product**: It works, people want it, and you're ready to take it to market or roll it out to your clients. You need to know it won't fall over, leak data, or embarrass you the first time a real customer does something unexpected.
- **You built an internal tool**: Your team relies on it, and you'd like to get back to your actual job. You need it to run properly without becoming your second role.
- **You've inherited it**: You're now accountable for something you didn't design, in a stack you may not use, hosted on an account you don't control. You need to know what you're signing up for.

## What the prototype shows vs. what production needs

AI tools are brilliant at getting from nothing to a working demo. They build the happy path. They don't ask what happens when a payment fails halfway, two customers edit the same record, or someone pastes in something nobody expected. Very little of this exists in a prototype, and almost none of it is visible until a real user finds it.

| What the prototype shows | What production needs |
|---|---|
| It works on the happy path | Edge cases handled: bad input, timeouts, double submits, partial failures, and clear errors when something goes wrong |
| It works for the person who built it | Proper sign-up, sign-in, roles, and permissions, whether for your customers or your company's identity system |
| One user at a time, on a fast connection | Load and abuse tested, so it holds up when real customers, and bots, arrive |
| It connects to the data | Each customer sees only their own data, with encryption, backups, and a retention policy |
| API keys pasted in to make it run | Secrets stored and rotated properly, never in code or a chat history |
| Hosted on an account someone signed up for | Environments and deployments you own, that your team can run, audit, and redeploy |
| It worked when the demo was recorded | Automated tests, so the next change doesn't silently break something else |
| A pile of packages, installed once | Someone watching for vulnerabilities and updating dependencies, indefinitely |
| It runs | Logging, monitoring, and alerts, so you know it's broken before your users do |
| It calls an AI API | A budget, usage limits, and a plan for when the model or its pricing changes |

If it's customer-facing, takes payments, or touches anything regulated, none of what production needs is optional.

## Built to survive real users

Your first customers will find every rough edge, usually on day one. When what you've built is going in front of paying customers or your clients, this is what we test and put in place before they get there.

- **Edge cases and errors**: We try to break it the way real users will: odd input, double clicks, dropped connections, expired sessions. Every gap gets fixed and covered by a test.
- **Security testing**: Checks for the holes AI tools commonly leave: exposed keys, open database rules, broken access control, and one customer able to see another's data.
- **Performance and load**: Load tests against realistic traffic, so a launch, a newsletter, or a big client onboarding doesn't take it down.
- **Payments and billing**: Failed cards, retries, refunds, webhooks that arrive twice or not at all, and plan changes mid-month, handled properly before money is involved.
- **Accounts and data privacy**: Reliable sign-up, password resets, and email delivery, plus GDPR basics such as data export, deletion requests, and clear consent.
- **Uptime and support**: Monitoring, alerts, backups you've actually restored, and a plan for when something breaks at 2am, run by us under SLA if you'd like.

## Three ways to get it live, one honest recommendation

We treat your prototype for what it is: a very good specification that happens to run. It proves the idea, shows exactly how it should work, and comes with someone who understands the problem. That's the hardest part of any software project, and you've already done it.

### Harden it

When the readiness review shows the existing code is a sound base, we keep it and add what's missing: edge-case handling, authentication and permissions, secrets, data protection, tests, deployment pipelines, hosting, monitoring, and documentation.

Best for: solid code in a stack your team can support.

### Rebuild it properly

When the prototype is the right idea in the wrong shape, we rebuild it cleanly, in a proven stack that can be supported for years, using the prototype as the blueprint. You pay the cost once and end up with something built to scale.

Best for: core products, long-lived systems, or a stack that won't scale.

### Keep building, with guardrails

If the person who built it has a clear vision and is enjoying it, let them keep going. We set up the foundation that makes their work sustainable: a proper repository, a deployment pipeline, tests that catch breakage, and review habits that keep quality high as the tool grows.

Best for: a sponsor who wants to keep ownership of the idea.

### And sometimes the answer is "don't"

Not every prototype should become a product. Some should stay prototypes, used by a small team who understand the limits. Some should be replaced by software you can simply buy, now that you know exactly what you need. We'll tell you if that's the case, because it's cheaper to find out early than after it's gone live.

## From prototype to production, without the guesswork

Every stage has a fixed scope and a clear deliverable, and you decide whether to go further.

1. **Free prototype review** (30 minutes · Free): Show us what you've built. One of our engineers talks through what it does, who uses it, and what it touches, and gives you an honest first read.
2. **Production readiness review** (1–2 weeks · Fixed fee): We go through the code, data, hosting, and security, try to break it the way real users will, and answer the go-live questions in writing. You get a clear recommendation (harden, rebuild, keep building with guardrails, or don't) with the cost and risk of each.
3. **Make it production-ready** (Typically weeks): We harden or rebuild it, or work alongside your builder, and ship in increments you can see every week. Your users and data move across safely, and launch day is a non-event.
4. **Hand over or run it** (Your choice): We hand it to your team with documentation and code walkthroughs, or we keep it secure, monitored, and improving under an SLA.

## Nine questions to settle before you go live

1. **Who is the named owner?** Today and in two years. A person, not a team alias, who can support the stack it's built in.
2. **What happens when things go wrong?** Bad input, a failed payment, an API timeout, two people editing at once. Has anyone tried?
3. **Where does it run?** Can you access, audit, and redeploy it without the original builder or their account?
4. **What data does it touch?** Are you allowed to put that data into it? Is it stored anywhere you didn't intend?
5. **What credentials does it use?** Where are they kept, and who can rotate them?
6. **How will you know when it breaks?** Is there logging, monitoring, anything that alerts a human?
7. **What happens when it needs to change?** Is there a test suite, a way to review changes, and a way to roll back?
8. **What does it cost to run?** Hosting, services, and AI usage, every month. What stops that bill growing unnoticed?
9. **Is it worth owning?** Or is there a product that already does this, which someone else would maintain for you?

## We live on the unglamorous end of software

- **Since 2016, the part after the demo**: We've spent a decade building and running the systems businesses depend on. Some of the platforms we built in 2016 are still in daily use, and still looked after by us.
- **We run our own software**: We build and maintain our own products, including Kanera and Productify.ai, so we know first-hand what it costs to keep software secure, fast, and online year after year.
- **Engineering discipline**: Clear specifications up front. Small, reviewable steps. Tests on every change. Nothing ships that our engineers don't understand.
- **You own it**: You own the application, its data, and its IP. Our goal is to hand back something your team genuinely owns and can run without us.

## Frequently asked questions

### Which AI tools do you work with?

Any of them: Lovable, Claude Code, Cursor, Bolt, Replit, v0, Codex, ChatGPT, or plain scripts written with AI help. What matters isn't the tool, it's what was built: the code, the hosting, the backend services, and the data.

### We're about to launch to customers. Is that a fit?

Yes, that's one of the most common reasons people come to us. If you've built a working product with AI tools and want to put it in front of paying customers or roll it out to your clients, we'll make sure it's ready before they see it.

We're not the right partner for ideas with nothing built yet. The prototype is what lets us move fast.

### How do you find the edge cases?

We read the code and the data model, then try to break it the way real users will: unexpected input, slow or failing third-party services, many users at once, expired sessions, payments that fail halfway, and the things nobody planned for. Every fix gets an automated test, so it stays fixed as you keep building.

### Do we have to throw away what we built?

Not necessarily. Sometimes the code is a sound base and we harden it. Sometimes it's better to rebuild in a stack your team already supports. Either way, the prototype is never wasted: it's the best specification you could have, because people have already used it.

### Our technical team doesn't use the language it was built in. What now?

That's one of the most common situations we see. There are three options:

1. Adopt it: your team learns the stack, which makes sense for a core, long-lived system.
2. Rebuild it: rewrite it in the stack your team already knows how to deploy, monitor, and secure.
3. Fence it: run it as a small, isolated service with a named owner and clear inputs and outputs.

The readiness review tells you which fits, and what each would cost.

### Will you take it away from the person who built it?

Only if they want us to. If the builder has a clear vision and enjoys the work, we'd rather work alongside them: setting up the repository, pipeline, tests, and practices that let them keep building safely, with every change checked before it reaches real users.

### It was built in Lovable (or similar). Can it move to our own hosting?

Usually, yes, but it's more than copying code. The front end can often be exported, while users, data, files, and secrets live in a hosted backend and need a proper migration. We plan and run that migration, and verify nothing is lost on the way.

### What does it cost?

The first conversation is free. The production readiness review is a fixed fee agreed upfront, and it ends with a costed recommendation, so you know the price of hardening, rebuilding, or running the tool before you commit to anything bigger.

### Is it safe to share our prototype and data with you?

Yes. We regularly sign NDAs and DPAs, complete security questionnaires, and can work with sample or masked data during the review. Part of what we check is whether the prototype itself is already exposing data it shouldn't.

## Get in touch

Built something with AI that's ready for real users? Book a free 30-minute prototype review with one of our engineers. Whether it's going to your customers or your team, let's make sure it's ready before launch day.

Contact: https://www.happen.software/contact or sales@happen.software