Subskrypcje kontra rozliczanie według użycia: co przechowywać od pierwszego dnia

Dlaczego modele cenowe potrzebują planu danych

Cennik to nie tylko strona na twojej witrynie. Decyduje, co trzeba zapisać, jak to raportować i czy po miesiącach potrafisz wytłumaczyć opłatę. Wybierając subskrypcje kontra rozliczanie według użycia, wybierasz też kształt swoich danych rozliczeniowych.

Prosta subskrypcja często wystarczy do obliczenia z kilku faktów: plan, okres rozliczeniowy, data rozpoczęcia i rabaty. Rozliczanie według użycia wymaga więcej: co zostało zużyte, kiedy to się zdarzyło, do którego klienta należy i jak to użycie przełożyć na pieniądze. Bez tych zapisów nadal możesz wysyłać faktury, ale nie obronisz ich później.

Dodanie rozliczania według użycia później, bez planu, zwykle psuje się w trzech miejscach:

• Brakuje wiarygodnej historii użycia, więc klienci kwestionują opłaty.
• Analityka staje się domysłami, bo zespoły różnie definiują "użycie".
• Finanse nie mogą przeprowadzić audytu faktur, bo surowe dane zniknęły lub zostały nadpisane.

Cel jest nudny, ale kluczowy: obliczyć tę samą fakturę w ten sam sposób za każdym razem. To oznacza, że możesz odtworzyć kalkulację z zapisanych faktów (warunki planu, reguły mierników, zdarzenia użycia i dokładna wersja cen, która miała zastosowanie).

"Widok modelowy" to po prostu opisanie rozliczeń jako bloków budulcowych, które do siebie pasują, nawet jeśli nie jesteś inżynierem. Wyobraź sobie produkt do czatu zespołowego:

• Subskrypcja: 99 USD za workspace miesięcznie
• Użycie: 0,01 USD za wiadomość po przekroczeniu 50 000 wiadomości

Aby obsłużyć to później, twoje dane muszą odpowiadać na pytania: który workspace, który miesiąc, ile wiadomości, co było wliczone i które reguły cenowe były aktywne.

Subskrypcje kontra użycie: jak to wygląda w praktyce

Subskrypcje pobierają opłatę za dostęp. Rozliczanie według użycia pobiera opłatę za konsumpcję. Zachowują się bardzo różnie, gdy pojawiają się ulepszenia, degradacje, proration i rzeczywiste przypadki brzegowe.

W przypadku subskrypcji kluczowe pytanie brzmi: "Czy klient miał prawo korzystać z produktu w tym czasie?" Głównie śledzisz plan, liczbę miejsc, okres rozliczeniowy i czy faktura została opłacona. Użycie nadal ma znaczenie, ale często pojawia się jako limity (miękkie lub twarde) zamiast pojedynczych pozycji.

W przypadku rozliczania według użycia kluczowe pytanie staje się: "Co dokładnie się wydarzyło i kiedy?" Potrzebujesz wiarygodnego pomiaru, jasnych reguł kiedy użycie jest liczone i sposobu, by później wytłumaczyć każdą opłatę. Nawet jeśli UI pokazuje jedną liczbę (np. "1 243 wywołań API"), w tle jest zestaw zdarzeń, które muszą być spójne i audytowalne.

Wiele zespołów B2B SaaS kończy na modelu hybrydowym: opłata podstawowa pokrywająca pakiet oraz opłaty za nadwyżki.

Popularne wzorce hybrydowe

Większość modeli hybrydowych mieści się w kilku znanych kształtach:

• Podstawowa opłata platformowa plus opłata za miejsce
• Opłata podstawowa plus wliczone jednostki (wiadomości, zadania, wywołania API) plus stawka za nadwyżkę
• Plan z poziomami plus dodatek użyciowy (naliczany tylko gdy włączony)
• Minimalne zobowiązanie z odwzorowaniem kredytów zużycia

Przewidywalność pomaga, gdy klienci potrzebują zatwierdzenia budżetu i stałych wydatków miesięcznych. Pay-as-you-go działa lepiej, gdy wartość skaluje się z aktywnością (np. "za przetworzoną fakturę") lub gdy klienci testują produkt i chcą niskiego ryzyka.

