Architektura 'na wyrost' w MVP - kiedy to świadomy wybór, a kiedy wymówka

Kontekst

Projekt: Brand Deals - SaaS do zarządzania współpracami marek z twórcami
Etap: MVP, dwa tygodnie po rozpoczęciu kodowania
Cel: zwalidować czy twórcy potrzebują narzędzia do ogarnięcia procesu ustalania szczegółów współpracy z markami. Reszta - umowy, stawki, rozliczenia - to dodatki

Dwa tygodnie rozmów z twórcami, planowanie zakresu, scopowanie MVP. Potem dwa tygodnie kodowania. Przy przeglądaniu tego co powstało zauważyłem, że MVP się rozjechał. Nie przez ficzery. Przez architekturę.

Opcje

Trzy ścieżki, które rozważałem (lub powinienem był rozważyć):

A: Minimum stacku. Express albo Fastify, flat structure, jeden model Prisma, deploy na Vercel. Postawienie w weekend, testowanie w poniedziałek. Ograniczenie: przy skalowaniu przepisujesz prawie wszystko.

B: Architektura docelowa. Monorepo (pnpm workspaces), NestJS z modułami, Prisma z pełnym schematem relacji, separacja concerns od dnia pierwszego. Setup trwa, ale “potem nie trzeba będzie przerabiać”. Ograniczenie: “potem” zakłada że wiesz co będzie potem.

C: Middle ground. NestJS, ale flat - bez modularyzacji. Jeden package, minimalne modele Prisma. Rozbudowa dopiero gdy jest po co - nie gdy wydaje się że kiedyś będzie po co.

Decyzja

Wybrałem B.

Kryterium: “skoro i tak będę to rozbudowywał, lepiej zrobić to porządnie od razu.”

Brzmi rozsądnie. Każdy developer słyszał tę logikę i każdy ją stosował. Problem w tym, że to nie jest kryterium - to jest projekcja. Zakłada wiedzę o przyszłości produktu, której jeszcze nie mam. Nie wiem co będzie rozbudowywane, bo nie wiem jeszcze czy ktokolwiek chce tego używać.

Pisałem o tym mechanizmie w notatce o granicy MVP - drift nie wygląda jak błąd, wygląda jak rozsądek. Tu jest to samo, tyle że na poziomie architektury zamiast zakresu. I ten sam wzorzec opisuje Complexity Substitution Principle - złożoność jako reakcja na niepewność, nie na faktyczną potrzebę.

Zderzenie

Produkt działa. Ale przeglądając co powstało w dwa tygodnie, trudno powiedzieć że to MVP. Moje największe overkille:

Monorepo z 3 apkami i elementami shared - api, web, landing page, plus shared contracts, config i utilities. Na produkt bez użytkowników.
Pełny CRUD dla wszystkich obiektów - łącznie z encjami, których nikt jeszcze nie używa i nie wiadomo czy będzie.
Custom Field System (EAV) - definicje pól, grupy pól, wartości z poziomem pewności (CERTAIN/UNCERTAIN). Cały silnik pod dynamiczne pola, zanim ktokolwiek potwierdził że tego potrzebuje.
Docker + CI/CD pipeline - multi-stage buildy, PostgreSQL w compose, linting, typecheck, testy, secret scanning, walidacja migracji Prisma. Produkcyjna infrastruktura przed pierwszym użytkownikiem.
AI telemetry + idempotency - śledzenie tokenów, kosztów, latency per call. Deduplikacja requestów do OpenAI. Optymalizacja pod ruch, którego nie ma.
Multi-tenancy z workspace isolation - per-request context middleware, role (OWNER, ADMIN, MEMBER). MVP zakłada jednego użytkownika na workspace.

Każdy z tych elementów z osobna ma sens. Razem tworzą architekturę produktu gotowego do skalowania, który nie zdobył jeszcze pierwszego użytkownika.

Hindsight

Za wcześnie na pełny werdykt - produkt jest wciąż w budowie.

Ale jedno widzę wyraźnie: “i tak będę rozbudowywał” to nie kryterium. To wymówka. Kryterium mówi co konkretnie będzie rozbudowywane i dlaczego ta złożoność jest warunkiem walidacji. “I tak będę” mówi tylko tyle, że nie wiem co będzie - ale na wszelki wypadek buduję pod wszystko.

Jeśli nie ma hipotezy - a nie było jej, bo nie postawiłem pytania wystarczająco wcześnie - to nie ma też kryterium na architekturę. Zostaje domyślna opcja: jak najmniej złożony stack, który pozwoli dotrzeć do pierwszego użytkownika.

Opcja C pewnie by wystarczyła. Może nawet A.

Czy to oznacza że wybrałem źle? Niekoniecznie. Może ta architektura się opłaci za miesiąc. Ale wybrałem ją bez podstaw - i to jest problem. Nie decyzja, tylko brak kryterium za nią.

Pełny kontekst tej decyzji - konkretne liczby, feedback od twórców i co z tego wynikło - w newsletterze.