# Rapid MVP Architecture Decision Framework

Decide on the right technical architecture for a fast-moving MVP build, balancing speed of shipping against future scaling and rework cost.

## Prompt

Act as a pragmatic technical advisor helping me choose an architecture for a fast MVP build. Here's what I'm building:
{{product_description}}

My constraints: {{constraints}}

Work through this decision framework:

1. Build vs. buy vs. no-code — for each major component of this product (e.g. auth, payments, database, hosting), recommend whether to build custom, use a managed service, or use a no-code/low-code tool, with a one-line reason for each.
2. Speed-to-ship estimate — give a rough relative time estimate (not exact hours) comparing the recommended stack against a 'build everything custom' alternative.
3. Deliberate technical debt — identify 2-3 places where taking on technical debt now is a reasonable trade-off for speed, and explicitly note what would need to be revisited before scaling past an early-stage user base.
4. Scaling cliff — identify the single most likely point where this architecture would need to be rebuilt or significantly changed (e.g. a specific user count, data volume, or feature that breaks the current approach), so I'm not surprised by it later.
5. Final stack recommendation — give a concrete, named recommendation (specific tools/frameworks), not just categories.

Optimize for shipping fast without creating an unrecoverable mess.

## Best for

Founders and indie developers building an MVP quickly who want a deliberate, informed set of technical trade-offs rather than either over-engineering or accumulating unmanageable technical debt.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Describe your product and its core components in {{product_description}}.
- List your real constraints (team size, timeline, budget, existing skills) in {{constraints}} — this materially changes the right recommendation.
- Pay close attention to the 'deliberate technical debt' section and write those items down somewhere you'll actually revisit them, not just this conversation.
- Treat the scaling cliff as an early warning system — check your actual usage against that threshold periodically.

## Customization tips

- If you have strong opinions about certain tools already (e.g. 'I only want to use Python'), state this as a constraint so recommendations respect it.
- Ask for a second version optimized purely for lowest cost if budget is the primary constraint rather than speed.
- Follow up by asking for a more detailed breakdown of just the highest-risk component identified (often auth or payments).

## Example input

Act as a pragmatic technical advisor... Product: A marketplace connecting freelance photographers with small businesses needing product photos, with booking, messaging, and payment. Constraints: solo founder, some coding ability, need to launch in 4 weeks, budget under $200/month for tools.

## Example output

1. Build vs. buy vs. no-code: Auth — use a managed service (e.g. Clerk or Supabase Auth) rather than building custom, since auth security mistakes are costly and this is a solved problem. Payments — use Stripe Connect for marketplace payouts rather than building custom payment splitting logic, since payment compliance is high-risk to build yourself. Booking/scheduling — build a simple custom calendar component rather than a heavy no-code tool, since booking logic is core to your product's differentiation. Messaging — use a managed chat API (e.g. Stream or a simple in-app messaging table via Supabase) rather than building real-time infrastructure from scratch.
2. Speed-to-ship estimate: this stack likely ships in roughly one-third the time of a fully custom build, primarily because auth and payments (the highest-risk, highest-effort components) are offloaded to managed services.
3. Deliberate technical debt: (a) hardcoding a flat platform fee percentage instead of building a flexible fee configuration system is fine for launch but should be revisited once you have pricing experiments to run, (b) using a single database table for all messages without conversation threading optimization is fine under a few thousand users but will need indexing work later, (c) skipping automated testing initially is reasonable for a 4-week MVP but should be added before onboarding paying customers at scale.
4. Scaling cliff: the most likely breaking point is the simple messaging table once you exceed roughly 10,000 messages, since query performance will degrade without proper indexing and pagination, requiring a messaging architecture revisit.
5. Final stack recommendation: Next.js for the frontend/backend, Supabase for database and auth, Stripe Connect for marketplace payments, and a simple custom-built booking calendar component, deployed on Vercel.