Zmiany planów są nieuniknione. Ceny, pakiety i opakowania będą się zmieniać. Projektuj system rozliczeń tak, aby można było dodać nowy miernik, wprowadzić nowy poziom lub zmienić, co znaczy "wliczone", bez przepisywania historii. Praktyczna zasada: przechowuj plan klienta i warunki cenowe takie, jakie obowiązywały w momencie naliczenia, a nie tylko jak wyglądają dziś.

Zdefiniuj mierniki, które da się mierzyć wiarygodnie

Miernik to dokładnie to, za co pobierasz opłatę, zapisane tak jasno, że dwie osoby liczące go otrzymają ten sam wynik. Składa się z trzech części: zdarzenia (co się stało), jednostki (co liczymy) i czasu (kiedy jest liczone).

Większość sporów zaczyna się tutaj. Jedna strona myśli, że płaci za efekty, druga nalicza za mierzalne działanie.

Uczyń miernik jednoznacznym

Wybierz mierniki, które odwzorowują rzeczywiste akcje produktowe i można je rejestrować automatycznie. Typowe przykłady:

• Miejsca (aktywni użytkownicy, którzy mogą się zalogować)
• Wywołania API (udane żądania lub wszystkie żądania)
• Przestrzeń dyskowa (GB w punkcie czasu lub średnia za okres)
• Wiadomości (wysłane, dostarczone, otwarte)
• Minuty obliczeniowe (czas działania zadania)

Następnie zdefiniuj, co się liczy, a co nie. Jeśli naliczasz za wywołania API, zdecyduj, czy retry się liczą, czy liczą odpowiedzi 4xx i 5xx, oraz czy wywołania wewnętrzne twoich integracji są liczone.

Czas ma tak samo duże znaczenie jak jednostka. Miejsca zazwyczaj działają najlepiej jako snapshot w punkcie czasu dla okresu rozliczeniowego. Wywołania API zwykle sumuje się w oknie. Przestrzeń dyskowa jest trudna: klienci oczekują opłaty za "ile przechowywałeś", co zwykle znaczy średnią w czasie, a nie szczyt.

Zdecyduj też o zakresie: per konto, czy per workspace/projekt. Prosta zasada: jeśli zespoły mogą być rozliczane oddzielnie, mierniki powinny być per workspace.

Limity, poziomy i uprawnienia

Uprawnienia to reguły mówiące, co klient może robić w wyniku zakupionego pakietu. Odpowiadają na pytania: ile użytkowników może dodać? Które funkcje są włączone? Jaki wolumen jest dozwolony miesięcznie? Uprawnienia stoją między dostępem a rozliczeniami: kształtują to, co produkt pozwala, podczas gdy mierzenie rejestruje, co faktycznie się wydarzyło.

Trzymaj uprawnienia oddzielnie od logiki mierzenia. Uprawnienia powinny być czytelne i stabilne (plan, dodatki, warunki kontraktu). Mierzenie będzie ewoluować wraz z produktem (nowe zdarzenia, nowe mierniki), i nie chcesz, żeby każda zmiana miernika ryzykowała złamanie dostępu.

Twarde limity, miękkie limity i rozliczanie nadwyżek mogą wyglądać podobnie w UI, ale zachowują się inaczej:

• Twardy limit blokuje akcję po osiągnięciu progu.
• Miękki limit pozwala na akcję, ale ostrzega i oznacza do follow-upu.
• Overage billing pozwala na akcję i nalicza opłatę za nadwyżkę.
• Okres karencji czasowo traktuje twardy limit jak miękki.
• Okresy próbne i darmowe poziomy stosują uprawnienia, ale cena jest inna (często zero) do określonej daty lub progu.

Zdecyduj wcześniej, co się stanie, gdy przekroczony zostanie limit. Przykład: zespół w planie "Starter" ma wliczone 5 miejsc i 10 000 wywołań API miesięcznie. Jeśli zaprosi 6. użytkownika, czy go zablokujesz, zaczniesz naliczać za dodatkowe miejsce, czy pozwolisz przez 7 dni jako okres karencji? Każdy wybór wymaga reguły, którą możesz pokazać na fakturze i w logach wsparcia.

Przechowuj uprawnienia jako zapisy z ograniczeniem czasowym: klient, plan lub dodatek, znaczniki startu i końca, wartości limitów oraz tryb egzekwowania (twardy, miękki, nadwyżka). To utrzymuje spójność decyzji o dostępie i rozliczeniach.

Faktury i okresy rozliczeniowe, które da się audytować

