B2B SaaS / ERP · 2026
3DPCC – System ERP i Kalkulator dla Drukarni 3D
SaaS ERP B2B dla drukarni 3D. Przepisany z MVP opartego na bezpośrednich zapytaniach do Supabase i Edge Functions w pełny wielodostępny backend Node.js z maszyną stanów zamówień, rezerwacjami stanów i nienaruszalnym logiem audytowym.

- Typ projektu
- B2B SaaS / ERP
- Rok
- 2026
- Technologie
- 19
- Status
- Wdrożone
Projekt i wyzwanie
3DPCC to platforma B2B SaaS dla firm i farm druku 3D, które potrzebują centralnego systemu do zarządzania wycenami, zamówieniami, magazynem i operacjami związanymi z realizacją produkcji. Platforma obsługuje organizacje z wieloma użytkownikami, planami subskrypcji oraz odrębnym kontekstem danych dla każdego klienta.
Projekt był wcześniej rozwijany jako kalkulator wycen wykorzystujący bezpośrednie zapytania frontendu do Supabase oraz rozproszone Edge Functions. Taka architektura była wystarczająca dla początkowej wersji produktu, ale zaczęła ograniczać jego rozwój w kierunku pełnego systemu ERP. Logika biznesowa była rozproszona między frontendem i funkcjami serverless, a operacje obejmujące kilka obszarów systemu stawały się coraz trudniejsze do realizacji w sposób spójny i przewidywalny.
Celem przebudowy było stworzenie fundamentu pod dalszy rozwój 3DPCC jako centralnego systemu operacyjnego dla firm zajmujących się drukiem 3D, z obsługą wielu magazynów, organizacji, klientów, zamówień oraz rygorystycznego cyklu życia rezerwacji stanów magazynowych.
Zakres przebudowy
Prace obejmowały zaprojektowanie i implementację od podstaw dedykowanego backendu Node.js, który przejął logikę biznesową i transakcyjną aplikacji. Frontend został jednocześnie zmigrowany z Next.js SSR do React SPA.
System został rozbudowany o kolejne obszary typowe dla aplikacji ERP i B2B SaaS, w tym zarządzanie magazynem i rezerwacjami, obsługę cyklu życia zamówień, wykrywanie i scalanie duplikatów klientów oraz system uprawnień powiązany z planami subskrypcji.
Najważniejsze obszary systemu
Magazyn i rezerwacje
System obsługuje wiele magazynów w ramach jednej organizacji. Rezerwacja, konsumpcja, zwolnienie oraz wygaśnięcie stanów są realizowane jako kontrolowane operacje transakcyjne, tak aby zmiana jednego elementu procesu nie pozostawiała danych w częściowo zaktualizowanym stanie.
Operacje magazynowe są idempotentne. Ponowienie tego samego żądania po zerwanym połączeniu lub timeoutcie nie powoduje utworzenia podwójnej rezerwacji ani ponownego odjęcia dostępnego stanu.
Zamówienia
Cykl życia zamówienia jest kontrolowany przez zdefiniowaną maszynę stanów, od szkicu, przez potwierdzenie i realizację, aż do zakończenia lub anulowania zamówienia.
Zmiany statusu są powiązane z odpowiednimi operacjami magazynowymi. Potwierdzenie, realizacja lub anulowanie mogą automatycznie konsumować albo zwalniać wcześniejsze rezerwacje, przy zachowaniu spójności w ramach jednej transakcji.
Kwoty finansowe są przechowywane w najmniejszych jednostkach walutowych, co pozwala uniknąć błędów zaokrągleń charakterystycznych dla operacji na liczbach zmiennoprzecinkowych.
Klienci
System wykrywa potencjalne duplikaty klientów na podstawie danych kontaktowych i adresowych.
Rekordy mogą następnie zostać scalone w kontrolowanym i audytowalnym procesie, bez utraty historii powiązanych zamówień. Sam proces scalania jest idempotentny, dzięki czemu ponowienie operacji nie prowadzi do nieprzewidywalnych zmian w danych.
Organizacje i uprawnienia
Platforma działa w modelu multi-tenant. Dane organizacji są izolowane zarówno na poziomie logiki aplikacji, jak i bazy danych.
Role, dostęp do funkcji i limity są rozwiązywane na podstawie aktywnego planu subskrypcji Stripe oraz przypisanych uprawnień. Frontend otrzymuje z API jeden spójny zestaw informacji o dostępnych funkcjach i limitach, na podstawie którego dostosowuje interfejs do bieżącego planu organizacji.
Architektura i bezpieczeństwo
Backend został zaprojektowany jako modularny monolit. Przy obecnej skali produktu mikroserwisy zwiększałyby złożoność infrastruktury, deploymentu i komunikacji pomiędzy usługami bez proporcjonalnych korzyści biznesowych.
Modularny monolit pozwala zachować prostą architekturę operacyjną i spójne transakcje, jednocześnie dzieląc system na wyraźne domeny, takie jak zamówienia, magazyn, klienci czy billing. Zależności pomiędzy nimi są kontrolowane, co ogranicza przenikanie logiki biznesowej między modułami.
Izolacja organizacji działa na dwóch poziomach. Warstwa aplikacyjna ogranicza zapytania do aktywnego kontekstu organizacji, a polityki Row Level Security w PostgreSQL zapewniają dodatkową warstwę kontroli bezpośrednio na poziomie bazy danych. Ogranicza to ryzyko nieautoryzowanego dostępu pomiędzy tenantami również w przypadku błędu w logice aplikacji.
Krytyczne zdarzenia, takie jak zmiany ról, transfer własności organizacji czy akceptacja zaproszeń, są zapisywane w niezmiennym logu audytowym. Wpis powstaje w tej samej transakcji co operacja biznesowa i może zawierać stan danych przed oraz po wykonaniu zmiany. Kod aplikacji może dodawać nowe rekordy audytu, ale nie może modyfikować ani usuwać istniejących.
Frontend
3DPCC jest aplikacją działającą niemal w całości po zalogowaniu, dlatego SSR nie wnosił istotnych korzyści związanych z SEO. Migracja z Next.js do React SPA uprościła architekturę frontendu, obsługę autoryzacji oraz proces wdrażania.
Frontend może być dystrybuowany jako statyczna aplikacja przez CDN, bez konieczności utrzymywania osobnej warstwy renderowania po stronie serwera.
Routing i internacjonalizacja zostały odseparowane od komponentów aplikacji, co ogranicza ich zależność od konkretnych bibliotek. Platforma obsługuje 16 języków, a dodatkowe pakiety tłumaczeń są ładowane dopiero wtedy, gdy są potrzebne użytkownikowi.
Jakość i niezawodność
Pipeline CI automatycznie weryfikuje kod, logikę biznesową, integrację z bazą danych oraz gotowość obrazu produkcyjnego do uruchomienia.
Testy jednostkowe obejmują logikę domenową, natomiast testy integracyjne działają na rzeczywistej instancji PostgreSQL. Weryfikują między innymi idempotentność operacji, polityki RLS oraz zachowanie systemu przy równoległych żądaniach.
Osobny etap sprawdza również budowanie i uruchamianie produkcyjnego kontenera Docker, dzięki czemu błędy związane z konfiguracją środowiska mogą zostać wykryte jeszcze przed wdrożeniem.
API jest opisane zgodnie ze specyfikacją OpenAPI 3.1 i posiada stabilne wersjonowanie, co zapewnia przewidywalny kontrakt dla przyszłych integracji oraz innych klientów korzystających z backendu.
Rezultaty biznesowe
Przebudowa architektury pozwoliła rozwinąć 3DPCC z kalkulatora wycen w system obsługujący szerszy zakres procesów operacyjnych, w tym zamówienia, magazyn, organizacje, klientów i uprawnienia.
Centralizacja logiki biznesowej w dedykowanym API uprościła rozwój kolejnych modułów i umożliwiła wprowadzenie mechanizmów wymagających spójności transakcyjnej, idempotentności oraz kontrolowanego cyklu życia operacji.
Modularny monolit pozwala utrzymać system na stosunkowo prostej infrastrukturze bez kosztów operacyjnych związanych z utrzymywaniem wielu niezależnych usług. Jednocześnie podział na domeny pozostawia możliwość dalszej rozbudowy bez mieszania logiki magazynu, zamówień, klientów i billingów.
Stabilne, wersjonowane API oraz dokumentacja OpenAPI przygotowują platformę pod integracje z zewnętrznymi systemami sprzedaży i kolejne kanały dostępu, w tym aplikacje mobilne. Obecna architektura stanowi fundament pod rozwój kolejnych modułów ERP bez konieczności ponownej przebudowy podstawowych warstw systemu.

Potrzebujesz czegoś podobnego?
Napisz, czego potrzebujesz — dostaniesz konkretny zakres, termin i cenę.
Skontaktuj się