The demo worked. It almost always does.
Someone shares a screen, the main path runs clean, and the screens look like the software your team described last week. People nod. Someone says it already feels like a product.
Then procurement asks what the build must include that the walkthrough never showed.
That question shifts the conversation from tools to outcome. You are no longer asking whether vibe coding works as a demo trick. You are asking whether the deal covers a system your team can run live, or only the polished path everyone just saw.
AI tools are not the problem. Missing production work in the deal is.
The limitations of vibe coding show up there: agree what “done” must include before you price the full build. Then the fixed fee covers what live operations require: testing under real use, observability (monitoring and alerts), security, documentation, and ownership your team can run.
What the Polished Demo Did Not Show
The polished path already won the room. Then procurement asked what the walkthrough never showed.
Vibe coding is not a put-down. Andrej Karpathy, the AI researcher who popularized the term{1}, used it to describe AI-assisted coding driven by natural language prompts and instinct rather than a formal specification.
AI coding assistants (Cursor, GitHub Copilot, Lovable, ChatGPT, Gemini) can take an idea from conversation to working prototype in hours. Speed is the point. The buying question is whether the deal also covers the production work a live system needs.
A complete production-ready build covers more than the polished path. It names who can access what{2}, what happens when someone enters bad or unexpected data (input validation and error handling), and checks that run before each release{3}. It also covers observability through monitoring and alerts{4}, plus ownership documentation your team can use once the system is live.
Demos follow the scenario that was described. Two builds can look identical on screen when nobody has checked whether that work is in scope.
Take a campaign lead-capture build your growth team prototyped over a weekend. Friday’s walkthrough shows clean submissions and neat dashboards. Monday someone asks who can depend on it under real launch traffic.
Who can see lead data? What happens when a marketing tool fails mid-campaign? Who owns the martech stack after handoff? Those answers were never written into scope. That is where vibe coding limitations meet MVPs that still need a production path.
Five Signals That Production Work Is Already in Scope
You know that work is already commissioned when five signals show up in the same scoping conversation as the polished screens:
- Checks that run before each release are visible, not only the interface.
- Someone can walk through what happens when a user enters bad or unexpected data.
- Code control today is clear, and a transfer plan is written in.
- Monitoring is defined for when something goes wrong.
- Dated security scan results are linked to this build.
Those signals mean the missing production work is already commissioned. A budget cap alone does not name the work the walkthrough skipped. The fee only stays reliable when that same work sits inside a fixed outcome.
What Makes Fixed-Fee Delivery Actually Reliable
Those five signals only count when the missing production work sits in the same definition of done as the polished screens. Until then, a fixed price is only a budget boundary.
A fixed-fee contract with clear acceptance criteria makes the fee reliable. When “done” is spelled out in terms you can check, the fee covers the complete build the business meant to buy, not only the screens that impressed the room.
Three contract structures keep that work from drifting out of scope:
- A production acceptance plan attached to the contract as an enforceable exhibit, not described informally in an email
- Milestone payments tied to deliverables you can verify, not calendar dates
- Explicit change-order limits so scope additions stay intentional and visible
Contract structures hold that definition steady. They still need a shared list of which production work belongs in it. Before production code starts, that list has to show up as evidence you can see beyond the demo.
See the Evidence Beyond the Demo
If the conversation is still happening on a shared screen, bring the completeness proof into the same meeting. See how unosquare‘s week-one prototype does that: scope, price, and what “done” means are named in the same conversation, before production code starts. No commitment required to see it in action.
BUILT is the shared list that turns “the demo looked complete” into missing work you can name, price, and accept before that code starts.
The BUILT Framework: Production Work the Demo Skipped
A polished demo proves the main path. Before the price is set, the deal still needs five named proofs. BUILT names the production work the walkthrough skipped: Bound scope and a protected fixed price, Underlying security and compliance, Independent ownership and handover, Live production readiness, and Traceable fix records.
| Letter | What it means in the deal | What the walkthrough skipped | What shows up in the deal |
|---|---|---|---|
| B: Bound scope and protected fixed price | Bound scope spells out what will be built, what “done” means per deliverable, and how acceptance will be tested, so the fixed fee has a clear definition of done | A production acceptance plan attached to the contract: security scan results, proof that release checks passed before each milestone, monitoring and alerts, speed and load targets, release requirements, handover documentation | Scope, price, and definition of done in the same document; milestone payments tied to deliverables you can verify; change-order limits written into the agreement |
| U: Underlying security and compliance | Security work in AI-assisted builds is one commissioned deliverable alongside testing, monitoring, and ownership docs, not a post-launch cleanup, and it aligns with maturity practices such as OWASP SAMM{5} | Dated reports from scanning the code and outside packages it relies on, a compliance checklist aligned with privacy rules that apply to your business (such as GDPR{7}), and fix plans with owners and dates for findings like passwords or keys left in the open, weak input validation, and unsafe outside packages{6} that create security vulnerabilities | Dated scan outputs linked to this build; compliance checklist with owners and fix-by dates; clear mapping to standards that apply to your business |
| I: Independent ownership and handover | Code control and day-to-day independence match what the contract says about ownership; handover is a condition of final payment, not a follow-up promise | Code transfer to accounts your company controls, release steps written for your systems, operating guides your team can follow, knowledge transfer completed before final payment | Written plan for code and access transfer; release and operating guides your team can use on its own; knowledge-transfer sessions scheduled before final payment |
| L: Live production readiness | Readiness you can verify, not a feeling from a polished walkthrough | Checks that run before each release{3} in a test setup your team can open; observability via monitoring and alerts{4} with documented alert rules; performance results under realistic load; a release process your team can run | Passing release checks in a test setup your team can open; monitoring and alert definitions your team can review; a release process your team can run without help |
| T: Traceable fix records | Acceptance proof stored where your team controls it, not reconstructed after handoff | Closed fix records with dates, owners, and sign-off; test reports linked to the release they cover; dated security and compliance scan outputs with annotated findings; signed handover checklists before final payment | Closed fix records with dates, owners, and sign-off; test and scan outputs tied to a specific release; signed handover confirmation before final payment |
unosquare‘s week-one Discovery produces a draft production acceptance plan while you are still comparing options, then locks scope, price, and what “done” means in the agreement before production code starts.
Demos help the room stay aligned; the table above is what turns “this looks great” into a list of missing production work you can commission.
Five named proofs matter most when they map onto a build leadership already recognizes. The client intake portal below shows what happens when those proofs stay out of the deal, and what commissioning looks like when they stay in it.
Example: A Fast Client Intake Portal Prototype
A client intake portal makes the BUILT proofs concrete. An operations lead built it with AI coding tools over a long weekend. Forms capture the right fields, routing looks clean, and Monday’s walkthrough impresses the room. The main path works, and leadership wants it commissioned as a real client-facing build.
The demo earned its place in the conversation. Like the campaign lead-capture build, commissioning still requires answers the walkthrough did not show.
Who can see which submissions? What happens when a form fails mid-submit? How does the system behave under a busy intake week, including edge cases the happy path never hit? What monitoring alerts the team? Who owns the code after handoff? Those answers belong in the acceptance plan before you price the full build.
unosquare‘s week-one Discovery maps that portal against a production acceptance plan, names scope and price with a shared definition of done, then typically delivers in 8 to 12 weeks with full ownership at handoff. Builds start as low as $100K, scoped before production code starts.
The delivery phases below show how each BUILT proof gets verified, from Discovery through handoff.
How unosquare Names Missing Production Work Before Writing Code
unosquare puts the polished demo and every production deliverable in the same deal. Scope, price, and what “done” means cover all five BUILT proofs. Each delivery phase verifies those proofs at payment milestones you can check.
Discovery: Stress-Testing What the Demo Proved
Week one delivers a working prototype and runs the paths the polished walkthrough skipped: bad or unexpected data, who can see which records, and recovery when something breaks. Those checks run against the same screens leadership already approved.
You leave with a draft production acceptance plan: which security scans belong in scope, which release checks must pass before each milestone, and which ownership transfer steps close the engagement. Discovery also surfaces maintainability gaps and technical debt in the AI-generated code before you fund a rebuild. No commitment to the full build is required.
Solution Architecture: Locking Price to What the Walkthrough Skipped
Week two converts that gap list into a signed contract exhibit. Scope, fixed price, and definition of done are agreed together, including the security work, monitoring setup, test evidence, and handover obligations the demo never displayed.
Change-order limits and milestone payments attach to deliverables your team can verify, not calendar dates. When procurement signs here, the fee already covers completeness beyond the polished screen share.
Build Phase: Accepting Proof at Every Milestone, Not Only at Demo Day
Weeks three through eleven are where demo-quality output becomes commissioned output. Each milestone release is checked against the acceptance plan: release-check results in a test setup your team can open, updated security scan reports linked to that release, and monitoring alert rules your operators can review.
AI-generated code can accelerate feature work during this phase, while human oversight{8} decides what ships. Debugging is part of acceptance, not a surprise after launch.
Milestone demos still help the room stay aligned, but payment gates follow evidence you can trace. A passing walkthrough is not enough if error handling for bad data is still open, or if a finding from scanning outside packages remains unresolved.
Deploy and Handoff: Ownership Before Final Payment
Week twelve confirms independence, not go-live alone. Code transfer happens first. Knowledge-transfer sessions are recorded. Operating guides are written for your systems. Closed fix records with owners and dates are completed before final payment releases.
Handoff asks a simple question your COO can answer without calling unosquare: can your team put this system live, monitor it, and recover it on its own? unosquare‘s obligation does not end at go-live. It ends when the client has confirmed readiness through a signed acceptance process.
Engagements typically run 8 to 12 weeks from Discovery through Deploy and Handoff. Builds start as low as $100K, scoped and fixed before production code is written. If delivery takes longer than the committed timeline, that additional cost is unosquare‘s, not the client’s.
unosquare has completed more than 2,500 projects over 16 years, with a client NPS in the top 1% of B2B services and enterprise clients across financial services, healthcare, and other regulated industries.
Deliveries are penetration-tested (security-tested) and SOC 2 compliant before launch, with HIPAA-ready practices where health-data rules apply, and backed by major cloud partner credentials when that is your stack.
The phases show how missing production work gets named and accepted. The fit question is whether your situation needs that structure now.
Is unosquare‘s Fixed-Fee, Outcome-Based Model Right for You?
That structure works best when the business outcome is clear and the timeline has real consequences. Common fit signals include:
- A board mandate with a delivery deadline
- A SaaS renewal that no longer makes economic sense
- An internal build that has consumed resources but has not shipped
- A stalled transformation initiative that needs a defined outcome and timeline
- An AI-assisted demo that already impresses the room, and leadership now needs the missing production work named in the deal before the price is set
When these conditions are present, naming outcomes and pricing the full build before work starts is often the clearest buying structure available. Week one is the place to name that completeness before you commit.
Typical Project Size, Timeline, and Investment Guidelines
| Parameter | Typical Range |
|---|---|
| Delivery timeline | 8 to 12 weeks |
| Minimum build investment | Starts at $100K, scoped before code is written |
| Week one | Working prototype delivered, no full commitment required |
| Cost of overrun | unosquare‘s cost, not the client’s |
See Completeness Named in the Deal Before You Commit
If an AI-assisted demo already impresses the room and the fit signals above apply, week one writes completeness into the deal. unosquare delivers a working prototype of your specific idea, with no commitment required. Request your week-one prototype and see which missing production work belongs in the same commissioned outcome before the price is agreed.
Frequently Asked Questions
What exactly is “vibe coding” when evaluating an AI-assisted prototype for production?
Vibe coding is AI-assisted development that produces polished main-path flows quickly. The limitations of vibe coding appear when AI-generated code meets live traffic: security checks, testing under real conditions, debugging edge cases, monitoring, and ownership documentation.
With the right acceptance plan, that same speed becomes the starting point for a complete commissioned build.
What belongs in a production-ready AI-assisted build beyond the demo?
Beyond the polished walkthrough, a complete build includes checks that run before each release, monitoring and alerts, and security checks with dated proof. It also includes performance evidence under realistic load, and ownership documentation with code transfer.
Cursor and similar tools get you to the demo; production readiness still requires that work in the deal before you price the full build.
What does “definition of done” look like before we sign?
Done is defined by a production acceptance plan attached to the contract before the build begins. It spells out what must be true for each deliverable: release checks that pass before each milestone, dated security scan outputs, monitoring setup, documented release steps, and complete code and access transfer.
unosquare agrees that definition of done before signing, so the fee already covers the work required to reach it.
How do you verify the Underlying security proof is in the deal, not deferred?
Dated reports from scanning the code and outside packages it relies on, security test results, and a compliance checklist with owner assignments and fix-by dates belong with the other BUILT proofs in the production acceptance plan.
Closed fix records with dates, owners, and sign-off travel with handover before final payment. Security work is commissioned alongside testing, monitoring, and handover docs, not sold as a post-launch add-on.
What evidence proves the deliverable is production-ready and not just a demo?
Release-check suites with passing results in a test setup your team can open, monitoring configurations with alert definitions, performance summaries showing behavior under realistic load, and a release process your team can run without outside help. unosquare accepts against that bar at each milestone, then confirms it again at Deploy and Handoff.
If your AI-assisted demo is strong enough to deserve a complete build definition, unosquare‘s outcome-based delivery model names every BUILT proof in the deal before production code starts. Request a scoped prototype and see which missing production work belongs in the same commissioned outcome before you commit.
References
- MIT Technology Review. (2025). What is vibe coding, exactly? MIT Technology Review.
https://www.technologyreview.com/2025/04/16/1115135/what-is-vibe-coding-exactly/ - OWASP Foundation. (n.d.). OWASP Secure Coding Practices – Quick Reference Guide. OWASP Foundation.
https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist.html - Fowler, M. (2014). Continuous Delivery. martinfowler.com.
https://martinfowler.com/bliki/ContinuousDelivery.html - Amazon Web Services. (n.d.). Using Amazon CloudWatch alarms. AWS Documentation.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Alarms.html - OWASP Foundation. (n.d.). OWASP Software Assurance Maturity Model. OWASP Foundation.
https://owasp.org/www-project-samm/ - OWASP Foundation. (2025). OWASP Top 10:2025. OWASP Foundation.
https://owasp.org/Top10/2025/ - European Parliament and Council of the European Union. (2016). Regulation (EU) 2016/679 of the European Parliament and of the Council. EUR-Lex.
https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng - Tabassi, E. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST.
https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
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 aim 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.