Faktura to nie tylko PDF. To ślad audytu, który odpowiada: kto został obciążony, za co, za jakie daty i według jakich zasad. Jeśli zmienisz ceny, nadal powinieneś móc odtworzyć stare faktury dokładnie tak, jak były.

Zacznij od kilku podstawowych rekordów: Klient, Subskrypcja (lub Kontrakt), Okres rozliczeniowy oraz Faktura z pozycjami. Każda pozycja powinna odnosić się do źródła: opłata planu, podsumowanie użycia lub opłata jednorazowa. To odniesienie sprawia, że rozliczenia są wytłumaczalne, gdy ktoś kwestionuje opłatę.

Okresy rozliczeniowe potrzebują kotwicy i strefy czasowej. "Miesięcznie" to za mało. Przechowuj datę kotwicy cyklu (np. 15-go o 00:00) i strefę czasową używaną do cięcia okresów. Bądź konsekwentny albo będziesz miał błędy o jeden dzień przy zmianie czasu.

Audytowalne faktury zwykle potrzebują:

• period_start i period_end na każdej fakturze i pozycji
• wersję cen (IDs planów/cen) użytych dla tej faktury
• niezmienne sumy: subtotal, podatek, rabaty, amount_due, waluta
• dokładne okno użycia dla pozycji rozliczanych według użycia
• zewnętrzne referencje płatności (ID opłaty procesora) gdzie stosowne

Uznawanie przychodów jest powiązane, ale nie tożsame z naliczaniem. Opłata z góry za subskrypcję zwykle jest rozpoznawana w czasie świadczenia usługi, podczas gdy użycie często rozpoznaje się w momencie dostarczenia. Nawet jeśli trzymasz to na wysokim poziomie, zapisuj wystarczająco dat, by obsłużyć to później.

Traktuj noty kredytowe, zwroty i korekty jako rekordy pierwszej klasy, nigdy jako edycje starych faktur. Jeśli klient się ulepszy w środku cyklu, stwórz pozycję korekcyjną lub notę kredytową, która odwołuje się do oryginalnej faktury i opisuje zastosowaną regułę proration.

Klucze idempotencji mają znaczenie przy generowaniu faktur i próbach pobrań. Jeśli zadanie uruchomi się dwa razy, chcesz jedną fakturę, jedno obciążenie i klarowny log.

Proration i zmiany w środku cyklu

Zmiany w środku cyklu to miejsce, gdzie zaczynają się spory rozliczeniowe. Jeśli ktoś ulepsza plan 20-go, wstrzymuje na tydzień, a potem rezygnuje, potrzebujesz reguł, które zamienią te akcje w liczby sensowne na fakturze.

Zdecyduj, jakie zmiany dopuszczasz i kiedy wchodzą w życie. Wiele zespołów stosuje natychmiastowe ulepszenia, aby klient od razu miał wartość, ale degradacje realizuje się przy odnowieniu, by uniknąć skomplikowanych zwrotów.

Wybierz politykę proration, którą potrafisz wytłumaczyć

Proration może być dzienny, godzinowy lub wcale. Im precyzyjniej, tym więcej znaczników czasu, reguł zaokrągleń i przypadków brzegowych musisz przechować i przetestować.

Zamknij wybory polityki wcześnie:

• Proracja ulepszeń natychmiast, degradacje przy odnowieniu
• Używaj proration dziennej (prostsze niż godzinowa i zwykle wystarczająco sprawiedliwe)
• Zdefiniuj reguły zaokrągleń (np. zaokrąglaj w górę do najbliższego centa)
• Zdecyduj, jak działają wstrzymania (zwrot czasu jako kredyt lub przedłużenie okresu)
• Ustal jasną politykę zwrotów przy rezygnacji (pełny, częściowy, brak)

Modeluj proration jako pozycje faktury

Unikaj ukrytych obliczeń. Reprezentuj proration jako jawne korekty na fakturze, np. obciążenie za pozostały czas na nowym planie i kredyt za niewykorzystany czas na starym planie. Każda pozycja powinna wskazywać dokładne zdarzenie zmiany (change_id) i zawierać okno proration (start_at, end_at), podstawę ilościową/czasową oraz kategorię podatkową.

Mierniki użycia dodają jeszcze jedną decyzję: kiedy plan się zmienia, czy mierniki się resetują, kumulują dalej, czy dzielą na segmenty? Prosty, audytowalny sposób to segmentować użycie według wersji planu. Przykład: klient ulepsza z 10 do 25 miejsc w środku miesiąca. Zachowujesz zdarzenia użycia jak są, ale twoje rating grupuje je według okresu uprawnień aktywnego w danym czasie.

