The demo ran perfectly. Everyone in the room was impressed. Someone built it in a week with AI tools (Cursor, Replit, or Claude Code). Then a leader asked when real users could depend on it, and nobody had a written answer.
That question is where the real build begins. Something already works on a screen. What remains is a maintainable system people can rely on, with a written definition of done both sides can check before production work starts.
The gap between this demo and software ready for real users is mostly a clarity problem, not a coding problem. Settle it first, and the build has a clear target. The Scoping Conversation is how you settle it.
Speed Gets You the Demo. Scope Gets You Real Users.
The Scoping Conversation starts because speed already got you a demo. Speed is the point of AI-assisted development, and it is also why you can run that conversation soon after the first walkthrough.
When language models and AI agents turn plain-English prompts into working screens{1}, the time from idea to something you can click through collapses. That speed is useful, and the business case for vibe coding is real.
Production software keeps that speed and adds what real users need once they depend on the system. The main flows must keep working under real traffic, with scalability matched to expected volume. “Done” must be something your organization can approve with confidence. The demo showed what is possible. The Scoping Conversation decides what must be true before real users rely on it.
Scope drift is the predictable next pressure. The prototype proves idea A; leadership gets excited and wants ideas B and C before launch. Put that energy into a written scope: what ships for real users in this release, what waits for the next one, and what each addition costs if it moves in. Excitement becomes a roadmap instead of an open-ended build.
Ownership at handoff is the gap teams underestimate. Someone built the demo inside a hosted AI builder tool (Replit, Vercel, or similar). Before real users arrive, name who holds launch access, passwords and keys, and source code in version control when the engagement ends. The prototype still works; the conversation sets up your team to run what comes next.
Operating conditions are where demos quietly fall short. Name the main user flow, authentication behavior, error handling for the failure states real users will hit, and a data plan sized for expected volume. Put those answers in writing before production work starts, and a fixed fee can attach to an outcome both sides can verify.
Why Fixing the Price Is a Strong Start, Not the Whole Answer
A fixed fee is where most executives start once those decisions are on the table, and that instinct is right: cost should be predictable. Alone, the number is only half the picture. Pair it with a written definition of what you get: whether the system is ready for real users, and whether your team can operate it after handoff.
That definition has to be specific and checkable. Name what the finished system must do, and how your team will confirm it works{2} on your accounts: pass-or-fail checks, code review on critical paths, and unit tests where the business risk is highest. When “done” still means “the demo works,” the price may be fixed, but the deliverable is still informal.
That is what SHIP puts in writing before the build. You are not buying “production-ready software” in the abstract. You are buying a defined path from this working MVP demo to a maintainable system real users can depend on.
That path gets concrete the Monday a weekend campaign prototype wins the room and leadership asks when real users can depend on it.
When a Weekend Campaign Prototype Wins Monday
Your growth team built a campaign tracker or lead-capture form over the weekend. Monday, leadership asked when real customers or sales reps can depend on it. The idea is proven. You already have this prototype. What remains is the Scoping Conversation: write down what must be true before real users depend on it, while Monday’s question still has a deadline.
Production asks for clearer answers in writing. Which reps or segments see which data? What happens when a CRM sync or form submission fails? How does the system behave under real campaign volume? Who operates it after handoff? Write those answers down before production work starts.
SHIP keeps that Monday answer concrete. Scoped outcome names what the tracker or form must do for real users. Hard acceptance makes “done” something your ops team can check with a pass-or-fail test. Independence puts code, passwords and keys, and launch access under your team. Price fixed attaches a fixed fee to that written outcome once scope is clear.
unosquare‘s week-one Discovery maps this prototype you already have, writes acceptance criteria, and returns a fixed-fee production scope before the build begins, so the Monday win becomes a clear path for real customers and reps.
SHIP: Four Decisions Before Production Code
The Monday campaign win only becomes a production path when four decisions are written down for the board, the operations team, and the budget owner. unosquare settles each one before the build starts. That is SHIP: Scoped outcome, Hard acceptance, Independence, and Price fixed once scope is clear.
| Letter | What it means for real users | What shows up in writing |
|---|---|---|
| S: Scoped outcome | What the system must do once people depend on it | A clear description of the finished system under real use. Scalability matches actual user volume, not demo traffic. Your team is named as the ongoing owner. Authentication, failure paths, and traffic expectations are named in scope |
| H: Hard acceptance | “Done” is checkable, not just a polished walkthrough | Clear pass-or-fail conditions your team can run on your accounts, not only a slide demo. Error handling covers failure paths alongside the path that works when everything goes right: bad logins, slow responses, unexpected input, and connections that return bad data |
| I: Independence | Your team runs, changes, and replaces the system without asking the original builder | Code in version control, launch access, and passwords and keys at handoff; documentation for operators; a handoff plan that assumes your team is the ongoing owner of a maintainable codebase |
| P: Price fixed | Fee set once scope is clear; new ideas get priced, capped, and scheduled through a defined change process | Fixed fee after the Scoping Conversation; written process and financial cap for out-of-scope changes; fee tied to SHIP decisions, not an open-ended “make it production-ready” promise |
SHIP names the decisions. Before a single line of production code is written, those decisions have to be settled in a Scoping Conversation your team can actually run.
Run the Scoping Conversation Before a Single Line of Production Code Is Written
You know this prototype works. SHIP already named what must be true for real users. What you need next is a Scoping Conversation that attaches a fee once scope is clear.
In week one, unosquare maps this prototype you already have, defines what the finished system must do for real users, and writes the acceptance criteria before anything is built. See how week one works, including what unosquare commits to in writing before the build begins.
That conversation still has to name the operating conditions real users will create before the fee attaches.
What the Scoping Conversation Must Settle Before Real Users
Once SHIP is written down, the build still has to deliver against real operating conditions. The Scoping Conversation turns those conditions into handoff requirements your team can use from day one.
| Decision area | What the conversation must name |
|---|---|
| Login and access | How authentication and sessions behave under real use. Wrong passwords, login outages, unusual account activity, and permission conflicts are checked on your accounts before real users arrive |
| Failure behavior | Error handling when a connected service fails, a response takes too long, input is unexpected, or a connection returns bad data |
| Pass-or-fail proof | Named outcomes for login failure, volume spikes, and partner outages; code review and unit tests where risk is highest; proof operations can check at each delivery checkpoint, not a demo that only works in the room |
| Capacity for expected volume | Users, activity, and data sizing for a year of real use, not demo traffic. Scalability targets match that plan |
| Visibility | Dashboards, alerts, and monitoring{3} matched to how the system actually behaves |
| Independence at handoff | Code, launch access, passwords and keys, and a full record of every change. Your team launches updates, can refactor safely, and modifies the system without vendor calls. |
Those rows turn SHIP into checks your operations team can run. The evidence for each one comes from the delivery phases.
How Outcome-Based Delivery Gets You There
The Scoping Conversation before real users is not a single meeting. The decision areas above run through four delivery phases, each producing evidence the next phase needs.
Discovery | Week 1
Discovery answers one question before budget moves: can this vibe-coded prototype (or early MVP) survive the conditions real users will create?
The demo probably ran inside a hosted AI builder tool with one path that works when everything goes right and a small dataset. Discovery checks the rest under tougher conditions.
unosquare maps this prototype against your actual systems, runs the authentication and connection paths your reps or customers will hit, and documents what breaks when passwords fail, a CRM sync slows down, or ten reps pull live campaign numbers at once.
You leave with a scoped outcome written in business terms, draft acceptance criteria your operations team can read without a walkthrough, and pricing options. There is no obligation to continue. If the prototype cannot support a definition of done that real users can depend on, you walk away with that evidence before a build starts.
Solution Architecture | Week 2
Week 2 turns Discovery evidence into a commissioned outcome. Leadership excitement from the demo gets sorted into what ships for real users in this release and what waits for the next one. unosquare finalizes acceptance criteria your team can run on your accounts, locks design and commercial terms together, and fixes the fee before production work begins.
When someone asks what “done” means after the Monday campaign demo, the answer is a test your ops team can run, not a replay of the room demo. Scope, price, and definition of done are settled in writing before week three.
Build | Weeks 3 to 11
Build proves the scoped outcome under conditions that resemble daily use, not a controlled demo session. Production work follows the agreed scope. Each delivery checkpoint runs the acceptance criteria on your accounts: login under expected volume, failure behavior when a connection returns bad data, and the paths operations named in Discovery. Working software ships at each delivery checkpoint.
Deploy and Handoff | Week 12
Deploy is when the system stops living in a builder-tool account and becomes something your team owns.
unosquare transfers source code, launch access, every API key and password the system needs, documentation written for the people who will operate it, and structured knowledge transfer so routine changes do not require a vendor call.
Your team can operate the system independently from day one. The typical timeline is 8 to 12 weeks. Builds start as low as $100K, fixed fee, scoped before code is written. If delivery runs over the fixed timeline, that overrun is unosquare‘s cost, not the client’s.
By week twelve, the prototype that impressed the room is a system your team owns and real users can depend on. Which path you take to that handoff depends on the situation you are in today.
Decision Guide
| Situation | Recommended Path |
|---|---|
| Internal tool, limited users, no sensitive data | Internal team with a clear owner and a written definition of done |
| Customer-facing product that needs to scale | Commission a fixed-fee production build |
| This prototype proved the idea; real users are next | Discovery engagement: Scoping Conversation with agreed scope and written acceptance criteria |
| Board AI mandate with a production deadline | Start with Discovery to settle scope before build begins |
| Internal build that missed delivery checkpoints and timeline pressure | Evaluate existing work in Discovery, then rebuild or reshape with fixed scope |
If one row in that table matches where you are today, start the same way: map what you already have, run the Scoping Conversation, and get scope and price on paper before production work starts.
One Week. This Prototype Scoped and Priced Before Real Users.
If your situation matches a row above and you already have this vibe-coded prototype, unosquare can map it, run the Scoping Conversation, and return a fixed-fee scope with written acceptance criteria, all in week one, with no commitment required. Start Discovery with what you already have.
Frequently Asked Questions
What does “vibe coding to production” actually mean for a business leader?
It means moving from this prototype you already have to software real users can depend on day to day. Vibe coding tools get you to a convincing walkthrough fast.
Production starts when scope, acceptance, and ownership are settled in writing (the bar SHIP names) before anyone starts production work. The Scoping Conversation proves you know what you are buying before real users depend on it.
How long does it take to go from a vibe-coded prototype to production?
With a defined scope and a structured build process, engagements typically run 8 to 12 weeks from Discovery through Deploy and Handoff. Discovery finishes in week one, solution architecture and pricing are fixed in week two, the build runs through week eleven, and production handoff wraps in week twelve.
Do we need to rebuild the entire prototype?
Not necessarily. Discovery looks at the work you already have and decides what to carry forward, what to refactor, and what to rebuild. The goal is the fastest responsible path to a maintainable system ready for real users, not a clean-slate rebuild by default.
What transfers at handoff once the Scoping Conversation is settled?
Everything SHIP’s independence decision names. Full transfer at handoff includes the code with a complete, readable record of every change; the automated build and deployment process; every API key and password the system uses; and any data generated or processed during the build.
The system is documented and built so your internal team or any future partner can extend it, and you do not need unosquare on retainer to keep the system running.
What is the cost to start?
Builds start as low as $100K, scoped and priced before production work begins. If delivery runs over the fixed timeline, that overrun is unosquare‘s cost, not the client’s. Discovery maps the prototype you already have and returns an agreed scope document with pricing options, with no commitment to proceed.
If your prototype has already proved the idea, the next step is the Scoping Conversation: turn this prototype into a scoped production commitment with written acceptance criteria, fixed fee, and independence at handoff before the build starts and before real users arrive.
Start Discovery with the prototype you already have to see what carries forward, what needs to change, and what delivery for real users would cost.
References
- MIT Sloan. (n.d.). How generative AI affects highly skilled workers. MIT Sloan.
https://mitsloan.mit.edu/ideas-made-to-matter/how-generative-ai-affects-highly-skilled-workers - NIST. (2021). Guidelines on minimum standards for developer verification of software. NIST CSRC.
https://csrc.nist.gov/pubs/ir/8397/final - Google. (n.d.). Monitoring distributed systems. Google Site Reliability Engineering.
https://sre.google/sre-book/monitoring-distributed-systems/
Our Editorial Standards
unosquare is committed to providing accurate, well-researched B2B software delivery information. Our editorial team reviews all content for accuracy and relies on reputable sources including industry analysts, technology standards bodies, academic institutions, peer-reviewed research, and established enterprise software providers. All references are verified for accessibility and relevance at the time of publication.
We strive for accuracy in everything we publish, but we recognize that mistakes can occur and information can become outdated as delivery models, pricing benchmarks, and technology standards evolve. If you notice an error or outdated information, please contact us so we can review and update our content.
Important Disclaimer
The information provided on this website is for general informational and educational purposes only. It is not intended as, and should not be interpreted as, professional legal, financial, or technical implementation advice. Always consult with qualified technology advisors, legal counsel, or appropriate professionals before making decisions about software investments, vendor selection, or delivery models. unosquare does not assume liability for actions taken based on the information presented on this site.
