Vibe-code to production
Vibe-code to production software in Melbourne
We turn Claude, Cursor, Windsurf, v0, Replit, Bolt, Lovable and GitHub Copilot prototypes into production software in Melbourne and across Australia. The build you shipped in a weekend is the starting point, not the problem. We port the parts that work, rebuild the parts that cannot stand up to real users and put the whole thing on a database-first foundation so it keeps working as the business grows. We finish the work. We do not throw it away.
Most prospects arrive with a working demo, a user interface that looks right and a quiet worry that the weekend of prompts did not leave them anything they can actually ship to paying customers. That is normal. The point of vibe-coding is to prove the idea, not the foundation. The foundation is where we start.
What vibe-code usually gives you
Most AI-assisted prototypes land in the same shape. A working demo you can click through. A user interface that feels right. A backend that does enough to pass the Monday morning walkthrough. The parts that are there are real work, and we treat them as real work.
What tends to be missing by the time a real user arrives:
- No data model that survives a second user. The prototype reads and writes through whatever shape the generator guessed at. Add a second account, a second tenant or a second workflow and the model falls over because there was never a plan for it to hold more than one.
- No real authentication. A hardcoded login, a cookie that trusts whatever the browser sends, or a prompt that assumes one user and one session. Fine for a demo; fatal the first time a paying customer logs in alongside another one.
- No deployment pipeline. The thing runs on a laptop, on a free-tier Replit or on a Vercel preview URL the founder does not want to hand to anyone. No staging, no production, no repeatable way to push a fix.
- No tests, no type discipline, no error handling. If it breaks silently, nothing tells you. If a field changes shape, the code keeps running and quietly loses data. The first real bug is the one a customer reports.
What production actually requires
Production software is not a vibe-coded prototype with more polish. It is a different foundation underneath the same screens. The pieces that have to exist before a real customer can use it safely:
- A real data model. Normalised tables, proper keys, indexes where they matter, constraints that keep bad data out. The model is designed for the workload the business actually runs, not for whatever screen the generator drew first.
- Authentication built for more than one user. Real sessions, password reset, multi-factor authentication where it is warranted, single sign-on where a team already runs Microsoft 365 or Google Workspace. Role-based access so a customer can never see another customer's records.
- Hosting, version control and a deployment pipeline. Staging, production, one-command deploys, rollback when something goes wrong. Branches, pull requests and review live in the same toolchain rather than a folder called
project-final-v3. The founder stops being the only person who can ship a fix on a Friday night, and mistakes get caught on staging before customers meet them. - Backups and monitoring. Automated backups, tested restores and someone notified when things break. Silent failures are the hardest to catch later; production software surfaces them before the customer does.
If you want the full picture of how we run an engagement, read how we work. Short version: small team, weekly demos, no three-month silences.
How we approach it
Discovery: what did you ship, where are the gaps
A half-day read-through of the prototype. We look at what works, what is broken and where the scale walls will hit. You get a plain-language assessment, not a pile of technical jargon. If the answer is that rebuilding is cheaper than rescuing, we say so on the same page.
Port the good parts
Screens, flows and product decisions you already got right stay. We lift them into a proper project with types, tests and version control. The weekend of prompts gave you clarity about what the product should do; that clarity is the asset we preserve.
Rebuild what cannot stand up
The data model, authentication, deployment pipeline and anything else that was glossed over for the demo. This is the part that makes it production software instead of a clever mockup. We run the rebuild alongside the port so the team does not lose weeks watching a staging branch.
Database-first from here on
Every new feature reads and writes through the database, not around it. Reports, integrations and the next AI-assisted iteration all run against the same model. The team carries on adding features against a codebase that will not surprise them six months in. We use AI coding tools alongside your team to ship faster; they run against the production codebase, not a side branch.
We have been shipping and supporting custom software since 2007, and we are still around for the phase-two bug and the 2028 feature request. A weekend of prompts cannot promise that. See who we are.
When to just rebuild
Not every prototype is worth saving, and pretending otherwise wastes your money. The honest test is whether the shape of what you have matches the shape of what the business actually needs.
If the prototype is a user-interface sketch sitting on a single screen of fake data, there is nothing to port. The data model has to be built from scratch, and dragging the old interface along only means fighting early decisions nobody remembers making. If the backend is a string of one-shot calls that happened to work for the demo, rebuilding is faster than untangling.
Sometimes the honest rebuild is not custom software at all. If the shape of what you are building fits a no-code platform like Bubble, Xano, Retool or Softr, we will tell you that too. Those tools earn their place when the workflow is generic enough to fit their primitives, the data model is shallow and the audience is small. Custom software earns its keep when the rules are specific to how your business actually operates, and those rules will not bend to someone else's template.
We tell you which side of the line your build sits on, and we tell you honestly. Sometimes the best value we add is cutting a month of rescue work and rebuilding properly in the same window. The clarity the vibe-code gave you is the real asset; the code is replaceable, the product decision is not.
What we see
The named cases will land here as they ship. In the meantime, Claude prototype to production: what actually has to change collects the pattern across the rescue engagements we have run so far. What the prototype usually proves, what it usually misses, and the four things that always change between demo-grade and production-grade. The rest of this section describes the shape we see week to week.
What usually arrives. A single-screen prototype on Claude or Cursor that works for one user. A Replit project with hardcoded data. A Bolt or Lovable demo that is beautiful and answers no real questions about persistence, users or billing. The founder or the product person knows the idea is right. Nobody has the stomach to keep prompting until it becomes a system people can run a business on.
What usually ships. A proper project with a data model, authentication, deployment pipeline, tests and backups. Mostly the same screens, mostly the same flow, a different foundation underneath. The team carries on adding features the same way they started, now against a codebase that will not surprise them in six months.
The work overlaps heavily with our Excel to web app work and our custom CRM development work, because the substrate is the same: a messy first version that proves the idea, and a disciplined second version that carries it. When the prototype is a customer-facing app rather than an internal tool, the work also overlaps with our client and staff portal work; the foundation is the same database underneath.
Most of the prototypes that arrive are operational software for fields where the work is physical and the office stack has not caught up: trade and field service businesses running job sheets on a phone, allied health practices tracking CPD and clinical hours. The Cursor build proves the team wants the tool; production is what lets it survive a second user.
Common questions
How long does this take?
Most builds land between six and ten weeks to a production-ready first release. The first two are discovery and planning; then we port what works and rebuild what does not, in parallel. We ship the core workflow first, put it in front of a few real users and iterate from there. Nobody waits three months staring at a specification before anything goes live.
What does it cost, shape-wise?
It depends more on what has to be rebuilt than on what has to be ported. A well-shaped Cursor project with a coherent data model that just needs authentication, deployment and tests is cheaper than a Claude sketch with no persistence. We give you a fixed range after the half-day discovery rather than a number over email. We will not hide surprises in phase two.
Can you just review what I have and tell me if it is any good?
Yes, and that is how most engagements start. A half-day technical review, written up in plain English: what is solid, what is likely to break first and what it would take to put the rest on a production footing. If rebuilding is the right call, we say so. If you have more than you think, we say that too. The review stands on its own whichever way the decision lands.
What AI coding tools do you work with?
Claude, Cursor, Windsurf, v0, Replit, Bolt, Lovable, GitHub Copilot and whatever else shipped your first version. We use them ourselves, so we know where each one lies about what it has actually built. If the tool you used is not on that list, bring it anyway. The work of turning a prototype into production software is largely the same regardless of which tool wrote the first draft.
How do you know if there is enough to save?
We look at three things. Is the data model coherent enough to grow, or was it built around a demo? Are the important flows real code, or scaffolding that happens to display data? Is the user interface a product decision, or a placeholder nobody loved? If two of those hold up, there is plenty to port. If only the interface survives, we usually rebuild the backend from scratch and keep the front-end work.
Got a prototype you want to ship?
Start with a half-day technical review. We read your Claude, Cursor or v0 project and tell you what is there and what it will take to get it to production. No sales pitch, no strings.