Zdecyduj, co można cofnąć. Pomaga traktować zdarzenia użycia jako ostateczne po zaakceptowaniu, podczas gdy zmiany subskrypcji mogą być odwracalne tylko do czasu finalizacji faktury. Przechowuj zdarzenia zmian i korekty fakturowania, aby móc czysto odtworzyć faktury, gdy reguły ewoluują.

Dane, które musisz przechowywać od pierwszego dnia

Jeśli zaczekasz z projektem danych rozliczeniowych do chwili, gdy klienci się poskarżą, skończysz zgadując. Niezależnie od tego, czy wybierzesz subskrypcję, rozliczanie według użycia czy hybrydowy model B2B SaaS, najbezpieczniejszy punkt startowy to niewielki zestaw rekordów, którymi zawsze możesz się posłużyć do audytu.

Zacznij od jasnej hierarchii klienta. W B2B SaaS płatnikiem zwykle jest konto firmowe, ale użycie często dzieje się wewnątrz workspace'ów lub projektów, a działania wykonują indywidualni użytkownicy. Przechowuj wszystkie trzy poziomy (konto, workspace, użytkownik) i zapisuj, kto co zrobił. Reklamacje często sprowadzają się do pytania "który zespół to zrobił?"

Minimalny projekt bazy rozliczeniowej, który wspiera prawdziwe faktury i czyste dochodzenie:

• Konta i struktura organizacyjna: konto, workspace (lub projekt), użytkownicy, role, kontakt do rozliczeń i pola podatkowe jeśli potrzeba
• Subskrypcje: plan, status, daty start/koniec, ustawienia odnowienia, powód anulowania i wersja cenowa zastosowana przy starcie
• Katalog cen: produkty, składniki planu (opłata bazowa, miejsca, mierniki), progi, waluta i daty obowiązywania
• Dane pomiaru użycia: niezmienny append-only log zdarzeń z timestampem, workspace, użytkownikiem (jeśli dostępny), nazwą miernika, ilością i unikalnym kluczem idempotencji
• Artefakty fakturowania: granice okresów rozliczeniowych, pozycje, sumy, podatki/rabaty i snapshot użytych wejść

Nie polegaj wyłącznie na skumulowanych licznikach. Trzymaj liczniki dla szybkości, ale traktuj log zdarzeń jako źródło prawdy. Prosta zasada: zdarzenia są niezmienne, korekty to nowe zdarzenia (np. ujemna ilość), a każde zdarzenie wiąże się z konkretną definicją miernika.

Przykład: klient twierdzi, że jego "wywołania API" podwoiły się w zeszłym miesiącu. Jeśli możesz wyciągnąć surowe zdarzenia według workspace i dnia, pokażesz, skąd wynikł skok albo wyłapiesz pętlę integracji.

Krok po kroku: od zdarzeń użycia do faktury

Trudność nie tkwi w matematyce. Chodzi o to, by wynik dało się wytłumaczyć miesiącami później, nawet po zmianie planów, cen i klientów.

1) Zacznij od katalogu cen, który potrafi "cofnąć czas"

Skonfiguruj produkty, plany, mierniki i ceny z datami obowiązywania. Nigdy nie nadpisuj starej ceny. Jeśli klient był fakturowany w marcu, musisz móc ponownie uruchomić marzec używając marcowego katalogu.

Przykład: "Wywołania API" kosztują 0,002 USD każde od 1 kwietnia. Faktury marcowe nadal muszą używać wcześniejszej stawki.

2) Zrób snapshot uprawnień klienta na okres

Na początku każdego okresu rozliczeniowego (lub gdy nastąpi zmiana) zapisz snapshot uprawnień: plan, wliczone jednostki, limity, reguły progowe, rabaty i ustawienia podatkowe. Traktuj to jako "co obiecaliśmy" na ten okres.

3) Zbieraj zdarzenia użycia i waliduj je wcześnie

Użycie powinno przychodzić jako niezmienne zdarzenia: timestamp, klient, miernik, ilość i unikalny identyfikator do deduplikacji. Waliduj podstawy przy odbiorze (brakujący miernik, ujemna ilość, niemożliwe znaczniki czasu) i zapisuj surowe zdarzenie nawet jeśli jednocześnie tworzysz "oczyszczoną" wersję.

