Dla akceleratora startupów Łódzkiej Specjalnej Strefy Ekonomicznej (ŁSSE) zbudowaliśmy MVP systemu CRM na Open Mercato, frameworku open source. Framework pokrył ok. 50–60% wymagań, w tym uprawnienia, audyt i wyszukiwanie. Resztę, czyli Kanban, oceny ekspertów, nabory i ankiety po programie, dopisaliśmy jako własne moduły. Poniżej: co framework daje od razu, co dopisaliśmy, jak pilnowaliśmy jakości i kiedy taki CRM ma sens.
Dlaczego akcelerator potrzebował własnego CRM?
Program akceleracyjny żył w arkuszach, folderach dokumentów, mailach i osobnym narzędziu do zadań. Celem było zebranie tego w jednym miejscu. Gotowe CRM-y są zbudowane wokół lejka sprzedaży, a tu struktura wygląda inaczej:
- Organizacja
- Akcelerator, czyli edycja programu z tablicą Kanban
- Startup, który może być na wielu tablicach naraz (relacja wiele-do-wielu)
- Kamienie milowe startupu
- Zadania i rezultaty
Do tego role: mentor główny i ekspert, oraz liczba godzin mentoringu przypisana do startupu. W HubSpocie czy Pipedrive da się to udawać polami własnymi, ale każdy raport trzeba by potem obchodzić. Do tego dochodzą nabory z publicznym formularzem, oceny ekspertów z punktacją i ankiety wysyłane miesiące po zakończeniu programu, czyli rzeczy, których lejek sprzedaży w ogóle nie przewiduje.
Co Open Mercato daje od razu?
Wersja 0.6.6 z tym stosem:
| Warstwa | Technologia |
|---|---|
| Aplikacja | Next.js 16, TypeScript, Node ≥ 24 |
| Baza i ORM | PostgreSQL z pgvector, MikroORM |
| Cache i kolejki | Redis |
| Wyszukiwanie | Meilisearch v1.11 |
Z pudełka dostaliśmy multi-tenancy, role i uprawnienia (RBAC), dziennik audytu, załączniki, powiadomienia, wyszukiwanie, własne pola, import, API z webhookami i szyfrowanie danych osobowych. To nudne, ale drogie elementy, które w systemie pisanym od zera zjadają pierwsze tygodnie. Całość działa jako jedna instancja, w której każda firma jest osobnym tenantem. Moduły sklepowe wycięliśmy, bo akceleratorowi nie są potrzebne.
Dlaczego Open Mercato, a nie CRM pisany od zera?
Bo najdroższą część każdego systemu biznesowego, czyli konta, uprawnienia, audyt, wyszukiwanie i API, Open Mercato ma gotową i przemyślaną. Architektura jest modułowa: własny moduł dokłada encje, ekrany, uprawnienia i endpointy, nie ruszając rdzenia. Dzięki temu aktualizacja frameworka nie rozjeżdża się z kodem klienta.
Przed startem przejrzeliśmy kod frameworka, żeby wycenić projekt na faktach, a nie na opisie z README. Na tej podstawie zdecydowaliśmy, co bierzemy z pudełka, a co budujemy jako moduł. Automatyzacje (reguły i powiadomienia) napisaliśmy na przykład jako własny moduł, dokładnie pod proces naborów i ocen. Meilisearch od razu tworzy osobny indeks dla każdego tenanta i toleruje literówki, więc wyszukiwanie startupów działa bez dodatkowej pracy.
Masz ten sam problem? Rozważasz Open Mercato i chcesz wiedzieć, ile wymagań pokryje framework? Zaczynamy od takiego przeglądu. Opisz sytuację →
Co trzeba było dopisać samemu?
Siedem własnych modułów: accelerator, assessments (oceny), intake (nabory z publicznym formularzem aplikacyjnym), milestones, monitoring (ankiety po 3, 6 i 12 miesiącach), reporting i startups. Do tego Kanban na dnd-kit, silnik ocen z punktacją, KPI, wykres Gantta, kalendarz, rule builder i powiadomienia Slack, SMS i e-mail ustawiane osobno dla każdego tenanta. Ekspert widzi tylko startupy, do których go przypisano.
Wymagania wydajności: listy poniżej 300 ms, Kanban i Gantt poniżej 500 ms przy 300 rekordach, zakaz zapytań N+1.
Ile trwało zbudowanie MVP?
Pierwszy commit powstał 21 lipca 2026 r., a tydzień później, 28 lipca, mieliśmy specyfikację: od 80 do 95 zadań rozpisanych na 24 epiki. Wstępny szacunek MVP wynosił 12–14 tygodni pracy jednego programisty.
| Stan na | Zadania | Uwagi |
|---|---|---|
| 21.08.2026 | 87 z 95 | 151 commitów, ok. 50 tys. linii kodu |
| wrzesień 2026 | 91 z 95 | końcowa faza przed wydaniem |
Tempo wzięło się głównie z tego, że nie pisaliśmy od zera logowania, uprawnień, audytu ani wyszukiwarki, tylko od pierwszego tygodnia budowaliśmy moduły, które akcelerator faktycznie widzi na ekranie.
Jak pilnowaliśmy jakości przed wydaniem?
Własne moduły przeszły 9 przeglądów kodu i testy QA. Wyłapaliśmy w nich 11 krytycznych błędów i naprawiliśmy wszystkie przed wydaniem. Między innymi:
- brak sprawdzania uprawnień na poziomie pojedynczego rekordu,
- SSRF w webhooku Slacka,
- 9 z 10 triggerów w rule builderze nigdy się nie odpalało,
- unikalność pól nie uwzględniała rekordów usuniętych miękko (soft-delete).
Najciekawszy był problem systemowy w naszym kodzie. Własne endpointy nie miały organization_id w zakresie zapytań. Poprawka: organizację bierzemy z rekordu, a nie z sesji użytkownika. Bramka jakości przed wydaniem to 872 testy i tłumaczenia: 2388 kluczy w 4 językach.
Gdzie hostować CRM na Open Mercato?
System ŁSSE hostujemy na własnym serwerze. Aplikacja, PostgreSQL, Redis i Meilisearch działają w kontenerach Dockera, a dane nie trafiają do zewnętrznego dostawcy SaaS. Dla instytucji, która przetwarza dane startupów i ekspertów, to prostsza rozmowa o RODO niż przy CRM w chmurze poza UE.
Open Mercato nie narzuca hostingu. Tę samą aplikację można postawić na serwerze klienta albo w wybranej chmurze w UE, bo całość to standardowy stos: Node.js, PostgreSQL, Redis i Meilisearch.
Dedykowany CRM czy HubSpot i Pipedrive?
| Gotowy CRM | CRM na Open Mercato | |
|---|---|---|
| Typowy lejek sprzedaży | Lepszy wybór | Przerost formy |
| Własny model danych (programy, oceny, kamienie milowe) | Obejścia polami własnymi | Model pod proces |
| Start | Od razu | Tygodnie pracy programisty |
| Dane i hosting | U dostawcy | Tam, gdzie zdecydujesz |
Jeśli sprzedajesz i potrzebujesz lejka, kup gotowy CRM. Jeśli Twój proces to nabory, oceny i opieka nad portfelem firm, jak w akceleratorze ŁSSE, framework oszczędza mniej więcej połowę pracy, a drugą połowę piszesz dokładnie pod swój proces. W ASAPDevs prowadzimy takie projekty od przeglądu wymagań do wdrożenia. Zobacz, jak wygląda nasz dedykowany CRM na Open Mercato. Integrujesz sprzedaż z marketplace’ami? Przeczytaj też, jak działa opis oferty w Allegro API.
