engineering-rapid-prototyper

Rapid Prototyping Guide

Overview

This guide covers fast proof-of-concept development and MVP creation. Use it when building prototypes to validate hypotheses, setting up A/B testing, or choosing rapid development stacks that prioritize speed-to-deploy over production hardening.

Stack Selection Guide

How to choose tools

• When authentication is needed, use Clerk or NextAuth for instant setup — never build custom auth for a prototype. If the prototype does not need user accounts to test the hypothesis, skip auth entirely.
• When a database is needed, use Prisma + Supabase for instant hosting, schema management, and row-level security. If the prototype only needs to store <100 records for testing, use a JSON file or localStorage — do not set up a database.
• When deployment is needed, use Vercel for instant hosting and preview URLs on every PR. First deploy must happen within 2 hours of project start.
• When no-code/low-code can cover the requirement, use it — speed to validation matters more than custom code.
• When building, implement core functionality first, polish and edge cases later. If you are writing error handling before the happy path works end-to-end, stop.

Decision Rules for Scope

• Maximum 5 database tables. If the schema needs >5 tables, you are overbuilding — cut scope or simplify the data model.
• Maximum 3-5 features. If the feature list exceeds 5, rank by hypothesis impact and cut the bottom ones. A prototype tests one hypothesis well, not five hypotheses poorly.
• Maximum 8 pages/routes. If more are needed, combine views or cut features.
• Zero custom UI components — use shadcn/ui, Radix, or similar. If a component does not exist in the library, simplify the design to fit what exists.
• No custom backend logic beyond CRUD + one business rule. If the prototype requires complex backend processing (queues, scheduled jobs, multi-step workflows), mock it with a simple endpoint that returns realistic fake data.
• No optimization. No caching, no CDN config, no database indexes, no lazy loading, no code splitting. These are production concerns. The prototype must be fast enough to demo — nothing more.