Następnie przeprowadź kalkulację w dwóch krokach:

• Agreguj zdarzenia do sum per klient, miernik i okres rozliczeniowy (i zapisuj wersję agregacji)
• Przelicz sumy na opłaty używając katalogu cen i snapshotu uprawnień (wliczone jednostki, cena za nadwyżkę, progi)

Generuj pozycje faktury, które odwołują się do dokładnych wejść (wersja katalogu, id snapshotu, id agregacji).

Na koniec zablokuj fakturę. Zapisz wejścia i wyjścia kalkulacji, oznacz ją jako finalną i uniemożliwiaj jej zmianę, gdy przyjdą późne zdarzenia. Późne zdarzenia powinny trafić do następnej faktury (lub osobnej korekty) z jasną adnotacją audytową.

Potrzeby raportowe klienta i zespołu wewnętrznego

Klienci nie przejmują się tym, czy wybrałeś subskrypcję czy rozliczanie według użycia. Zależy im, żeby twoje liczby zgadzały się z ich i żeby mogli przewidzieć kolejną opłatę.

Raportowanie dla klienta działa najlepiej jako prosty "panel rozliczeń", który odpowiada na kilka pytań bez otwierania ticketów:

• Na jakim jestem planie i co on zawiera?
• Ile zużyłem w tym okresie i jak liczone jest użycie?
• Jakie mam limity i co się stanie po ich przekroczeniu?
• Kiedy kończy się okres rozliczeniowy i jaka jest szacunkowa następna faktura?
• Gdzie zobaczę wcześniejsze faktury i płatności?

Wewnętrznie wsparcie i finanse muszą umieć wytłumaczyć liczbę, a nie tylko ją pokazać. To znaczy: wychwytywać skoki, śledzić zmiany i oddzielać kalkulacje podglądu od sfinalizowanych faktur.

Trzymaj podglądy faktur oddzielnie od faktur. Podglądy mogą być przeliczane, gdy pojawi się późne użycie lub gdy dopracujesz definicję miernika. Faktury finalne nie mogą się zmieniać.

Twoje raporty wewnętrzne powinny ułatwiać oznaczanie anomalii (nagłe skoki użycia, ujemne użycie, duplikaty), odtworzenie pozycji faktury z surowych danych i zobaczenie zmian planu oraz reguł proration obowiązujących w danym okresie.

Ślady audytu są ważniejsze niż większość zespołów przewiduje. Jeśli klient mówi: "Ulepszyliśmy 12-go", potrzebujesz znacznika czasu, aktora (użytkownik, admin, automatyzacja) i dokładnych wartości przed/po dla planu, miejsc, limitów i stawek mierników.

Dla retencji przechowuj surowe zdarzenia użycia i finalne artefakty faktur przez długi czas. Praktyczna zasada: jeśli coś może zmienić naliczoną kwotę albo pomóc w obronie rozliczenia w sporze, przechowaj to niezmiennie.

Częste pułapki powodujące spory rozliczeniowe

Większość sporów nie dotyczy ceny. Powstają, gdy nie potrafisz wytłumaczyć liczby na fakturze lub gdy te same wejścia dają inny wynik później.

Częstym błędem jest trzymanie tylko miesięcznych sum. Bez surowych zdarzeń nie odpowiesz na proste pytania typu "Który dzień przepchnął nas ponad limit?". Trzymaj zdarzenie, potem agreguj.

Inny częsty problem to zmiana znaczenia miernika bez jego wersjonowania. "Aktywny użytkownik" może najpierw znaczyć "zalogował się przynajmniej raz", a później "utworzył rekord". Jeśli nie wersjonujesz definicji mierników, klienci porównają stare faktury z nowymi i nie udowodnisz, która reguła obowiązywała.

Spory zwykle pochodzą z kilku wzorców:

• Uprawnienia egzekwowane tylko w UI (backend nadal pozwala na dodatkowe użycie lub blokuje prawidłowe użycie)
• Jeden pole znacznika czasu używane do wszystkiego (czas zdarzenia, czas ingestii, czas rozliczenia)
• Ignorowanie stref czasowych (użycie o 00:30 czasu lokalnego trafia do złego dnia/miesiąca)
• Zapomniane kotwice rozliczeniowe (niektórzy klienci są fakturowani 1-go, inni od dnia rejestracji)
• Brak śladu audytu zmian planu, cen i limitów

