Softech zaprojektował i rozwija KILOGRAM jako produkcyjny ekosystem marketplace dla handlu rolnego, łączący aplikację mobilną, platformę webową, centralne API oraz panel administracyjny. System rozdziela przepływy SELL i BUY, obsługuje wyszukiwanie, profile, ulubione, dokumenty, płatne promowanie, powiadomienia, społeczność, moderację oraz procesy AI wspierające tworzenie opisów i grafik. Architektura oparta na TypeScript, React Native, NestJS, PostgreSQL, Redis i BullMQ utrzymuje jeden model domenowy dla wszystkich kanałów oraz pozwala operatorom kontrolować kolejki, próby generowania, błędy i statusy bez angażowania zespołu developerskiego w każdą codzienną operację. Opis projektu przedstawia potwierdzony zakres systemu i celowo nie publikuje niezatwierdzonych danych o wzroście, konwersji ani liczbie użytkowników.
Kontekst biznesowy i sytuacja przed wdrożeniem
Handel produktami rolnymi odbywa się równolegle przez telefony, komunikatory, grupy społecznościowe, lokalne portale i bezpośrednie relacje. KILOGRAM powstał jako wyspecjalizowana infrastruktura cyfrowa, która porządkuje ofertę i popyt, ale nie zmusza użytkowników do porzucenia szybkiego, mobilnego sposobu działania.
- Sprzedający potrzebują szybkiej publikacji produktów z ilością, jednostką, lokalizacją, zdjęciami i warunkami handlowymi.
- Kupujący muszą publikować zapotrzebowanie i filtrować rynek według produktu, odmiany, ilości, jednostki oraz regionu.
- Operator platformy potrzebuje jednego miejsca do moderacji, obsługi użytkowników, płatnych wyróżnień, dokumentów, błędów i procesów AI.
- Produkt musi działać spójnie w aplikacji mobilnej, przeglądarce i panelu administracyjnym, mimo że każdy kanał ma inne potrzeby UX.
- Model biznesowy wymaga możliwości rozwijania monetyzacji i nowych kanałów dystrybucji bez przebudowy podstawowego przepływu ogłoszenia.
Stan wyjściowy
Przed uruchomieniem wspólnego produktu procesy handlowe i publikacyjne były rozproszone pomiędzy kanałami, a informacje o podaży i popycie nie tworzyły jednolitego modelu danych. Samo dodanie kolejnego portalu ogłoszeniowego nie rozwiązywałoby problemu, ponieważ brakowałoby narzędzi operacyjnych, kontroli AI, monetyzacji i spójności między mobile a web.
- Podaż i zapotrzebowanie były komunikowane w podobny sposób, mimo że wymagają innych formularzy, komunikatów i filtrów.
- Publikacja atrakcyjnego ogłoszenia wymagała samodzielnego przygotowania opisu oraz materiału wizualnego.
- Procesy moderacyjne i wyjaśnianie błędów nie miały jednego audytowalnego centrum operacyjnego.
- Płatne promowanie, dokumenty, powiadomienia i statusy musiały być projektowane jako jeden proces, a nie osobne dodatki.
- Niestabilne połączenie mobilne mogło prowadzić do powtórzeń operacji, niejasnych komunikatów i utraty zaufania użytkownika.
Cele, kryteria sukcesu i ograniczenia
Discovery rozpoczęło się od rozpisania aktorów, stanów ogłoszenia i działań, które muszą być wspólne dla wszystkich kanałów. Zamiast projektować osobno aplikację, portal i panel, zespół zdefiniował centralne reguły domenowe, a następnie dopasował interfejsy do kontekstu sprzedającego, kupującego, moderatora i administratora.
Cele produktu
- Zbudować jeden model domenowy obsługujący osobne przepływy SELL i BUY.
- Zapewnić pełną ścieżkę użytkownika w aplikacji mobilnej i na platformie webowej.
- Dać operatorom samodzielną kontrolę nad moderacją, statusami, płatnościami, dokumentami i procesami AI.
- Wprowadzić kontrolowane AI, które skraca przygotowanie ogłoszenia bez automatycznego publikowania niezweryfikowanego wyniku.
- Przygotować fundament pod płatne wyróżnienia, dodatkowe modele monetyzacji, kolejne języki i zewnętrzne kanały publikacji.
- Zachować obserwowalność i odporność procesów asynchronicznych wymagających retry, idempotencji i historii prób.
Kryteria sukcesu
- Ta sama oferta i stan użytkownika są interpretowane jednakowo przez mobile, web, API i panel administracyjny.
- Użytkownik od początku rozumie, czy publikuje sprzedaż, czy zapotrzebowanie zakupowe.
- Proces AI zapisuje status, wersję promptu, dostawcę, próby i błędy oraz może zostać bezpiecznie ponowiony.
- Operator może wykonywać codzienne działania moderacyjne i operacyjne bez bezpośredniej ingerencji w bazę danych.
- Płatna promocja i dokumenty mają spójne statusy widoczne w kanałach użytkownika i operacji.
- Nowe moduły mogą być dodawane bez kopiowania logiki domenowej do kilku niezależnych klientów.
Wiele klientów, jeden stan domenowy
Mobile, web i panel administracyjny mają inne interakcje, ale muszą korzystać z tych samych reguł uprawnień, walidacji i statusów.
Łączność mobilna
Krytyczne operacje muszą jasno komunikować stan sieci, unikać przypadkowych duplikatów i bezpiecznie wracać do przerwanego procesu.
Procesy asynchroniczne
Generowanie AI, powiadomienia i operacje integracyjne nie mogą blokować interfejsu ani znikać bez historii statusu i błędu.
Kontrola jakości AI
System musi rozpoznawać domenę produktu, ograniczać błędne fallbacki i pozostawiać możliwość retry, odrzucenia oraz ręcznej oceny.
Rozwój bez zatrzymywania produktu
Nowe funkcje, migracje danych i zmiany modeli muszą być wdrażane iteracyjnie w działającym systemie produkcyjnym.
Treść wielojęzyczna
Interfejs, ogłoszenia, komunikaty operacyjne i treści wspierające muszą pozostać semantycznie spójne w języku polskim i angielskim.
Analiza i decyzje produktowe
- Rozdzielenie SELL i BUY jako odrębnych intencji użytkownika, a nie jednego formularza z dodatkowym polem.
- Zdefiniowanie cyklu życia ogłoszenia, promocji, płatności, dokumentu i procesu moderacyjnego.
- Określenie, które reguły należą do backendu, a które są wyłącznie prezentacją w mobile lub web.
- Zaprojektowanie narzędzi operacyjnych przed skalowaniem liczby procesów AI i zgłoszeń moderacyjnych.
- Wydzielenie operacji synchronicznych od zadań, które wymagają kolejki, retry, historii prób i kontroli idempotencji.
- Przyjęcie zasady, że AI wspiera publikację, ale nie zastępuje modelu domenowego ani odpowiedzialności użytkownika i operatora.
Architektura rozwiązania
KILOGRAM wykorzystuje architekturę warstwową: osobne doświadczenia użytkownika korzystają z centralnego API, a procesy wymagające odporności są obsługiwane poza cyklem żądanie–odpowiedź. Dzięki temu reguły marketplace, płatności, moderacji i AI nie są kopiowane do kilku klientów.
- 01Warstwa doświadczenia
Aplikacja mobilna i platforma webowa
Dedykowane interfejsy dla szybkich działań mobilnych, powiadomień, odkrywania ofert, publikacji i indeksowalnych stron webowych.
React NativeExpoReactNext.jsTypeScript - 02Operacje
Panel administracyjny
Centrum zarządzania użytkownikami, ogłoszeniami, raportami, moderacją, konfiguracją, płatnościami i procesami AI.
ReactTypeScriptRole-based access - 03Domena i API
Centralny backend
Autoryzacja, reguły SELL/BUY, walidacja, statusy, płatności, dokumenty, powiadomienia, społeczność i integracje.
NestJSTypeScriptREST API - 04Dane
Model transakcyjny
Relacyjny model użytkowników, ogłoszeń, promocji, płatności, dokumentów, dyskusji, raportów i historii stanów.
PostgreSQLPrisma - 05Asynchroniczność
Kolejki i workery
Kontrolowane wykonanie generowania AI, powiadomień, tłumaczeń, moderacji i innych zadań wymagających retry oraz obserwowalności.
RedisBullMQBackground workers - 06Dostarczenie
Infrastruktura i edge
Rozdzielone środowiska dla frontendu i usług backendowych, ochrona ruchu, cache, health checks i monitoring produkcyjny.
VercelRenderCloudflare
Problemy, decyzje i wdrożone możliwości
Sprzedaż i zapotrzebowanie zakupowe wymagają innych danych i komunikatów.
Rozdzielić SELL i BUY na poziomie modelu domenowego i interfejsu.
Dedykowane ścieżki publikacji, walidacji, prezentacji i filtrowania.
Użytkownik od początku komunikuje właściwą intencję, a system może rozwijać reguły obu rynków niezależnie.
Aplikacja mobilna i web mogłyby rozjechać się pod względem statusów i uprawnień.
Umieścić reguły biznesowe w centralnym API zamiast powielać je w klientach.
Wspólna autoryzacja, walidacja, cykl życia ogłoszenia i model danych.
Każdy kanał może rozwijać własny UX bez zmiany znaczenia operacji domenowych.
Przygotowanie opisu i grafiki zwiększa próg wejścia dla publikacji.
Dodać AI jako kontrolowaną warstwę wspierającą, a nie autonomicznego wydawcę.
Generowanie opisów i obrazów z danymi domenowymi, wersją promptu, historią prób, retry i kontrolą operatora.
Użytkownik otrzymuje pomoc w przygotowaniu treści, a platforma zachowuje możliwość audytu i odrzucenia błędnego wyniku.
Codzienne operacje nie mogą wymagać ręcznej ingerencji developera.
Zaprojektować panel jako narzędzie operacyjne, a nie wyłącznie podgląd danych.
Moderacja, raporty, statusy, konfiguracja, kontrola AI, kolejki, błędy i retry.
Operator może samodzielnie obsługiwać większość powtarzalnych sytuacji i szybciej diagnozować wyjątki.
Monetyzacja ogłoszeń dotyka płatności, widoczności, dokumentów i komunikacji.
Traktować promocję jako pełny proces domenowy z własnymi statusami.
Płatne wyróżnienia, synchronizacja statusu, dokumenty i prezentacja promocji w mobile, web i panelu.
Model przychodowy może rozwijać się bez niespójności pomiędzy płatnością a faktyczną widocznością ogłoszenia.
Usuwanie treści może niszczyć relacje potrzebne do audytu i obsługi zgłoszeń.
Wykorzystać statusy moderacyjne i soft delete tam, gdzie zachowanie kontekstu jest istotne.
Ograniczenie widoczności przy zachowaniu historii, relacji i kontekstu dyskusji.
Zespół operacyjny może wyjaśniać zdarzenia bez odtwarzania utraconych danych.
Decyzje technologiczne
| Technologia | Rola | Uzasadnienie | Konsekwencja wyboru |
|---|---|---|---|
| TypeScript | Wspólny język dla mobile, web, backendu i narzędzi operacyjnych. | Zmniejsza rozjazd kontraktów, ułatwia ponowne wykorzystanie typów i wspiera kontrolowane refaktoryzacje w rozwijanym produkcie. | Wymaga utrzymania dyscypliny typów i wyraźnych granic między kodem serwerowym a klienckim. |
| React Native + Expo | Dedykowana aplikacja mobilna dla iOS i Android. | Pozwala rozwijać jeden produkt mobilny z dostępem do powiadomień, biometrii i natywnych mechanizmów dystrybucji. | Funkcje zależne od systemu operacyjnego nadal wymagają testów i konfiguracji osobno dla obu platform. |
| Next.js / React | Platforma webowa i indeksowalne doświadczenie przeglądarkowe. | Łączy szybki interfejs aplikacyjny z SSR/SSG, metadanymi i adresami przydatnymi dla odkrywania treści, SEO i widoczności w systemach AI. | Wymaga świadomego zarządzania granicą danych, bundle oraz zgodnością hydracji. |
| NestJS | Centralne API i moduły domenowe. | Modułowa struktura wspiera wyraźne odpowiedzialności dla ogłoszeń, użytkowników, płatności, dokumentów, moderacji i AI. | Rozbudowany system wymaga pilnowania granic modułów i unikania ukrytych zależności między usługami. |
| PostgreSQL + Prisma | Transakcyjny model danych i migracje schematu. | Relacje między użytkownikami, ogłoszeniami, promocjami, płatnościami, dokumentami i dyskusjami wymagają spójności oraz kontroli migracji. | Zmiany modelu w działającym produkcie wymagają planowania kompatybilności i bezpiecznych migracji danych. |
| Redis + BullMQ | Kolejki, retry i procesy asynchroniczne. | Oddziela kosztowne lub podatne na błędy zadania od requestów użytkownika i umożliwia kontrolę prób oraz statusów. | Wprowadza dodatkowy stan operacyjny, który musi być monitorowany, idempotentny i możliwy do naprawy. |
Integracje i przepływy danych
Dostawca płatności
dwukierunkowaAutoryzacja płatnych wyróżnień i utrzymanie spójności pomiędzy transakcją, statusem promocji oraz dokumentem.
Backend waliduje statusy, zapisuje wynik procesu i obsługuje sytuacje, w których użytkownik wraca z płatności w nieoczekiwanym stanie.
Usługi powiadomień
wychodzącaInformowanie użytkowników o zmianach statusu, aktywności i zdarzeniach wymagających reakcji.
Zdarzenia są oddzielone od interfejsu użytkownika, dzięki czemu błąd dostarczenia nie musi blokować głównej operacji.
OpenAI API i warstwa modeli
request / resultWspieranie generowania opisów i grafik na podstawie uporządkowanych danych ogłoszenia.
Wywołania są wersjonowane, kolejkowane i zapisywane jako próby; błędny wynik może zostać odrzucony lub ponowiony.
Zewnętrzne kanały publikacji
wychodzącaRozszerzanie dystrybucji wybranych ofert i treści poza własne kanały platformy.
Publikacja jest traktowana jako osobny proces ze statusem i obsługą błędów, a nie jako niekontrolowany efekt uboczny zapisu ogłoszenia.
Cloudflare / warstwa edge
ruch przychodzącyOchrona ruchu, kontrola DNS, cache i stabilne kierowanie użytkowników do warstw web oraz API.
Konfiguracja edge jest oddzielona od kodu produktu i podlega własnym regułom cache, domen oraz crawlerów.
AI, bezpieczeństwo i niezawodność
Warstwa AI jest procesem domenowym z wejściem, stanem, walidacją i kontrolą operacyjną. Model nie otrzymuje dowolnego polecenia użytkownika i nie publikuje wyniku bezpośrednio. Dane ogłoszenia są przekształcane w wersjonowany prompt, a każda próba pozostawia ślad umożliwiający diagnozę, retry lub odrzucenie.
Przepływ AI
- Pobranie uporządkowanych danych produktu, typu ogłoszenia, kategorii, lokalizacji i parametrów publikacji.
- Rozpoznanie domeny i archetypu produktu oraz wybór właściwej wersji promptu.
- Utworzenie zadania w kolejce z identyfikatorem, modelem, dostawcą i wersją konfiguracji.
- Wykonanie generacji poza głównym requestem użytkownika.
- Walidacja rezultatu pod kątem wymaganych pól i zgodności domenowej.
- Zapis wyniku, błędu i historii prób oraz udostępnienie retry lub odrzucenia operatorowi.
Kontrole
- Wersjonowanie promptów, dostawcy i modelu użytego w konkretnej próbie.
- Reguły domenowe blokujące niezgodne archetypy oraz nieprawidłowe scenariusze zastępcze.
- Kolejki, retry, statusy i kontrola idempotencji dla zadań podatnych na awarie.
- Panelowa historia prób i błędów umożliwiająca analizę bez bezpośredniego dostępu do produkcyjnej bazy.
- Możliwość ręcznego odrzucenia wyniku i zachowania poprzedniej wersji treści.
- Rozdzielenie AI description, AI images i procesów moderacyjnych na osobne odpowiedzialności.
Ograniczenia
- AI wspiera użytkownika, ale nie zastępuje walidacji danych ani odpowiedzialności za finalną publikację.
- Jakość wyniku zależy od kompletności i poprawności danych wejściowych ogłoszenia.
- Nowe domeny i nietypowe produkty wymagają testów archetypów oraz aktualizacji reguł przed produkcyjnym użyciem.
- Opis projektu nie przypisuje AI wpływu na konwersję ani czas publikacji bez zatwierdzonego pomiaru analitycznego.
- Mechanizmy kontrolne ograniczają błędy, ale nie oznaczają, że model generatywny jest deterministyczny.
Uwierzytelnianie i sesje
Dostęp użytkownika jest chroniony przepływem OTP, zarządzaniem sesją i mechanizmami aplikacji mobilnej, w tym biometrią tam, gdzie jest dostępna.
Uprawnienia operacyjne
Role i uprawnienia ograniczają dostęp do moderacji, administracji, konfiguracji oraz działań wpływających na stan innych użytkowników.
Historia i soft delete
Usuwanie treści może ograniczyć widoczność bez niszczenia relacji potrzebnych do audytu, zgłoszeń i zachowania kontekstu.
Odporne zadania asynchroniczne
Statusy, retry i historia prób pozwalają odróżnić zadanie oczekujące, zakończone, odrzucone i wymagające interwencji.
Health checks i monitoring
Warstwy produkcyjne są obserwowane przez health checks, logi usług i alerty potrzebne do diagnozy błędów infrastruktury oraz integracji.
Komunikacja błędów sieciowych
Interfejs odróżnia problem połączenia od błędu domenowego, aby użytkownik wiedział, czy powinien ponowić operację, poprawić dane czy zaczekać.
Realizacja, testy i uruchomienie
- 1Faza 1 — Discovery i model domenowy
Zdefiniować aktorów, intencje SELL/BUY, cykl życia ogłoszenia i granice odpowiedzialności systemu.
- Mapa ról i kluczowych ścieżek
- Model stanów ogłoszenia i moderacji
- Zakres MVP oraz kolejność modułów
- Kontrakty pomiędzy klientami i API
Rezultat: Jedna definicja produktu, na której mogły równolegle powstawać mobile, web, backend i panel administracyjny.
- 2Faza 2 — Fundamenty platformy
Uruchomić bezpieczny dostęp, centralne dane i podstawowe przepływy publikacji oraz odkrywania ofert.
- Autoryzacja i profile
- Aplikacja React Native
- Platforma webowa
- API NestJS i PostgreSQL
- Wyszukiwanie, filtry, ulubione i listing details
Rezultat: Działający wielokanałowy marketplace korzystający z jednego modelu danych i reguł domenowych.
- 3Faza 3 — Operacje i monetyzacja
Dać operatorom narzędzia do zarządzania platformą i wdrożyć procesy tworzące przychód.
- Panel administracyjny
- Moderacja i raporty
- Płatne wyróżnienia
- Dokumenty i statusy płatności
- Powiadomienia i funkcje społecznościowe
Rezultat: Codzienne operacje i podstawowa monetyzacja zostały włączone do tego samego kontrolowanego procesu produktowego.
- 4Faza 4 — Produkcyjne AI
Zmniejszyć tarcie publikacji bez utraty kontroli nad jakością i stanem generacji.
- AI descriptions i AI images
- Archetypy oraz prompty domenowe
- Kolejki i retry
- Historia prób i wersji
- Kontrole panelowe i obsługa niezgodności
Rezultat: AI stało się obserwowalnym modułem systemu, a nie niekontrolowanym wywołaniem z interfejsu użytkownika.
- 5Faza 5 — Stabilizacja i ewolucja
Utrzymywać jakość produkcyjną podczas rozwijania kolejnych modułów, integracji i wariantów domenowych.
- Monitoring i health checks
- Regresje dla krytycznych przepływów
- Optymalizacje web i mobile
- Rozwój moderacji i trust & safety
- Widoczność w wyszukiwarkach i systemach AI, lokalizacja oraz nowe kanały
Rezultat: Platforma może być rozwijana iteracyjnie bez zastępowania fundamentów przy każdej nowej funkcji.
Kontrola typów i buildów
Mobile, web i API przechodzą walidację TypeScript oraz produkcyjne buildy przed wdrożeniem zmian dotykających wspólnych kontraktów.
Regresje przepływów krytycznych
Ścieżki SELL, BUY, AI, płatności, dokumentów i moderacji są testowane pod kątem zmian, które mogą przerwać stan istniejących użytkowników lub danych.
Testy błędów i retry
Procesy asynchroniczne są sprawdzane również dla timeoutów, nieprawidłowych odpowiedzi, powtórnych prób i stanów wymagających interwencji operatora.
QA wielokanałowe
Zmiany reguł domenowych są weryfikowane w aplikacji mobilnej, webie i panelu, ponieważ błąd może ujawnić się w innym kanale niż miejsce implementacji.
Obserwowalny rollout
Po wdrożeniu zespół wykorzystuje logi, health checks i statusy zadań do wykrywania problemów integracyjnych i regresji produkcyjnych.
Migracje kompatybilne z produkcją
Zmiany bazy i modeli są planowane tak, aby działające klienty nie otrzymały niekompatybilnego kontraktu w trakcie wdrożenia.
Co potwierdza opis projektu
Opis obejmuje wyłącznie funkcje, relacje i decyzje możliwe do potwierdzenia w działającym produkcie, dokumentacji systemu, interfejsach lub procesach operacyjnych. Dane o wzroście zostaną dodane dopiero wtedy, gdy będzie można wskazać punkt odniesienia, okres pomiaru, źródło oraz właściciela danych.
| Zakres | Podstawa | Materiał | Potwierdzenie | Granice wniosku |
|---|---|---|---|---|
| KILOGRAM działa jako system obejmujący aplikację mobilną, platformę webową, centralne API i panel administracyjny. | Zakres wdrożonego produktu | KG-01 · Architektura i moduły produkcyjne KILOGRAM | Potwierdzone w produkcie | Stwierdzenie opisuje zakres funkcjonalny, nie liczbę aktywnych użytkowników. |
| Marketplace rozdziela ogłoszenia SELL i BUY jako odrębne przepływy domenowe. | Model domenowy | KG-02 · Formularze, walidacja, statusy i prezentacja ogłoszeń | Potwierdzone w produkcie | Dowód nie określa udziału każdego typu ogłoszenia w rynku. |
| Warstwa AI wspiera generowanie opisów i grafik ogłoszeń oraz zapisuje historię prób. | Funkcja produktu | KG-03 · Moduły AI Description, AI Images, kolejki i panel operacyjny | Potwierdzone w produkcie | Nie publikuje się wpływu na czas lub konwersję bez zatwierdzonego pomiaru. |
| Zadania AI i inne procesy asynchroniczne korzystają z Redis i BullMQ oraz mechanizmów retry. | Architektura rozwiązania | KG-03 · Konfiguracja kolejek, workerów i statusów zadań | Potwierdzone w produkcie | Opis projektu nie publikuje wolumenu zadań ani wskaźnika błędów. |
| Platforma obsługuje płatne promowanie ogłoszeń i powiązane dokumenty. | Proces biznesowy | KG-04 · Moduły promocji, płatności, statusów i dokumentów | Potwierdzone w produkcie | Nie publikuje się przychodu ani konwersji promocji bez danych finansowych. |
| Panel administracyjny umożliwia moderację, kontrolę AI, analizę błędów i ponawianie wybranych procesów. | Narzędzia operatora | KG-04 · Widoki administracyjne i endpointy operacyjne | Potwierdzone w produkcie | Zakres uprawnień zależy od roli operatora. |
| System wykorzystuje soft delete i statusy moderacyjne do zachowania kontekstu wybranych relacji. | Model danych i moderacja | KG-04 · Relacje ogłoszeń, dyskusji, raportów i stanów widoczności | Potwierdzone w produkcie | Polityka retencji zależy od rodzaju danych i nie jest opisywana jako uniwersalna dla każdego rekordu. |
| KILOGRAM posiada polską i angielską warstwę językową dla rozwijanych kanałów produktu. | Lokalizacja produktu | KG-01 · Zasoby i18n aplikacji, webu i treści systemowych | Potwierdzone w produkcie | Nie oznacza to automatycznie uruchomienia operacyjnego na każdym rynku anglojęzycznym. |
Jak czytać te informacje
- Potwierdzenie funkcji oznacza, że działa ona w produkcie; nie oznacza automatycznie wpływu na przychód, konwersję lub retencję.
- Nie publikujemy liczby użytkowników, ogłoszeń, transakcji ani przychodu bez zatwierdzonego źródła analitycznego lub finansowego.
- Rezultaty jakościowe opisują zmianę procesu i dostępne narzędzia, a nie statystyczną zależność przyczynową.
- Po połączeniu danych z GSC, GA4 i analityki produktowej materiał może zostać rozszerzony o porównania wartości przed i po wdrożeniu.
- Każda przyszła metryka musi wskazywać źródło, okres, datę aktualizacji i granice interpretacji.
Zmiana procesu, konsekwencje decyzji i wnioski
| Obszar | Przed wdrożeniem | Po wdrożeniu | Wpływ biznesowy |
|---|---|---|---|
| Struktura rynku | Oferty i zapotrzebowanie były rozproszone pomiędzy kanałami bez wspólnego modelu danych. | SELL i BUY funkcjonują w jednym marketplace, ale zachowują odrębne reguły publikacji i filtrowania. | Platforma może porządkować obie strony rynku i rozwijać dla nich oddzielne mechanizmy discovery. |
| Kanały produktu | Użytkownicy korzystali z wielu niespójnych narzędzi i sposobów komunikacji. | Aplikacja mobilna i web korzystają ze wspólnego API, profilu, danych i stanów ogłoszenia. | Nowy kanał może być rozwijany bez budowania osobnego systemu operacyjnego. |
| Przygotowanie treści | Opis i grafika zależały wyłącznie od czasu, wiedzy i materiałów użytkownika. | AI wspiera przygotowanie treści w kontrolowanym procesie z historią prób i możliwością odrzucenia. | Platforma redukuje tarcie tworzenia ogłoszenia bez rezygnowania z kontroli jakości. |
| Operacje | Wyjątki i problemy wymagałyby częstego udziału zespołu technicznego lub ręcznej analizy danych. | Panel pokazuje statusy, raporty, próby, błędy i akcje naprawcze dostępne dla uprawnionych operatorów. | Codzienna obsługa jest mniej zależna od developera, a wyjątki mają czytelniejszy ślad diagnostyczny. |
| Monetyzacja | Promowanie oferty mogłoby być jedynie wizualnym oznaczeniem bez kompletnego procesu płatności i dokumentu. | Promocja ma własny cykl życia powiązany z płatnością, widocznością, statusem i dokumentacją. | Platforma posiada fundament do rozwijania kontrolowanych produktów płatnych i raportowania ich stanu. |
| Odporność procesów | Kosztowne operacje wykonywane synchronicznie mogłyby blokować użytkownika i tracić stan po błędzie. | Zadania wymagające odporności korzystają z kolejek, statusów, retry i historii prób. | Błędy mogą być diagnozowane i naprawiane bez ponownego wykonywania całego procesu użytkownika. |
Osobne aplikacje mobile i web ze wspólnym API
- Alternatywa
- Jedna uniwersalna aplikacja webowa używana we wszystkich kontekstach.
- Konsekwencja
- Dwa interfejsy wymagają osobnego QA i koordynacji wersji.
- Uzasadnienie
- Mobile potrzebuje powiadomień, biometrii i szybkich akcji, a web indeksowalności, wygody desktopowej i publicznego discovery.
Kolejki dla AI i integracji
- Alternatywa
- Wykonywanie generacji bezpośrednio w żądaniu użytkownika.
- Konsekwencja
- Kolejki dodają własny stan, monitoring i scenariusze retry.
- Uzasadnienie
- Proces użytkownika pozostaje responsywny, a awaria dostawcy nie usuwa historii zadania i nie wymusza ponownego wpisywania danych.
AI assistance zamiast automatycznego publikowania
- Alternatywa
- Pełna automatyzacja treści bez etapu kontroli.
- Konsekwencja
- Użytkownik lub operator nadal wykonuje decyzję końcową.
- Uzasadnienie
- Dane handlowe i wizerunek produktu wymagają kontroli, a modele generatywne nie są deterministyczne.
Soft delete dla kontekstowych danych
- Alternatywa
- Natychmiastowe trwałe usunięcie każdego rekordu.
- Konsekwencja
- Model danych i zapytania muszą konsekwentnie uwzględniać stan widoczności.
- Uzasadnienie
- Moderacja, zgłoszenia i dyskusje wymagają zachowania relacji potrzebnych do audytu i wyjaśnienia zdarzeń.
Modułowa ewolucja działającego produktu
- Alternatywa
- Jednorazowe wdrożenie pełnej, zamkniętej specyfikacji.
- Konsekwencja
- Architektura, migracje i testy muszą uwzględniać ciągłe zmiany.
- Uzasadnienie
- Marketplace rozwija się wraz z danymi użytkowników, operacjami, monetyzacją i nowymi przypadkami domenowymi.
Najważniejsze lekcje
- W marketplace B2B rozróżnienie intencji SELL i BUY powinno istnieć w domenie, nie tylko w etykiecie interfejsu.
- Panel administracyjny należy projektować równolegle z produktem użytkownika, ponieważ brak narzędzi operacyjnych szybko staje się ograniczeniem skali.
- AI produkcyjne wymaga wersjonowania, statusów, historii prób i ścieżki ręcznej; sam prompt nie jest architekturą produktu.
- Płatność za widoczność ogłoszenia jest procesem obejmującym transakcję, uprawnienie do promocji, dokument i komunikację, a nie pojedynczym przyciskiem.
- Wielokanałowy produkt potrzebuje centralnej semantyki statusów, ponieważ ten sam rekord jest prezentowany inaczej w aplikacji mobilnej, platformie webowej i panelu administracyjnym.
- Najpierw należy mierzyć jakość źródeł danych, a dopiero później publikować wyniki w materiałach marketingowych i eksperckich.
Dla jakich organizacji ten model jest istotny
Marketplace’y B2B z dwiema stronami rynku
Organizacje, które muszą osobno modelować podaż i zapotrzebowanie, ale utrzymać je w jednym systemie discovery, komunikacji i operacji.
Platformy branżowe z aplikacją mobilną
Produkty wymagające szybkiego mobile UX, publicznego web discovery, wspólnego profilu i centralnych reguł domenowych.
Produkty monetyzujące widoczność lub priorytet
Systemy, w których płatna promocja musi być spójna z płatnością, dokumentem, entitlement i faktyczną ekspozycją treści.
Organizacje wdrażające kontrolowane AI
Zespoły, które chcą generować treść lub media, ale potrzebują domenowych ograniczeń, retry, audytu i panelowej kontroli jakości.
Platformy wymagające moderacji i trust & safety
Produkty społecznościowe i marketplace’y, w których raporty, statusy, soft delete i historia zdarzeń są częścią operacji.
Firmy rozwijające jeden produkt na wiele kanałów
Organizacje potrzebujące osobnych klientów mobile i web bez kopiowania logiki biznesowej oraz procesów integracyjnych.
Powiązana wiedza i usługi
Tworzenie aplikacji mobilnych
Projektowanie i rozwój produkcyjnych aplikacji React Native połączonych z centralnym backendem oraz procesami operacyjnymi.
Tworzenie aplikacji webowych
Systemy webowe łączące interfejs użytkownika, API, role, dane, płatności, integracje i narzędzia administracyjne.
Automatyzacje i systemy AI
Kontrolowane procesy AI z kolejkami, monitoringiem, scenariuszami zastępczymi, walidacją i możliwością interwencji człowieka.
Rozwój platform marketplace i eCommerce
Architektura transakcji, katalogów, discovery, płatności, promocji, dokumentów i operacji komercyjnych.
React Native
Technologia aplikacji mobilnych współdzielących domenę i API z platformą webową.
Node.js i NestJS
Modułowe API, procesy asynchroniczne, integracje i logika systemów biznesowych.
Foodeli — logistyka ostatniej mili
Powiązany przykład wieloról, aplikacji mobilnych i operacyjnej platformy obsługującej rynek dwustronny.
Jak zbudowaliśmy ekosystem KILOGRAM
Artykuł uzupełniający opis projektu o narrację dotyczącą rozwoju produktu i poszczególnych etapów wdrożenia.
Planujesz platformę, która łączy wiele kanałów i procesów operacyjnych?
Porozmawiajmy o modelu domenowym, architekturze, mobile, webie, monetyzacji, panelu operacyjnym i kontrolowanej warstwie AI — zanim kosztowne decyzje zostaną zapisane w kodzie.
Najważniejsze potwierdzone fakty
Poniższe informacje podsumowują potwierdzony zakres produktu i nie zawierają niezatwierdzonych danych o wzroście.
- 1
Softech zaprojektował i rozwija KILOGRAM jako produkcyjną platformę marketplace dla handlu rolnego.
- 2
KILOGRAM łączy aplikację mobilną, platformę webową, centralny backend API i panel administracyjny.
- 3
Platforma KILOGRAM rozdziela ogłoszenia SELL i BUY jako odrębne przepływy domenowe.
- 4
Aplikacja mobilna i platforma webowa KILOGRAM korzystają z tego samego modelu danych i centralnych reguł API.
- 5
KILOGRAM obsługuje płatne promowanie ogłoszeń oraz powiązane statusy płatności i dokumenty.
- 6
Warstwa AI w KILOGRAM wspiera tworzenie opisów i grafik ogłoszeń na podstawie uporządkowanych danych produktu.
- 7
Procesy AI w KILOGRAM zapisują wersję promptu, dostawcę, model, status i historię prób.
- 8
KILOGRAM wykorzystuje Redis i BullMQ do obsługi zadań wymagających kolejek, retry i obserwowalności.
- 9
Panel administracyjny KILOGRAM umożliwia moderację, kontrolę statusów, analizę błędów i obsługę wybranych procesów AI.
- 10
System KILOGRAM wykorzystuje PostgreSQL i Prisma do przechowywania relacyjnych danych użytkowników, ogłoszeń, promocji, dokumentów i procesów operacyjnych.
- 11
KILOGRAM posiada polską i angielską warstwę językową dla rozwijanych kanałów produktu.
- 12
Softech odpowiada w KILOGRAM za strategię produktu, UX/UI, mobile, web, backend, AI, infrastrukturę i dalszy rozwój systemu.
- 13
Opis projektu KILOGRAM nie publikuje niezatwierdzonych danych o liczbie użytkowników, przychodzie ani konwersji.
- 14
KILOGRAM jest rozwijany iteracyjnie jako działający system produkcyjny, a nie jednorazowy prototyp.
Materiały wizualne
Diagramy przedstawiają potwierdzony zakres produktu i przepływy opisane w materiale. Nie są makietami ani deklaracją nieudokumentowanych wyników.
FAQ
Dlaczego KILOGRAM potrzebuje zarówno aplikacji mobilnej, jak i platformy webowej?
Mobile wspiera częste, szybkie działania i powiadomienia, natomiast web zwiększa dostępność, umożliwia indeksowanie ofert i zapewnia wygodną obsługę na komputerze. Obie warstwy korzystają z tego samego API i modelu danych.
Jak platforma rozróżnia ogłoszenia sprzedaży i zakupu?
SELL i BUY są osobnymi przepływami domenowymi z własnymi komunikatami, walidacją i prezentacją. Dzięki temu użytkownik od początku określa, czy oferuje produkt, czy zgłasza zapotrzebowanie.
W jaki sposób AI jest używane w KILOGRAM?
AI wspiera przygotowanie opisów i grafik ogłoszeń. System wykorzystuje dane produktu, reguły domenowe, wersjonowane prompty, historię prób, kolejki, retry i panelową kontrolę jakości.
Jak operator kontroluje błędne generacje AI?
Panel administracyjny pokazuje status, model, dostawcę, wersję promptu, historię prób i błędy. Operator może ponowić zadanie, odrzucić wynik lub przeanalizować niezgodność domenową.
Czy system obsługuje płatne promowanie ogłoszeń?
Tak. Monetyzacja obejmuje płatne wyróżnienia i statusy promocji, które muszą być spójnie obsługiwane przez backend, aplikację mobilną, web, dokumenty i panel administracyjny.
Jak rozwiązano moderację i usuwanie treści?
System łączy statusy moderacyjne, raporty i soft delete. Pozwala to ograniczać lub usuwać widoczność treści bez niszczenia relacji potrzebnych do audytu i zachowania kontekstu dyskusji.
Czy architektura pozwala rozwijać platformę na kolejne rynki?
Warstwa lokalizacji, centralny model domenowy, osobne klienty mobile i web oraz modułowa infrastruktura tworzą podstawę do dodawania kolejnych języków, integracji i modeli monetyzacji.
