Własny CRM dla małej firmy: nowy moduł pod każdy problem

Z gotowymi narzędziami do prowadzenia firmy mieliśmy ciągle ten sam kłopot: płacisz za mnóstwo funkcji, używasz kilku, a tej jednej, której naprawdę potrzebujesz, nie ma. Albo jest, ale działa według cudzego procesu i to firma ma się dopasować do programu. Dlatego od kilku miesięcy budujemy własny CRM dla małej firmy, czyli dla siebie: Kosari CRM. Zasada jest jedna i bardzo prosta. Każdy powtarzalny problem w firmie dostaje swój moduł. W ostatnich tygodniach nowy obszar dochodzi mniej więcej co tydzień.

W tym wpisie pokazujemy, jak to wygląda w praktyce, od czego zaczęliśmy, jak dziś powstaje nowy moduł i gdzie są granice takiego podejścia. Bo są, i lepiej o nich wiedzieć przed startem.

Skąd w ogóle pomysł na własny system

Prowadzimy firmę, która robi strony, sklepy, platformy kursowe i automatyzacje. To oznacza mieszankę procesów, której nie obsługuje żaden jeden gotowiec: sprzedaż i oferty, projekty z checklistą wdrożenia, abonamenty z pakietami godzin, czas pracy, faktury, płatności z banku, kopie zapasowe stron klientów, zespół i jego dokumenty. Każda z tych rzeczy siedziała kiedyś w innym narzędziu albo w arkuszu, a przepisywanie danych między nimi zjadało czas.

Pierwsza wersja naszego systemu była wtyczką WordPress: około 19 tysięcy linii PHP i około 50 tabel w bazie, z integracjami z systemem do faktur, Telegramem, pocztą i automatyzacjami. Działała, ale WordPress nie jest dobrym fundamentem dla aplikacji, która ma liczyć pieniądze i obsługiwać kilka firm naraz. W marcu 2026 roku zakończyliśmy przenoszenie wszystkiego do osobnej aplikacji.

Na czym stoi: prosto i na lata

Wybraliśmy technologie nudne w najlepszym sensie: Python z Flaskiem, baza PostgreSQL, Redis do kolejek i pamięci podręcznej, całość w kontenerach Docker na własnym serwerze VPS. Interfejs to lekki HTMX i Alpine.js, bez ciężkiego frameworka. Aplikacja działa w przeglądarce i instaluje się na telefonie jak zwykła aplikacja.

Jedną decyzję podjęliśmy od pierwszego dnia: system jest wielofirmowy. Każdy rekord w bazie ma przypisaną firmę, do której należy. Kosztowało to trochę więcej pracy na starcie, ale dzięki temu panel klienta, panel pracownika i dane różnych firm nigdy się nie mieszają, a dołożenie kolejnej firmy nie wymaga przebudowy.

Proces: problem, potem moduł, nigdy odwrotnie

Najważniejsza zasada brzmi: nie budujemy funkcji „na zapas”. Moduł powstaje dopiero wtedy, gdy ten sam problem wraca, kosztuje czas albo pieniądze i nie da się go rozwiązać prościej. Zanim cokolwiek napiszemy, przechodzimy przez pięć pytań w ustalonej kolejności.

Usuwanie dotyczy też samego systemu. W październiku wycięliśmy cały moduł map myśli, razem z danymi, bo przestał być potrzebny. Wcześniej wyłączyliśmy moduł skupienia, który się nie sprawdził. Każde takie usunięcie robimy odwracalnie: kopia danych i kodu zostaje w archiwum, na wypadek gdyby się okazało, że jednak czegoś brakuje.

Jak to wygląda w praktyce: kilka modułów i problemów, z których powstały

Wyciągi bankowe i faktury