Przykład: klient w Tokio ulepsza plan w środku cyklu 31-go czasu lokalnego. Jeśli zapiszesz tylko timestamp UTC i nie masz kotwicy rozliczeniowej, ulepszenie może wyglądać na 30-tego w twoim systemie, przesuwając proration i użycie do złego okresu.

Najszybszy sposób na utratę zaufania to brak możliwości odtworzenia starej kalkulacji faktury. Przechowuj wejścia (zdarzenia, wersje, kotwice i zastosowane ceny), aby później ponowne uruchomienie tej samej logiki dawało ten sam wynik, nawet po zmianach w produkcie.

Szybkie kontrole przed wypuszczeniem rozliczeń

Zanim wystartujesz, zrób jeden test: wybierz losowego klienta i odtwórz jego ostatnią fakturę używając tylko zapisanych danych. Jeśli potrzebujesz "czegoś, co kod robił wtedy", to nie masz śladu audytu.

Upewnij się, że każdy miernik jest jednoznaczny. Miernik potrzebuje jasnej jednostki (żądania, miejsca, GB, minuty), zaufanego źródła (która usługa go emituje) i okna czasowego (na dzień, na okres rozliczeniowy, na miesiąc). Jeśli nie potrafisz wyjaśnić miernika jednym zdaniem, klienci mu nie zaufają.

Szybkie kontrole, które łapią większość problemów:

• Potrafisz odtworzyć fakturę z wejść: wersji planu, cen, sum użycia, podatków, rabatów i parametrów proration
• Zdarzenia użycia są append-only, niezmienne i z deduplikacją (klucz idempotencji lub id zdarzenia)
• Zmiany planów i cen są wersjonowane z datami obowiązywania (nie nadpisuj starych cen)
• Reguły proration są opisane prostym językiem i objęte testami
• Support potrafi szybko odpowiedzieć "dlaczego zostałem obciążony" używając tych samych zapisanych faktów

Przykład: klient ulepsza z 10 do 25 miejsc 18-go i przekracza próg użycia 23-go. Twój system powinien pokazać (1) która wersja planu była aktywna w każdej dacie, (2) zdarzenie zmiany miejsc z timestampem, (3) zastosowany wzór proration i (4) zdarzenia użycia zsumowane do końcowego wyniku.

Kolejne kroki: wdrażaj, nie zamykając sobie drogi do manewru

Zacznij mało, ale nie zaczynaj nieprecyzyjnie. Najbezpieczniejsza ścieżka to najmniejszy model danych, który nadal pozwala odpowiedzieć na jedno pytanie miesiącami później: "Dlaczego obciążyliśmy tę kwotę?"

Prototypuj schemat rozliczeń i ekrany administracyjne wcześnie, zanim pojawi się pierwsza zmiana cen. Jeśli poczekasz, aż sprzedaż poprosi o nowy poziom lub zmianę w środku cyklu, będziesz łatany logiką w zbyt wielu miejscach.

Praktyczny podział: pozwól Stripe obsługiwać pobrania, potwierdzenia i ponowne próby płatności, ale trzymaj rating (jak użycie staje się pozycjami) we własnym systemie. To znaczy: zapisujesz surowe zdarzenia użycia, wersje cen i wyniki kalkulacji używane do generowania podglądu faktury.

Prosty plan startowy, który pozostanie elastyczny:

• Wybierz 1–2 mierniki, które możesz mierzyć wiarygodnie (np. aktywne miejsca dziennie i wywołania API)
• Wersjonuj reguły cenowe od pierwszego dnia, żeby stare faktury zgadzały się ze starymi regułami
• Zbuduj wewnętrzny panel administracyjny rozliczeń, by przeglądać użycie, nadpisania, kredyty i spory
• Dodaj podstawowy portal klienta: bieżący plan, użycie w okresie, przewidywana faktura
• Traktuj każdą fakturę jako audytowalny snapshot, nie jako przeliczane zgadywanie

Jeśli chcesz działać szybko bez pisania dużo customowego back-office, możesz zamodelować te encje w AppMaster i zbudować ekrany administracyjne jego narzędziami wizualnymi, trzymając PostgreSQL jako system zapisu zdarzeń i faktur.

Konkret: startujesz z jednym miernikiem miejsc. Po trzech miesiącach dodajesz GB storage. Jeśli mierniki, uprawnienia i reguły cenowe są wersjonowane, wprowadzenie nowego miernika nie złamie wcześniejszych faktur, a support wyjaśni każdą pozycję w minutach.