Pracowałem kiedyś nad projektem, który miał 14 dni na pełen cykl – od designu przez development po deployment. Gra webowa z ośmioma mechanikami, panel CMS, integracja z kodami QR. Wszystko w dwa tygodnie. Brzmi jak absurd? Brzmi. Ale takie projekty zdarzają się częściej niż mogłoby się wydawać, szczególnie gdy klient potrzebuje czegoś „na wczoraj” albo gdy poprzedni wykonawca zawodzi tuż przed deadlinem kampanii marketingowej.
Najtrudniejsze w tego typu projektach nie jest nawet samo tempo – najtrudniejsze jest pogodzenie się z faktem, że nie napiszesz pięknego, czystego kodu. Że będziesz świadomie zaciągał dług techniczny. I że jeśli nie zrobisz tego rozważnie, ten dług zaprocentuje dużo szybciej niż w standardowych projektach.
Dług techniczny nie jest porażką - jest narzędziem
Większość zespołów traktuje technical debt jak wstydliwą tajemnicę. Coś, co powstaje przez brak czasu albo umiejętności. W reality to często świadoma decyzja biznesowa, szczególnie przy MVP. Problem zaczyna się wtedy, gdy nie rozróżniamy między długiem, który możemy spłacić, a długiem, który nas ubezwłasnowolni.
Martin Fowler w swoim Technical Debt Quadrant rozróżnia cztery typy długu. Dla nas najważniejsze są dwa: świadomy-rozmyślny (deliberate-prudent) i nieświadomy-nieuważny (inadvertent-reckless). Pierwszy to decyzja „wiemy, że to nie jest idealne, ale teraz musimy deliverować”. Drugi to „kodzę na czuja i zobaczymy co wyjdzie”. Przy 14-dniowym projekcie nieuchronnie znajdziesz się w pierwszej kategorii – pytanie tylko, czy robisz to ze zrozumieniem konsekwencji.
Konkretny przykład: integracja z kodami QR. W idealnym świecie zrobiłbyś redirect service, logging każdego skanu z metadanymi, rate limiting, tokeny z ograniczonym czasem życia. W 14-dniowym MVP? QR prowadzi bezpośrednio do URL gry i tyle. To dług. Ale jeśli wiesz, że jest, i wiesz, gdzie tkwi problem – możesz go później naprawić. Jeśli nie wiesz, odkryjesz to dopiero gdy ktoś zacznie brute-force”ować Twoje kody promocyjne.
Co można zaciągnąć na kredyt - framework decyzyjny
Przy ekstremalnie krótkich timeframach musisz mieć jasną mapę: co jest do przyjęcia jako technical debt, a co jest architektoniczną bombą zegarową. To nie jest kwestia feeling”u – da się to rozpisać dość konkretnie.
Możesz sobie darować (teraz):
- Testy jednostkowe dla każdej funkcji. Brzmi kontrowersyjnie, ale przy 14 dniach i MVP nie napiszesz pokrycia 80%. Lepiej skoncentrować się na critical path testach - czy podstawowy flow działa, czy użytkownik może przejść przez grę od początku do końca. Resztę zostawisz na później.
- Optymalizacje wydajnościowe przed zmierzeniem realnego ruchu. Premature optimization to nadal root of all evil, nawet przy napiętym harmonogramie. Zrobisz connection pooling, podstawowy cache, CDN dla statycznych assetów. Ale czy potrzebujesz Redis, database sharding i load balancera dla kampanii, która może mieć 200 użytkowników jednocześnie? Raczej nie.
- Perfekcyjnie DRY kod. W MVP będziesz miał duplikację. Będziesz miał podobne funkcje, które teoretycznie można by uogólnić. To jest do spłacenia później - jeśli okaże się, że te fragmenty faktycznie potrzebują być generyczne.
Nie możesz sobie darować (nigdy):
- Separacji warstw, nawet uproszczonej. Jeśli zmiksasz logikę biznesową z warstwą prezentacji, każda zmiana wymagań będzie wymagała grzebania w całym kodzie. Przy projekcie, który potencjalnie będzie iterowany po MVP, to sentence śmierci. Nawet najprostsza separacja - kontrolery, serwisy, modele - da Ci możliwość wymiany części systemu bez przepisywania całości.
- Error handling na zewnętrznych zależnościach. Przy integracji z API, bazą danych, file storage - każda zależność może zawieść. Jeśli nie owiniesz tego w try-catch albo equivalent, Twoje MVP położy się przy pierwszym timeout"cie zewnętrznego serwisu. Nie musisz mieć sophisticated retry logic, ale podstawowa obsługa błędów to minimum.
- Environment configuration. Hardkodowanie URL-i, credentials, feature flags bezpośrednio w kodzie to classic mistake. Gdy będziesz chciał zmienić środowisko albo przekazać projekt klientowi, odkryjesz że trzeba grepować cały codebase w poszukiwaniu wszystkich miejsc, gdzie coś trzeba podmienić.
- Authentication i authorization, nawet prosty. Panel CMS bez żadnego logowania? Publiczne API bez rate limiting? To nie jest tech debt, to security issue. Nawet podstawowy auth zajmuje kilka godzin, ale oszczędza miesięcy problemów później.
Był moment w tym projekcie kiedy klient nalegał na dodanie dziewiątej mechaniki w połowie sprintu. „To tylko mała funkcja, szybko pójdzie”. Problem w tym, że zespół już działał na pełnych obrotach przy ośmiu mechanikach i dwutygodniowym deadline. Musieliśmy powiedzieć wprost: albo dostarczymy osiem działających mechanik, albo dziewięć kruchych. Klient wybrał osiem. To nie było easy conversation, ale było konieczne – bo alternatywą było dostarczenie czegoś, co wygląda na działające na demo, ale sypie się przy użyciu produkcyjnym. Czasem mówienie „nie” klientowi jest najlepszą decyzją techniczną jaką możesz podjąć.
Modular monolith jako kompromis między szybkością a maintainability
Przy 14 dniach nie zbudujesz microservices architecture. To oczywiste. Ale możesz uniknąć big ball of mud. Rozwiązaniem jest modular monolith – jeden deployment, ale wewnętrznie podzielony na moduły, które mogą być później wyekstrahowane jeśli zajdzie potrzeba.
Konkretnie: mechaniki gry jako osobne moduły. Panel CMS jako osobny moduł. Auth jako osobny moduł. Nawet jeśli wszystko żyje w jednym repozytorium i jest deployowane razem, ta separacja daje Ci dwie rzeczy: łatwość testowania (każdy moduł ma jasny interface) i możliwość przyszłej ekstrakcji (jeśli mechanika X musi być osobnym serwisem, masz jasne granice).
Głównym wyzwaniem jest komunikacja między modułami. W microservices masz API. W modular monolith masz function calls. Co jeśli później będziesz musiał to rozdzielić? Rozwiązanie: definiujesz internal API jako interfaces albo abstract classes. Moduł A nie wywołuje bezpośrednio funkcji z modułu B – wywołuje interface, który moduł B implementuje. Później, jeśli B stanie się osobnym serwisem, podmienisz implementację interface”u na HTTP client. Kod wywołujący nie zmienia się.
typescript
// Zamiast:
import { validateQRCode } from "./qr-module";
const result = validateQRCode(code);
// Robisz:
interface QRValidator {
validate(code: string): Promise;
}
class QRModule implements QRValidator {
async validate(code: string): Promise {
// logic
}
}
// I inject dependency:
constructor(private qrValidator: QRValidator) {}
const result = await this.qrValidator.validate(code);
To wygląda jak over-engineering przy 14-dniowym projekcie. Ale to jest różnica między MVP, który możesz rozwijać, a MVP które za trzy miesiące trzeba przepisać od zera.
Extension points - projektowanie pod przyszłość która może nie nadejść
Najtrudniejsza decyzja architektoniczna przy MVP: co jeśli się spodoba? Sukces kampanii marketingowej oznacza presję na dodawanie funkcji. Jeśli Twoje MVP jest architektonicznie zamknięte, każda iteracja będzie kosztować więcej niż poprzednia. Ostatecznie dojdziesz do punktu gdzie rewrite from scratch jest tańszy niż kolejna zmiana.
Rozwiązaniem są extension points – miejsca w architekturze gdzie możesz podpiąć nową funkcjonalność bez przepisywania core logic. Nie budujesz całego plugin systemu w MVP, ale projektujesz kod tak, żeby to było możliwe później.
Przykład z projektu gry: scoring system. Masz osiem mechanik, każda zwraca punkty. W MVP możesz je po prostu sumować. Ale jeśli zrobisz to tak:
typescript
class ScoringEngine {
calculateTotalScore(mechanics: MechanicResult[]): number {
return mechanics.reduce((sum, m) => sum + m.points, 0);
}
}
…to później, gdy klient zechce dodać mnożniki, bonusy, streak”i, będziesz musiał przepisywać tę logikę. Alternatywa z extension point:
typescript
interface ScoreModifier {
apply(score: number, context: GameContext): number;
}
class ScoringEngine {
private modifiers: ScoreModifier[] = [];
calculateTotalScore(mechanics: MechanicResult[], context: GameContext): number {
let score = mechanics.reduce((sum, m) => sum + m.points, 0);
return this.modifiers.reduce((s, mod) => mod.apply(s, context), score);
}
}
W MVP lista modifiers jest pusta. Ale gdy przyjdzie czas na bonusy, dodajesz nowy modifier bez ruszania core logic. To kosztuje może godzinę więcej przy developmencie, ale oszczędza dni przy pierwszej iteracji.
Kluczowe: nie dodajesz extension points wszędzie. To byłoby over-engineering. Dodajesz je w miejscach, gdzie wysoka szansa na zmianę wymagań: scoring, walidacja, content, UI themes. Miejsca które customer typically chce modyfikować po zobaczeniu działającego MVP.
Dokumentacja długu jako część deliverables
Najgorsza rzecz jaką możesz zrobić przy świadomym zaciąganiu tech debt: nie udokumentować go. Za trzy miesiące Ty zapomisz dlaczego coś jest zrobione w określony sposób. Klient na pewno nie będzie wiedział. Kolejny developer który przejmie projekt będzie reverse-engineerował Twoje decyzje.
Architectural Decision Records to lightweight sposób dokumentowania istotnych decyzji. Dla każdej większej decyzji architektonicznej robisz krótki dokument:
- ADR-003: Brak redirect service dla QR codes
- Context: Integracja z kodami QR przy 14-dniowym deadline. Idealnie QR powinien prowadzić do redirect service, który loguje skany i pozwala zmienić target URL bez przeprintowania materiałów.
- Decision: W MVP QR prowadzi bezpośrednio do URL gry. Brak loggingu skanów. Brak możliwości zmiany target URL po wydrukowaniu materiałów.
Consequences:
- - Risk: Jeśli trzeba zmienić domenę, QR na materiałach będą martwe
- - Risk: Zero analytics o tym kto, kiedy, skąd skanował
- - Cost to fix: ~8h dev (redirect service + migration starych QR)
To brzmi jak overkill, ale przy przekazywaniu projektu to jest różnica między „mam kod ale nie wiem co z tym robić” a „rozumiem trade-offy które zespół podjął”.
Druga rzecz: Technical Debt Register. Prosty spreadsheet albo dokument z listą wszystkich known issues i ich estimated cost of fixing. Format mniej więcej taki:
- Brak obsługi błędów przy wywołaniach zewnętrznych API
Wpływ: system może przestać działać przy timeoutach lub błędach zewnętrznego serwisu.
Szacowany czas naprawy: 4 godziny.
Priorytet: wysoki. - Powielona logika walidacji w trzech miejscach
Wpływ: każda zmiana reguł wymaga modyfikacji wielu fragmentów kodu, co zwiększa ryzyko błędów.
Szacowany czas naprawy: 6 godzin.
Priorytet: średni. - Feature flagi zapisane bezpośrednio w kodzie
Wpływ: każda zmiana ustawień wymaga nowego wdrożenia aplikacji.
Szacowany czas naprawy: 2 godziny.
Priorytet: średni. - Brak indeksów w bazie danych dla kluczowych zapytań
Wpływ: spadek wydajności po przekroczeniu około 1000 użytkowników.
Szacowany czas naprawy: 4 godziny.
Priorytet: niski na etapie MVP.
To nie jest shame list. To jest plan spłaty długu. Przy przekazywaniu projektu albo planowaniu iteracji masz jasny obraz: co jest do naprawy, co to kosztuje, co jest critical.
"Przy 14-dniowym MVP granica między świadomym długiem technicznym a przyszłym problemem jest zaskakująco cienka. Zwykle odkrywamy, po której stronie byliśmy, dopiero wtedy, gdy ktoś próbuje dodać kolejną funkcję."
Definicja "done" przy ekstremalnej presji czasowej
Feature freeze to jedna z najtrudniejszych rzeczy do wyegzekwowania przy napiętych deadline”ach. Klient widzi działające MVP tydzień przed końcem i nagle ma „świetny pomysł” na nową mechanikę. Albo „drobną zmianę” w istniejącej. Problem w tym, że przy 14 dniach nie masz bufora na scope creep.
Rozwiązaniem jest jasna definicja done ustalona przed startem developmentu. W przypadku tego projektu: makiety interaktywne jako kontrakt. Klient akceptuje makiety, potem feature freeze. Żadnych zmian w trakcie developmentu. Brzmi drastycznie, ale przy takim tempie to jedyny sposób żeby dostarczyć cokolwiek działającego.
Definicja done dla każdej mechaniki powinna być konkretna:
- Happy path działa end-to-end
- Basic error handling (nie crash"uje przy invalid input)
- Responsive na desktop i mobile
- Przetestowane ręcznie na minimum trzech urządzeniach
To nie jest „production ready”. To jest „demo ready” z jasną listą co będzie do poprawy. I to jest okej – o ile wszyscy wiedzą, że to MVP, nie final product.
Lepiej dostarczyć pięć mechanik które działają solidnie niż osiem które „jakoś działają”. Przy odbiorze z klientem różnica jest drastyczna. Pięć solidnych mechanik wygląda na polished MVP. Osiem kruchych wygląda na niedokończony produkt. Paradoks: mniej features może wyglądać lepiej niż więcej.
Strategia wyjścia - od MVP do production-ready
Najtrudniejsze rozmowy przychodzą po deliverze MVP. Klient jest zadowolony, kampania działa, wszystko brzmi idealnie. I nagle: „chcielibyśmy dodać X, Y, Z”. Tu się okazuje czy zaciągnąłeś spłacalny dług, czy utoniesz w odsetkach.
Przy przekazywaniu projektu albo planowaniu kolejnych iteracji potrzebujesz refactoring roadmap. To nie jest wishful thinking „kiedyś to zrefaktorujemy”. To konkretny plan: co, w jakiej kolejności, za ile.
Faza 1 (po MVP, przed pierwszą iteracją):
- Spłata high-priority technical debt z register"u
- Dodanie monitoring i alerting (jeśli nie było w MVP)
- Database backups i disaster recovery procedure
- Load testing z realistycznym ruchem
Estimated effort: 2-3 dni. To brzmi dużo, ale to różnica między systemem który możesz rozwijać a systemem który się posypie przy pierwszej iteracji.
Faza 2 (przy dodawaniu nowych features):
- Refactoring modułów które będą modyfikowane
- Dodanie testów dla core logic
- Migracja hardcoded config do environment variables
- Dokumentacja API (jeśli będą integracje)-
To jest stopniowa spłata długu – nie robisz big-bang refactoringu, tylko iteracyjnie poprawiasz kod który i tak musisz dotykać przy zmianach.
Kluczowe: wycena refactoringu musi być transparentna. Jeśli klient chce dodać nową mechanikę, estimate powinien zawierać czas na feature + czas na spłatę długu w tym module. „Nowa mechanika to 16h – 10h feature, 6h refactoring istniejącego scoring engine żeby było możliwe dodanie bez duplikacji logiki”. Bez tego wprost powiedzianego, klient będzie surprised wysokim estimate”m i będzie pressure żeby „po prostu dodać” bez refactoringu.
Monitoring jako debt który wraca nocą
Nie napisałem o tym wcześniej bo to jest ten rodzaj długu, który nie boli podczas developmentu. Boli w produkcji, zazwyczaj o 3 w nocy, gdy system leży i nie wiesz dlaczego.
Przy 14-dniowym MVP monitoring typically nie istnieje. Masz może podstawowe health check, może logi. Ale nie masz alertów. Nie masz metryk. Nie wiesz ile masz użytkowników, ile trwa response time, gdzie są bottlenecki.
To jest akceptowalne przy MVP które jest testowane tydzień przed kampanią. Nie jest akceptowalne przy systemie który ma działać przez dwa miesiące kampanii marketingowej bez nadzoru.
Minimum viable monitoring to:
- Health check endpoint (podstawowy: czy serwis odpowiada)
- Error logging z aggregacją (Sentry, Rollbar, cokolwiek)
- Basic metrics: request count, response time, error rate
- Alerty na krityczne metryki (error rate >5%, response time >3s, zero requests od 5 minut)
To się robi w kilka godzin jeśli użyjesz managed solutions. Ale różnica jest drastyczna – zamiast dowiadywać się o problemie od zdenerwowanego klienta, dostajesz alert kiedy error rate zaczyna rosnąć.
Obserwowaliśmy przy podobnym projekcie ciekawy pattern: użytkownicy grają głównie w godzinach wieczornych i w weekendy. W tygodniu w pracy flow był minimalny. Deployment w piątek przed weekendem był idiotycznym pomysłem – jeśli coś się psuje, psuje się przy peak traffic. Bez metrics nie wiedzielibyśmy tego, deployowalibyśmy „kiedy wygodnie” i crashowali system przy największym ruchu.
"Większość MVP wygląda stabilnie do momentu pierwszej większej zmiany. Wtedy zwykle okazuje się, które decyzje były świadomym kompromisem, a które tylko dobrze ukrytym problemem."
Infrastruktura jako technical debt
Dedykowane środowisko hostingowe” brzmi profesjonalnie. W praktyce przy 14-dniowym projekcie często oznacza: jeden VPS, ręczny deployment, zero redundancji. To jest kolejny dług – tym razem infrastrukturalny.
Single point of failure to realny problem. Jeśli ten jeden serwer padnie podczas kampanii B2B, masz wizerunkową katastrofę. Szczególnie gdy klient jest po „kryzysie zaufania” z poprzednim wykonawcą – drugi fail może być końcem kontraktu.
Minimum dla produkcyjnego MVP:
- Automatyczne backupy bazy danych (daily minimum)
- Documented restore procedure (i przetestowany restore - backup bez testu restore to nie jest backup)
- Automatyczne restarty serwisu przy crash"u (systemd, docker restart policy, cokolwiek)
- Możliwość szybkiego rollback do poprzedniej wersji
To nie jest high availability, to jest basic reliability. Kosztuje może dzień setupu, ale różnica między „system padł i wstaje za godzinę” vs „system padł i trzeba go ręcznie przywracać z paniki” jest ogromna.
Kontenerowość vs tradycyjny deployment to ciekawe pytanie przy MVP. Docker daje Ci reproducible builds i łatwy deployment, ale dodaje complexity. Przy 14 dniach jeśli zespół nie zna Dockera dobrze, tradycyjny deployment może być szybszy. To jest świadomy trade-off: szybciej teraz, trudniej później vs trudniej teraz, łatwiej później. Nie ma uniwersalnej odpowiedzi – zależy od kompetencji zespołu.
RODO compliance - nie jest optional tech debt
Privacy i security to jeden z tych obszarów gdzie zaciąganie długu technicznego może mieć konsekwencje prawne, nie tylko techniczne. „Zgodność z RODO” często jest checkboxem w requirements, ale w praktyce wymaga konkretnych decyzji architektonicznych.
Problem zaczyna się od prostego pytania: jakie dane zbierasz i po co? Gra webowa może zbierać: email (do logowania), results (do leaderboard), analytics (usage patterns), session data. Każdy typ danych ma inną podstawę prawną i inny required retention period.
Typowe błędy przy MVP:
- Zbieranie wszystkiego "może się przyda" bez jasnego celu
- Brak data retention policy (dane trzymane w nieskończoność)
- Analytics bez anonimizacji IP
- Brak mechanizmu do data export/deletion
To nie brzmi jak tech debt, brzmi jak legal issue. I faktycznie jest. Ale ma konkretne konsekwencje architektoniczne.
Jeśli nie zaprojektujesz możliwości usunięcia danych użytkownika od początku, może się okazać że dane są rozproszone po pięciu tabelach z foreign keys, cached w Redis, w backup”ach, w analytics. Usunięcie wszystkich danych konkretnego użytkownika staje się non-trivial problem.
Rozwiązanie: privacy by design. Minimalizuj zbierane dane. Anonimizuj co się da. Trzymaj PII (personally identifiable information) w jednym miejscu, nie rozpraszaj po całym systemie. To brzmi jak dodatkowa praca przy 14-dniowym deadline, ale w praktyce często simplifikuje architekturę – mniej danych to mniej complexity.
Cookie banner to nie RODO compliance. To jest konieczny element, ale nie wystarczający. Potrzebujesz jeszcze: privacy policy (co zbierasz i dlaczego), mechanizm consent management (jeśli używasz non-essential cookies), i actual implementation tego co deklarujesz w policy.
"Backupy były skonfigurowane, monitoring działał, a serwer przechodził wszystkie health checki. Dopiero awaria pokazała, które zabezpieczenia faktycznie chronią system, a które istnieją głównie po to, żeby dobrze wyglądać na diagramie."
Kiedy dług techniczny staje się nie do spłacenia
Są symptomy które mówią: to nie jest już tech debt, to jest legacy code którego nie da się utrzymać. Problem w tym, że przy MVP czasem trudno odróżnić jedno od drugiego.
Red flags:
- Estimate na małą zmianę rośnie z 4h do 16h bo "trzeba najpierw posprzątać kod"
- Developer który zna projekt odchodzi i nikt inny nie jest w stanie wprowadzać zmian (nawet 'wujek Marek')
- Każda zmiana psuje dwie inne rzeczy w niepowiązanych miejscach (tight coupling)
- "Nie możemy tego zmienić bo połowa systemu na tym polega" - oznaka że abstractions leakają
To są symptomy że dług techniczny przekroczył punkt w którym opłaca się go spłacać. Koszt utrzymania MVP przekracza koszt przepisania. I to jest okej – jeśli to był conscious trade-off. MVP miało służyć dwa miesiące kampanii, posłużyło, teraz budujemy produkt właściwy. Problem jest gdy MVP miało służyć dwa miesiące, a używane jest dwa lata.
Realnie przy 14-dniowym MVP zbudowanym pod presją, shelf life to zazwyczaj 3-6 miesięcy active development. Później albo zamrażasz (brak zmian, tylko maintenance) albo przepisujesz. Jeśli ktoś obiecuje że MVP będzie „foundation for future development” przy takim tempie – to marketing speak, nie technical reality.
Najtrudniejsza rozmowa z klientem to „system działa, kampania była sukcesem, ale jeśli chcecie budować na tym dalej, rekomendujemy rebuild”. To brzmi jak przyznanie się do porażki. W praktyce to jest przyznanie się do rzeczywistości. MVP z założenia nie jest production-grade system. Jeśli staje się nim przez przypadek (bo „działa więc zostańmy przy tym”), to problem organizacyjny, nie techniczny.
Lekcje
Największym błędem przy fast-track MVP jest traktowanie go jak normalnego projektu z mniejszym budżetem. To nie jest ten sam proces tylko szybszy. To jest fundamentalnie inny rodzaj projektu z innymi zasadami, innymi trade-offami, innymi miarami sukcesu. Sukces to nie „zero tech debt” – to niemożliwe przy 14 dniach. Sukces to „kontrolowany, udokumentowany dług który możemy spłacić gdy zajdzie potrzeba”.
Produkcja weryfikuje założenia bardzo szybko. To co wyglądało na rozsądny kompromis na stagingu, okazuje się problematyczne przy realnym traffic”u. Monitoring pokazuje bottlenecki których nie spodziewałeś się. Użytkownicy znajdują edge case”y których nie testowałeś. I to wszystko jest normalne – o ile masz architekturę która pozwala na iteracyjne poprawki, a nie wymaga przepisania przy każdej zmianie. To jest różnica między świadomie zaciągniętym długiem a kodem który powstał w panice.
Podsumowanie
MVP działało. Kampania wystartowała na czas, użytkownicy grali, klient był zadowolony, a większość kompromisów wydawała się rozsądną ceną za dostarczenie produktu w dwa tygodnie. Problem w tym, że produkcja nie ocenia architektury w dniu deployu. Ocenia ją miesiąc później, gdy pojawiają się pierwsze zmiany, dodatkowe wymagania i scenariusze, których nie było ani w backlogu, ani na żadnym diagramie. Wtedy okazuje się, że część długu technicznego była inwestycją, a część po prostu odroczonym kosztem, który właśnie wrócił z odsetkami.
Najciekawsze jest to, że największe problemy rzadko wynikają z rzeczy, których nie zdążyliśmy zrobić. Znacznie częściej wynikają z rzeczy, które wydawały się wystarczająco dobre na potrzeby MVP. Fragment logiki skopiowany „na szybko”, uproszczony model danych, tymczasowy endpoint, który miał zniknąć po pierwszej iteracji. Każdy z tych elementów przeżywa zwykle znacznie dłużej, niż ktokolwiek zakładał. Produkcja ma dziwną tendencję do zamieniania tymczasowych rozwiązań w stałe elementy systemu.
Po kilku miesiącach utrzymywania takich projektów trudno oprzeć się wrażeniu, że sukces MVP i jego największe zagrożenie często są dokładnie tą samą rzeczą. Im lepiej działa produkt po premierze, tym większa pokusa, żeby dalej budować na fundamentach, które nigdy nie były projektowane do długiego życia. I zwykle właśnie wtedy zaczyna się prawdziwa rozmowa o architekturze, której wszyscy byli przekonani, że uda się uniknąć.
Zobacz powiązane case studies i analizy
Procesy, architektura i workflow powiązane z tematami poruszanymi w tym materiale – od integracji i realtime systems po automatyzacje operacyjne.