Problem: ręczne sprawdzanie, kto zapłacił. Rozwiązanie: system pobiera wyciągi z banku przez oficjalne API, sam łączy wpłaty z fakturami, gdy jest pewny dopasowania, a resztę pokazuje do decyzji. Opisaliśmy to szerzej we wpisie o tym, jak księgowość firmy robi się sama. W październiku doszedł do tego alarm: jeśli połączenie z bankiem się zerwie albo zgoda zbliża się do wygaśnięcia, dostajemy maila, zanim cokolwiek przestanie działać.

Czas pracy, pakiety godzin i rozliczenia

Problem: klienci z abonamentem mają pakiet godzin, a miesiące są nierówne. Rozwiązanie: stoper przy każdym projekcie i zadaniu, czas trafia sam do kolejki płatności, a niewykorzystane godziny i nadgodziny przechodzą na kolejne miesiące jak kula śnieżna. Klient widzi te same liczby u siebie w panelu. Projekt ma jeden z trzech typów rozliczenia: abonament godzinowy, wycena albo praca bez rozliczenia, i to on decyduje, co dzieje się z czasem.

Wdrożenia platform kursowych

Problem: kilkaset powtarzalnych kroków przy każdym wdrożeniu i ryzyko, że coś umknie. Rozwiązanie: proces wdrożenia jako checklista w projekcie, z właścicielem każdego punktu, także punktów wykonywanych automatycznie. Startowaliśmy w sierpniu od 216 punktów zaimportowanych z wcześniejszej, lokalnej wersji.

Zespół, dokumenty i opinie

Problem: comiesięczne umowy zlecenia i rachunki przygotowywane ręcznie. Rozwiązanie: pierwszego dnia miesiąca system sam generuje dokumenty i zapisuje je na Dysku Google, a pracownik ma własny panel z dokumentami. Podobnie z opiniami klientów: jeden link, formularz z obowiązkową zgodą na publikację i przejście do wizytówki Google.

Jak AI skraca drogę od pomysłu do działającego modułu

Gdyby każdy moduł pisać klasycznie, tempo byłoby kilka razy wolniejsze. Kod pisze u nas Claude Code, a człowiek opisuje problem, podejmuje decyzje i sprawdza wynik. Żeby to działało przewidywalnie, AI pracuje według stałej procedury, a nie „z głowy”:

1. znajduje w kodzie miejsce, którego dotyczy zmiana,
2. pobiera aktualną wersję pliku z serwera i robi kopię zapasową,
3. wprowadza zmianę i pisze do niej test,
4. przebudowuje aplikację,
5. sprawdza, że zmiana naprawdę działa na serwerze, a nie tylko, że komenda zakończyła się sukcesem.

Ostatni punkt nauczył nas pokory. Na początku zdarzało się, że restart aplikacji wyglądał na wdrożenie, a kontener dalej działał na starym kodzie. Od tamtej pory weryfikacja na żywym systemie jest obowiązkowym krokiem, a nie dobrą praktyką. Większe moduły mają własne zestawy testów: na przykład moduł opinii klientów przed wdrożeniem przeszedł 44 sprawdzenia.

Granice tego podejścia: co może pójść źle

Własny system to nie same plusy. Oto rzeczy, które realnie nas kosztowały:

• Dwie drogi do tego samego wyniku. W pewnym momencie te same godziny mogły trafić do rozliczenia dwiema niezależnymi ścieżkami. Wyszło to przy analizie rozliczeń jednego klienta. Wniosek: przy każdym nowym module trzeba sprawdzić, czy coś już nie liczy tego samego.
• Logika oparta na złym sygnale. Blokada zamkniętego miesiąca opierała się na statusie faktur, a abonamenty fakturujemy z góry. Efekt: wpisy czasu pracy z bieżącego miesiąca po cichu przesuwały się na następny. Teraz zamknięcie miesiąca to osobny, jawny rejestr.
• Utrzymanie. Każdy moduł trzeba potem utrzymywać: aktualizacje, kopie bazy, monitoring. Gotowy CRM robi to za Ciebie, własny nie.
• Zależność od wiedzy. System jest tak dobry, jak jego dokumentacja. Dlatego mapa modułów i lekcje z błędów są prowadzone na bieżąco, a nie „kiedyś”.

