From Cursor Prototype to Production SaaS: A Realistic Timeline

You built a prototype in Cursor in a weekend. Turning it into a product people pay for takes 4-8 weeks. Here's exactly what happens in each week and why.

A realistic week-by-week timeline for turning a Cursor-built prototype into a production SaaS product. What changes, what stays, and how long each phase actually takes.

You spent a weekend with Cursor and built something impressive. The app has a working UI, core features, and a flow that makes sense. You showed it to people and they said "this looks real." Now you want to charge money for it.

Here's the honest timeline for what comes next.

What Your Prototype Has (And What It Doesn't)

A typical Cursor prototype after a weekend of focused building includes: a working UI with polished components, core feature flows (the happy path), basic data storage (usually SQLite or a simple Supabase setup), maybe a login page, and maybe a Stripe checkout button.

What it doesn't have: server-side authentication on every API endpoint, webhook-driven payment processing, error handling for failure cases, environment separation, database migrations, automated backups, monitoring and alerting, input validation, rate limiting, proper security headers, tested deployment pipeline, and the 50+ edge cases that real users will encounter.

The prototype looks 90% complete because the visible 90% — the UI and features — is genuinely good. The invisible 80% of a production product is missing entirely. This is the final 10%, and it takes longer than the prototype to build.

The Realistic Timeline

Week 1: Security and Authentication (40 hours)

This is the most important week. Everything that follows depends on authentication and security being solid.

Days 1-2: Migrate to proper authentication. If the prototype uses custom auth (which most do), migrate to Supabase Auth, Auth0, or Clerk. Set up server-side session validation on every API endpoint. Implement proper password hashing if you're keeping custom auth. Add rate limiting on login attempts.

Days 3-4: Move security logic server-side. Audit the entire frontend codebase for client-side security checks — role checks, access control, feature gating. Move every check to the API layer. Set up row-level security in the database if using Supabase.

Day 5: Security audit. Run through the 25-point security checklist. Fix everything that fails. This catches the issues the migration missed — hardcoded secrets, missing CORS configuration, exposed error messages, unvalidated inputs.

By the end of week 1, users can safely log in, their data is protected, and the API rejects unauthorised requests.

Week 2: Infrastructure and Deployment (40 hours)

Days 1-2: Set up proper hosting and environments. Migrate from Replit (if applicable) to Vercel. Create separate development and production environments with their own databases and API keys. Configure automated deployments from Git.

Days 3-4: Database infrastructure. Set up a migration framework so the database schema can evolve safely. Configure automated backups. If the prototype used SQLite, migrate to PostgreSQL (via Supabase or similar). Set up connection pooling for production traffic.

Day 5: Monitoring and error tracking. Configure Sentry for error tracking, uptime monitoring with alerting, and basic application logging. Set up health check endpoints. After this, you'll know when things break before your users tell you.

By the end of week 2, the app runs on production-grade infrastructure with automated backups, monitoring, and a deployment pipeline.

Week 3: Payments and Business Logic (40 hours)

Days 1-3: Production payment processing. If the prototype has Stripe, rebuild the integration properly: webhook-driven access control, signature verification, subscription lifecycle management, failed payment handling. If no payments yet, implement from scratch using the production payment architecture.

Days 4-5: Business logic hardening. Identify every business rule in the application and verify it's enforced server-side. Handle concurrent requests (two users booking the same slot). Handle edge cases the prototype ignores (timezone differences, special characters in names, empty states, pagination for large datasets).

By the end of week 3, the app correctly handles real money and real business scenarios.

Week 4: Polish and Launch (40 hours)

Days 1-2: Error handling and user experience. Replace every raw error message with user-friendly feedback. Handle every failure state — network timeouts, service outages, invalid input, expired sessions. Add loading states and empty states throughout the app.

Days 3-4: Testing and edge cases. Test the complete application with multiple concurrent users. Test every form with invalid input. Test the payment flow end-to-end with Stripe test cards for different failure scenarios. Test on mobile browsers.

Day 5: Launch. Run the 30-item production-ready checklist. Fix any remaining items. Deploy. Monitor closely for the first 48 hours.

By the end of week 4, the app is production-ready for real users.

When It Takes 8 Weeks Instead of 4

The 4-week timeline assumes a relatively simple application with straightforward requirements. It extends to 6-8 weeks when the application has multi-tenant data isolation (each customer's data must be completely separated), complex workflows with multiple user roles and approval chains, regulatory compliance requirements (GDPR data handling, financial regulations, healthcare rules), integration with multiple third-party services, or an architecture that needs significant restructuring (no API layer, client-side-only logic, no proper database design).

The additional weeks are spent on architectural work that can't be shortcut. Multi-tenant data isolation alone can take a week to implement correctly. Compliance requirements often require legal review alongside technical implementation.

What to Keep From Your Prototype

The good news: most of your prototype survives. Here's what typically stays and what gets replaced.

Keep: UI and components. Cursor generates excellent UI code. The visual layer — components, layouts, styling — almost always survives intact. Minor adjustments for mobile responsiveness and accessibility, but the design stays.

Keep: Core feature logic. The business logic for your main features is usually correct. The happy path works, and the code that implements it is solid. What changes is how that logic is protected, validated, and error-handled.

Replace: Authentication. Almost always needs rebuilding with a proper auth provider and server-side enforcement.

Replace: Payment integration. Needs webhook-driven architecture and proper subscription management.

Replace: Infrastructure. Hosting, deployment, backups, monitoring — all need production-grade setup.

Add: Everything invisible. Error handling, input validation, rate limiting, security headers, database migrations, monitoring — the production infrastructure the prototype doesn't have.

Think of it as keeping the house but replacing the plumbing, electrical, and foundation. The rooms look the same. What holds them up is completely different.

The Cost Equation

A weekend Cursor prototype: £0 (your time) plus Cursor subscription (£20/month).

Getting that prototype to production yourself: 4-8 weeks of full-time work. If you know what you're doing, this is feasible. If you're learning as you go, add 2-4 weeks for mistakes and dead ends.

Getting it to production with professional help: £15,000-£30,000 for a 30-day build that takes the prototype's core concept and builds it production-grade from scratch. A Discovery Sprint (£5,000) can assess whether your prototype is worth building on or whether a clean build is faster.

The total cost is still 3-5x less than the traditional path (6-12 months, £50,000-£150,000 through an agency). AI tools compressed the prototype phase from months to a weekend. The production phase is where human expertise still matters — but it's still dramatically faster than building without AI.

Frequently Asked Questions

Can I launch the prototype as-is and fix things later?

For a free product with no sensitive data, maybe — if you accept the risk of security issues and poor user experience. For anything involving payments, personal data, or paying customers, no. The issues described in weeks 1-3 aren't nice-to-haves. They're the difference between a product and a liability.

Should I continue building in Cursor or switch to a different tool?

Keep using Cursor for the production build. It's excellent for implementing the production-grade code — you just need to direct it with more specific prompts. Instead of "add payments," prompt with "implement Stripe webhook handler with signature verification, handling checkout.session.completed and invoice.payment_failed events." The tool is the same; the direction changes.

What if my prototype is in Replit or Bolt instead of Cursor?

The timeline is similar, but the starting point may be different. Replit and Bolt prototypes tend to have simpler architectures (sometimes a single file), which means more restructuring in week 1. The UI components often need more work. But the fundamental gap — missing production infrastructure — is the same regardless of which tool built the prototype.

How do I know if my prototype is worth building on?

If the core concept is validated (people want what it does), the UI is solid, and the data model makes sense, build on it. If the architecture is fundamentally wrong (no API layer, no database, everything in the frontend), a clean rebuild using the prototype as a reference is faster. A Discovery Sprint gives you a definitive answer.