W większości projektów IT termin jest przedmiotem negocjacji. Klient chce wcześniej, zespół prosi o dwa tygodnie więcej, ktoś przesuwa release o sprint i świat się nie kończy. Projekt regulacyjny działa inaczej: data wejścia obowiązku w życie jest zapisana w ustawie, a ustawy nie da się przenegocjować na stand-upie.
Kiedy zaczynaliśmy pracę nad własnym produktem SaaS obsługującym obowiązkowe e-fakturowanie, mieliśmy jeden punkt odniesienia, którego nikt nie mógł ruszyć. Harmonogram KSeF został potwierdzony ustawą z 5 sierpnia 2025 r., podpisaną przez Prezydenta 27 sierpnia 2025 r. Od 1 lutego 2026 r. obowiązek objął dużych podatników, od 1 kwietnia 2026 r. pozostałe firmy, a od 1 stycznia 2027 r. obejmie mikroprzedsiębiorców. Trzy daty. Zero elastyczności.
To case study procesowe, nie technologiczne. Nie opowiemy o wyborze frameworka. Opowiemy o tym, jak podejmowaliśmy decyzje o zakresie, co świadomie wycięliśmy z MVP i jak zbudowaliśmy produkt, który przetrwał zmianę przepisów w trakcie własnej realizacji.
Dlaczego projekt regulacyjny to zupełnie inna klasa ryzyka
Klasyczny trójkąt projektowy zakłada, że manewrujesz trzema zmiennymi: zakresem, czasem i budżetem. W projekcie pod deadline ustawowy jedna z nich zamienia się w beton. Zostają dwie — i tylko jedna z nich jest naprawdę elastyczna.
Skala ryzyka jest dobrze udokumentowana. Badanie McKinsey we współpracy z Uniwersytetem Oksfordzkim, obejmujące ponad 5 400 dużych projektów IT, wykazało, że przeciętnie przekraczają one budżet o 45%, harmonogram o 7% i dostarczają o 56% mniej wartości, niż zakładano. W projekcie komercyjnym te 7% opóźnienia to niedogodność. W projekcie regulacyjnym to moment, w którym klienci tracą zdolność legalnego wystawiania faktur.
Trzy typy terminów i tylko jeden naprawdę twardy
Warto rozróżnić, z jakim terminem mamy do czynienia, bo od tego zależy cała logika planowania:
Termin biznesowy — chcemy wejść na rynek przed konkurencją. Przesuwalny, kosztuje udział w rynku.
Termin kontraktowy — zapisany w umowie z klientem. Przesuwalny, kosztuje karę umowną lub relację.
Termin ustawowy — zapisany w akcie prawnym. Nieprzesuwalny, kosztuje zgodność z prawem.
Tylko trzeci typ wymusza odwrócenie standardowego procesu planowania. Nie pytasz „ile czasu zajmie zbudowanie tego zakresu?”, tylko „jaki zakres da się zbudować do tej daty?”. To pozornie kosmetyczna różnica, która przebudowuje cały sposób pracy zespołu.
Konsekwencja: zakres staje się jedyną zmienną
Budżet w projekcie produktowym też jest w praktyce sztywny — nie dorzucisz w połowie drogi drugiego tyle pieniędzy ani nie zwiększysz zespołu dwukrotnie bez utraty tempa. Prawo Brooksa działa niezależnie od branży: dodanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej.
Zostaje więc zakres. I to on musi być przedmiotem najbardziej dyscyplinowanych decyzji w całym przedsięwzięciu. Nie „co byłoby fajne”, tylko „bez czego klient 1 kwietnia złamie prawo”.
Priorytetyzacja zakresu: co weszło do MVP, a co odłożyliśmy
Standish Group od lat pokazuje w swoich badaniach, że znacząca większość funkcji w systemach biznesowych jest używana rzadko albo wcale — w klasycznej analizie tej organizacji około 45% funkcjonalności nie było używane nigdy. W projekcie bez presji czasu to marnotrawstwo. W projekcie pod ustawę to zagrożenie egzystencjalne, bo każda godzina włożona w funkcję opcjonalną jest godziną odjętą od funkcji obowiązkowej.
Przyjęliśmy jedno kryterium nadrzędne, które rozstrzygało każdy spór o priorytet.
Kryterium: „czy bez tego klient łamie prawo?”
Każdą propozycję funkcji przepuszczaliśmy przez trzystopniowy filtr:
Blokujące zgodność — bez tego użytkownik nie może wykonać obowiązku ustawowego. Wchodzi do MVP bez dyskusji.
Blokujące operacyjnie — użytkownik formalnie spełni obowiązek, ale proces będzie na tyle uciążliwy, że praktycznie nieużywalny. Wchodzi, jeśli zmieści się w oknie czasowym.
Podnoszące wartość — poprawia doświadczenie, oszczędza czas, wyróżnia produkt. Nie wchodzi przed datą graniczną. Kropka.
Brzmi banalnie, dopóki nie trzeba zastosować tego wobec funkcji, którą naprawdę chce się zbudować. Dyscyplina polega na tym, żeby nie przesuwać rzeczy z kategorii trzeciej do pierwszej za pomocą kreatywnej argumentacji.
Co weszło do pierwszej wersji
Zakres MVP zamknął się w kilku obszarach, z których każdy odpowiadał bezpośrednio na obowiązek wynikający z przepisów:
Wystawianie i wysyłka faktur ustrukturyzowanych w obowiązującym schemacie.
Odbiór dokumentów przychodzących — bo od 1 lutego 2026 r. wszyscy podatnicy VAT muszą odbierać faktury z systemu, niezależnie od tego, kiedy zaczynają je wystawiać.
Zarządzanie uwierzytelnianiem i uprawnieniami — kto w firmie ma prawo działać na fakturach.
Obsługa korekt, faktur zaliczkowych i rozliczeniowych, czyli typów dokumentów, bez których księgowość nie domknie miesiąca.
Pobieranie urzędowego potwierdzenia i archiwizacja dowodów wysyłki.
Podstawowa obserwowalność: co poszło, co odrzucono, dlaczego.
Co świadomie odłożyliśmy
Lista rzeczy odłożonych była dłuższa niż lista rzeczy zbudowanych — i to jest zdrowy sygnał, nie porażka:
Rozbudowana analityka i dashboardy menedżerskie.
Automatyczne kategoryzowanie kosztów oparte na uczeniu maszynowym.
Głębokie integracje dwukierunkowe z systemami księgowymi trzecich stron.
Zaawansowane workflow akceptacji wielopoziomowej.
Aplikacja mobilna.
Personalizacja wyglądu dokumentów wykraczająca poza minimum.
Kluczowa zasada, którą stosowaliśmy: odłożone nie znaczy skasowane, ale musi być zapisane. Każda odsunięta funkcja trafiała do rejestru z uzasadnieniem i wstępną datą powrotu. Dzięki temu rozmowa z interesariuszami nie brzmiała „nie zrobimy tego”, tylko „zrobimy to w drugim kwartale po uruchomieniu, a oto dlaczego nie wcześniej”.
Jak rozmawialiśmy o zakresie z interesariuszami
Najbardziej niedoceniana część priorytetyzacji to nie samo podejmowanie decyzji, tylko ich komunikowanie. Osoba odpowiedzialna za sprzedaż widzi w odłożonej funkcji utracony argument w rozmowie z klientem. Osoba z księgowości widzi ryzyko, którego nie widzi zespół produktowy.
Zamiast bronić decyzji, zaczęliśmy pokazywać jej koszt alternatywny. Każda propozycja rozszerzenia zakresu była wyceniana nie w roboczogodzinach, lecz w tym, co musiałoby wypaść z MVP na jej rzecz. Rozmowa „co usuwamy, żeby to dodać?” kończy się zupełnie inaczej niż rozmowa „czy da się to dorzucić?”.
Drugim narzędziem był cotygodniowy, jednostronicowy status z jedną liczbą na górze: liczbą dni do daty ustawowej. Bez wykresów, bez procentu ukończenia. Ta jedna liczba porządkowała wszystkie priorytety skuteczniej niż jakikolwiek dokument planistyczny.
Okres przejściowy, czyli kilka wersji rzeczywistości naraz
Najtrudniejszy element całego przedsięwzięcia nie miał nic wspólnego z samym uruchomieniem. Chodziło o to, że ustawodawca — słusznie — nie przełącza całej gospodarki jednym pstryczkiem. Rozłożony harmonogram oznacza, że przez wiele miesięcy w obrocie funkcjonują równolegle różne stany prawne.
W praktyce nasz produkt musiał jednocześnie obsługiwać: firmy już objęte obowiązkiem, firmy jeszcze nieobjęte, ale zobowiązane do odbioru, oraz podmioty korzystające z wyłączeń przejściowych. Wyłączenie dla najmniejszych podatników dotyczyło transakcji do 450 zł dla pojedynczej faktury i do 10 tys. zł miesięcznej sprzedaży — a to oznacza, że system musi znać kontekst każdego klienta, nie tylko kalendarz.
Wersjonowanie schemy jako funkcja produktu, nie dług techniczny
Największy błąd, jaki można popełnić w takim projekcie, to potraktowanie formatu danych jako czegoś stałego. Schemat faktury ustrukturyzowanej zmienił się w trakcie wdrożenia — nowa wersja zastąpiła poprzednią, wprowadzając między innymi dedykowane pola powiązujące fakturę rozliczeniową z zaliczkową.
Zaprojektowaliśmy więc obsługę wielu wersji schemy jako pierwszorzędną funkcję systemu. Dokument przechowywany jest w modelu wewnętrznym, niezależnym od formatu urzędowego, a translacja do konkretnej wersji odbywa się na wyjściu, w zależności od daty i kontekstu podatnika. Ta jedna decyzja architektoniczna zwróciła się kilkukrotnie.
Dane migrują wolniej niż przepisy
Druga lekcja okresu przejściowego dotyczy dokumentów historycznych. Faktura wystawiona w starym reżimie musi pozostać czytelna, korygowalna i archiwizowana przez lata po zmianie przepisów. Korekta do dokumentu sprzed zmiany formatu to osobny, nietrywialny przypadek biznesowy — organ podatkowy wydawał zresztą w tej sprawie interpretacje indywidualne.
Wniosek dla każdej firmy planującej podobne wdrożenie: zaplanuj obsługę przeszłości, zanim zaplanujesz obsługę przyszłości. Migracja danych historycznych to zwykle najbardziej niedoszacowany element harmonogramu.
Kiedy przepisy zmieniają się w trakcie budowy
Najbardziej pouczający moment projektu nadszedł już po uruchomieniu pierwszej fazy. 9 czerwca 2026 r. w Ministerstwie Finansów odbyły się otwarte konsultacje po częściowym wdrożeniu systemu, na których przedstawiono propozycje usprawnień.
Jedna z nich dotyczyła bezpośrednio warstwy, którą już mieliśmy zbudowaną. Tokeny jako metoda uwierzytelnienia miały być wygaszane do końca 2026 r., ale w odpowiedzi na postulaty rynku ministerstwo zaproponowało ich utrzymanie także po 31 grudnia 2026 r. Jako uzasadnienie wskazano zainteresowanie tym narzędziem, bezpieczeństwo jego użytkowania i wygodę w codziennej pracy. W propozycji pojawił się też termin ważności tokenów od 1 do 365 dni oraz mechanizm automatycznego odnawiania za zgodą właściciela.
Dlaczego to była dobra wiadomość, która mogła być katastrofą
Zbudowaliśmy warstwę uwierzytelniania z założeniem, że tokeny zostaną wycofane, a certyfikaty staną się metodą docelową. Gdyby ta warstwa była wpleciona bezpośrednio w logikę biznesową, zmiana kierunku oznaczałaby przepisanie znacznej części systemu w środku sezonu.
Ponieważ metody uwierzytelniania były od początku traktowane jako wymienne wtyczki za wspólnym interfejsem, dostosowanie sprowadziło się do zmiany konfiguracji i dodania obsługi cyklu życia tokenu. Kilka dni pracy zamiast kilku tygodni.
Zasada „projektuj pod kierunek, nie pod literę”
Z tego doświadczenia wyciągnęliśmy regułę, którą stosujemy dziś we wszystkich projektach regulacyjnych: implementuj obecną literę przepisu, ale projektuj strukturę pod kierunek, w którym przepis może pójść. Jeśli konsultacje wskazują, że coś może zostać utrzymane, rozszerzone albo doprecyzowane, ta niepewność powinna być widoczna w architekturze jako punkt elastyczności — a nie ukryta w kodzie jako założenie.
Architektura odporna na zmianę regulacji — cztery zasady
Odporność regulacyjna nie jest cechą technologii. To sposób podziału odpowiedzialności w systemie. Cztery zasady, które sprawdziły się u nas:
1. Reguły biznesowe oddzielone od kodu aplikacji
Progi kwotowe, daty wejścia obowiązków, listy wyjątków i warunki stosowania wyłączeń są danymi konfiguracyjnymi, nie instrukcjami warunkowymi rozsianymi po aplikacji. Zmiana progu to zmiana wpisu, nie wdrożenie nowej wersji.
2. Warstwa izolująca od API instytucji publicznej
Systemy państwowe mają własne tempo zmian, własne limity i własne awarie. Nasz produkt komunikuje się z nimi przez wydzieloną warstwę adaptacyjną, która tłumaczy zewnętrzny model na wewnętrzny. Ma to też wymiar czysto operacyjny: limity zapytań w trybie interaktywnym wynoszą 10 faktur na sekundę, 30 na minutę i 180 na godzinę, a przy pobieraniu odpowiednio 8, 16 i 64. Kolejkowanie i kontrola przepustowości muszą być zaprojektowane od pierwszego dnia, a nie dokładane po pierwszym szczycie sprzedażowym.
3. Przełączniki funkcji powiązane z datami wejścia w życie
Każdy element zakresu zależny od przepisu ma własny przełącznik i własny kalendarz aktywacji. Dzięki temu kod nowego obowiązku trafia na produkcję z wyprzedzeniem, ale „budzi się” dopiero w dniu wejścia w życie — a w razie przesunięcia terminu wystarczy zmienić datę.
4. Pełna audytowalność zamiast nadpisywania
W środowisku regulowanym historia zmian to nie luksus, tylko dowód. Warto zauważyć, że sam ustawodawca idzie w tę stronę — wśród planowanych zmian jest rejestrowanie pełnej historii modyfikacji danych na fakturach, ponieważ dziś kolejne zmiany nadpisują poprzednie, co uniemożliwia prześledzenie procesu. Jeśli państwo dochodzi do wniosku, że potrzebuje pełnej ścieżki audytu, tym bardziej potrzebuje jej system, który ma odpowiadać na pytania kontroli.
Sześć wniosków dla firm przed własnym terminem ustawowym
Skala tego, co się wydarzyło, była realna: system obsłużył ponad 340 mln faktur wystawionych przez ponad 2,1 mln podmiotów. To pokazuje, że przy dobrze poprowadzonym procesie da się dowieźć na czas w skali całej gospodarki. Nasze wnioski:
Ustal datę, od której liczysz wstecz, i uczyń ją nienaruszalną. Wszystkie inne decyzje są jej pochodną.
Zdefiniuj jedno kryterium priorytetyzacji i trzymaj się go mechanicznie. Im mniej miejsca na uznaniowość, tym mniej sporów w krytycznym momencie.
Buduj z myślą o okresie przejściowym, nie o dniu docelowym. Współistnienie wersji trwa dłużej niż samo przełączenie.
Traktuj niepewność regulacyjną jako wymaganie architektoniczne. Tam, gdzie przepis może się zmienić, potrzebujesz punktu wymiany.
Uruchamiaj wcześniej niż musisz. Okres bez sankcji jest czasem na naukę procesu, a nie powodem do zwłoki — sankcje wracają w pełnym zakresie po jego zakończeniu.
Zapisuj to, czego nie zbudowałeś. Rejestr świadomych rezygnacji to jedyna obrona przed pytaniem „a dlaczego tego nie ma?” trzy miesiące później.
Podsumowanie
Projekt pod deadline ustawowy nie jest trudniejszy technicznie od innych. Jest trudniejszy decyzyjnie. Wymaga zgody organizacji na to, że pierwsza wersja będzie węższa, niż ktokolwiek chciał, i że część dobrych pomysłów poczeka.
To, co naprawdę decyduje o powodzeniu, to trzy rzeczy: bezwzględna dyscyplina zakresu, zaprojektowanie okresu przejściowego jako pełnoprawnego stanu systemu oraz architektura, która zakłada, że przepisy jeszcze się zmienią. Bo zmienią się na pewno — pytanie tylko, czy zastaną Cię gotowym.
Jeśli Twoja firma stoi przed własnym terminem regulacyjnym — obowiązkiem raportowym, wymogiem branżowym albo zmianą, która wymusi przebudowę procesów — nie zaczynaj od pytania o technologię. Zacznij od pytania o zakres i o to, co jest gotowe do odłożenia.
Jeśli chcesz stworzyć system dopasowany do procesów Twojej firmy — skontaktuj się z nami. Nasz zespół pomoże Ci przełożyć cele biznesowe na konkretne rozwiązania IT. Umówimy bezpłatną konsultację, na której przeanalizujemy Twój harmonogram, zidentyfikujemy elementy krytyczne dla zgodności i zaproponujemy realny plan wdrożenia.