Uczciwa odpowiedź na pytanie „czy budować własny CRM” brzmi więc: tylko jeśli Twoje procesy naprawdę nie mieszczą się w gotowcu i jesteś gotów traktować system jako produkt, a nie jednorazowy projekt.

Czy własny CRM jest dla Twojej firmy? Szybki test

1. Wypisz procesy, które dziś przepisujesz ręcznie między narzędziami. Jeśli jest ich mniej niż trzy, gotowy CRM prawdopodobnie wystarczy.
2. Sprawdź, ile płacisz miesięcznie za narzędzia, z których korzystasz w małej części.
3. Zastanów się, który jeden problem kosztuje Cię najwięcej czasu co tydzień. Od niego zaczyna się pierwszy moduł, nie od „całego systemu”.
4. Upewnij się, że ktoś będzie ten system utrzymywał po wdrożeniu.
5. Rozważ wersję pośrednią: gotowy CRM plus jedna lub dwie integracje dopisane pod Twój proces.

Czego nauczyło nas te kilka miesięcy

Najlepsze moduły powstały z najprostszych pytań: „dlaczego robię to ręcznie po raz piąty?”. Moduły, które nie rozwiązywały żadnego powtarzalnego problemu, po prostu przestawały być używane, i część z nich już usunęliśmy. Własny system ma sens wtedy, gdy rośnie razem z firmą, krok po kroku, a nie gdy próbuje od razu zrobić wszystko.

FAQ

Ile kosztuje własny CRM dla małej firmy?

To zależy od zakresu. Najtaniej zacząć od jednego modułu, który rozwiązuje najbardziej kosztowny problem, i rozbudowywać system stopniowo. Koszt całego systemu na start to zwykle przepłacanie za funkcje, których jeszcze nie potrzebujesz.

Czy własny CRM jest lepszy od gotowego?

Nie zawsze. Gotowy CRM wygrywa, gdy Twój proces jest typowy, a ty nie chcesz zajmować się utrzymaniem. Własny ma przewagę, gdy łączysz kilka obszarów, których nie obsługuje jedno narzędzie, na przykład sprzedaż, projekty, czas pracy i bank.

Na jakiej technologii budować własny CRM?

Na sprawdzonej i nudnej. U nas to Python z Flaskiem, PostgreSQL, Redis i Docker. Ważniejsze od technologii jest to, żeby od początku uwzględnić kopie zapasowe, uprawnienia i rozdzielenie danych różnych firm.

Ile trwa zbudowanie jednego modułu?

Prosty moduł z pomocą AI powstaje w dni, a nie miesiące. Najwięcej czasu zajmuje nie pisanie kodu, tylko ustalenie, jak proces ma naprawdę działać, i sprawdzenie modułu na prawdziwych danych.

Czy AI wystarczy, żeby zbudować własny system?

AI przyspiesza pisanie kodu, ale nie zastąpi decyzji, co budować, i weryfikacji, czy to działa. Bez stałej procedury, testów i sprawdzania na żywym systemie AI potrafi równie szybko wprowadzić błąd, jak go naprawić.

Czy da się połączyć własny CRM z bankiem i fakturami?

Tak. Banki udostępniają wyciągi przez oficjalne API, a systemy do faktur mają własne interfejsy. U nas połączenie wyciągów z fakturami działa automatycznie, a wątpliwe przypadki trafiają do ręcznej decyzji.

Potrzebujesz systemu dopasowanego do Twojej firmy? Napisz do nas

Jeśli Twoja firma pracuje w kilku narzędziach naraz, a dane przepisuje się ręcznie, pomożemy ustalić, od którego problemu zacząć: integracji, automatyzacji czy własnego modułu. Budujemy rozwiązania na tym samym procesie, który opisaliśmy wyżej, także z wykorzystaniem agentów AI.

Napisz do nas – ustalimy, który proces w Twojej firmie warto zautomatyzować najpierw