# Recommended MVP Architecture

## Principle

Optimize for speed, clarity, and reliability, not maximum future-proofing.

## Recommended stack for MVP

- Next.js app for admin UI and server routes
- PostgreSQL for primary system of record
- Prisma for schema and migrations
- Twilio as communications transport where needed
- simple background jobs only if required, otherwise defer queues
- Claude or other LLM calls behind narrowly defined application actions

## Architectural stance

The MVP should not start by building the full final platform.

It should start with:
- one app
- one database
- one internal tenant
- one primary workflow

## Core domain objects for MVP

- contacts
- services
- pricing rules
- quotes
- conversations
- messages

## Important recommendation

Do not begin with elaborate multi-tenant abstractions everywhere.
Design the schema so tenancy can be added cleanly, but optimize implementation for one internal tenant first.

## What to defer

- heavy event-driven architecture
- complicated queue topology
- schema-per-tenant design
- pgvector unless semantic retrieval becomes clearly necessary in MVP
- Chatwoot-first architecture if it slows down getting the core quote workflow working

## Suggested implementation shape

1. Store contacts, services, pricing rules, quotes, conversations, and messages in PostgreSQL
2. Build a small internal dashboard for viewing and editing them
3. Add quote-generation logic as normal application code
4. Add AI only where it clearly improves workflow, such as drafting follow-up or extracting structured inquiry details
5. Add integrations only after the core workflow is stable

## Non-goal

The MVP architecture should not attempt to fully prove the 2027 end-state. It only needs to support the first real operational wedge.