EWWE solutions
№ 02 · Studia przypadku · AD MMXXVI
Wdrożenie na zamówienie · dwa produkty

ARCHITEKTURA, — przypadek po przypadku.

Trzy realizacje, jedna pracownia. Otwiera je komercyjne wdrożenie na zamówienie — strona firmowa, konfigurator serwerów i autorski CRM z integracją KSeF dla dystrybutora IT. Dalej dwa własne produkty AI — w różnych stadiach: Fiszkomat do fiszek dla studentki medycyny i Ofertomat do analizy zamówień publicznych. Poniżej: stack, decyzje warte odnotowania i kierunek, w którym zmierza każda z nich.

Napisane dla inżynierów i menedżerów inżynierii oceniających naszą pracę — czytelne także dla nietechnicznego czytelnika, ale bez spłycania technicznych decyzji. Każda sekcja to mniej więcej dwie minuty czytania.

01

CRM.

Strona firmowa + konfigurator serwerów + CRM z KSeF — wdrożenie na zamówienie

▢ Płatne · wdrożenie

Problem

Dystrybutor sprzętu serwerowego prowadził sprzedaż na arkuszu kalkulacyjnym i statycznym cenniku PDF. Leady ginęły między skrzynką e‑mail a Excelem, a klient pytający o konfigurację serwera dostawał cennik zamiast rozmowy ofertowej. Potrzebne było jedno spójne narzędzie: nowa strona, która zamienia zapytanie w leada, oraz system, który ten lead prowadzi od pierwszego kontaktu po fakturę — bez wdrażania ciężkiego, generycznego CRM‑a, którego nikt w firmie by nie obsłużył.

Architektura

  • Strona + konfiguratorNowa strona firmowa i interaktywny konfigurator serwerów (Dell / Fujitsu), który prowadzi do zapytania ofertowego zamiast cennika. Każdy formularz → /api/lead → CRM. To jest szew integracji, nie e‑mail.
  • CRMFastAPI + HTMX, renderowanie po stronie serwera, bez kroku budowania frontu. Pipeline, statusy, ranking sprzedaży, w pełni konfigurowalne pola. SQLite jako magazyn — adekwatny do skali jednej firmy, zero administracji bazą.
  • E‑mail dwukierunkowoKorespondencja synchronizowana z kartą kontaktu w obie strony — przychodzący e‑mail dopinany do właściwej firmy, cały wątek widoczny przy leadzie. Zastępuje ręczne przeklejanie z Outlooka.
  • KSeFCRM wystawia faktury w schemacie FA(3), wysyła je do Krajowego Systemu e‑Faktur, odbiera UPO i pobiera faktury zakupowe — zgodnie z oficjalnym API Ministerstwa Finansów (mandatoryjnym od 02.2026). Ścieżka pod regulatora w pełni deterministyczna — model nie dotyka tego, co widzi urząd.
  • OpsUsługa systemd, szablony czytane na żywo; zmiany w kodzie wymagają restartu (bez --reload). Pakiet ~250 testów na zielono.

Decyzje warte odnotowania

  1. Autorski CRM zamiast wdrożenia gotowca. Klient nie potrzebował Salesforce‑a — potrzebował zastąpić arkusz. Bespoke pod jeden konkretny proces sprzedaży kosztuje mniej w starcie i nie zmusza zespołu do uczenia się obcego narzędzia. Model komercyjny: niski koszt wejścia plus abonament, z pełnym przeniesieniem praw autorskich do klienta.
  2. E‑mail jako pierwszorzędny obywatel, nie integracja na doczepkę. Sprzedaż w tej firmie dzieje się w skrzynce. Dwukierunkowy sync e‑mail ↔ karta firmy to nie pozycja na liście funkcji — to oś produktu; bez niego CRM byłby drugim miejscem do ręcznego przepisywania.
  3. KSeF: AI nie dotyka tego, co widzi urząd. Podział granic na całej ścieżce regulacyjnej — emisja FA(3), wysyłka i odbiór UPO to deterministyczny kod pod oficjalne API MF. Zero modelu na ścieżce regulacyjnej.

Status

Pierwsze płatne wdrożenie build‑for‑hire pracowni. Strona, konfigurator i CRM zbudowane; warstwa KSeF (FA(3) + UPO + faktury zakupowe) dopięta. Na życzenie klienta nie publikujemy nazwy ani adresu wdrożenia; demo udostępniamy na zapytanie.

02

FISZKOMAT.

Farmakologia PDF → Anki — narzędzie zbudowane dla jednej studentki medycyny

▢ Live

Problem

Studenci trzeciego roku medycyny muszą wykuć mniej więcej dwa tysiące leków × mechanizmów × wskazań × działań niepożądanych na jedno kolokwium z farmakologii. Anki to dominujące narzędzie, ale przygotowanie kart zjada godziny, które powinny iść w powtórki. Istniejące generatory AI produkują zbyt wiele kart o słabej atomowości (jedna karta pyta o dwie rzeczy) i wymagają importu w desktopowym Anki.

Architektura

  • Generowanie kartAPI Anthropic (Sonnet w pierwszym przebiegu, Haiku do przeformułowań). Wyjście zablokowane schematem JSON, atomowość wymuszona w prompcie (jedno pytanie, jeden mechanizm albo jedno wskazanie), liczba kart limitowana per wykład heurystykami częstości egzaminacyjnej z sylabusa użytkownika.
  • ReviewerPowtórki SM‑2 w przeglądarce (czysty JS, deterministyczne). Zero LLM w codziennej ścieżce użycia. Mobile‑first, bez instalacji.
  • BackendFastAPI + integracja płatności Stripe, bramka deweloperska na darmowe tokeny, potwierdzenia Postmark.
  • Opsusługa systemd czytająca pliki źródłowe wprost, więc aktualizacje treści nie wymagają restartu.

Decyzje warte odnotowania

  1. Spec odkryty przez użycie, nie przez projekt. v0 było „jedna karta na punkt slajdu” — produkowało 200 kart/wykład i zostało porzucone przez pierwszą prawdziwą testerkę (studentkę medycyny przygotowującą się do realnego kolokwium). v0.5 limituje karty do ≈30, wymusza atomowość i dostarcza własny reviewer. Spec wyłonił się dopiero z zaobserwowanego zachowania w nauce, nie z wywiadów.
  2. SM‑2, nie interwały oceniane przez AI. Deterministyczny algorytm odpowiada oczekiwaniom użytkowników Anki i usuwa probabilistyczny tryb awarii z codziennej ścieżki użycia.

Status

Działa na fiszkomat.ewwesolutions.work. Osiem ręcznie dopracowanych przykładowych talii (ponad 1 000 kart) na landingu jako wzorzec „dobrego” wyjścia, do tego reviewer SM‑2 w przeglądarce. Zbudowany dla jednej użytkowniczki — studentki medycyny (i ewentualnie jej koleżanki); talie weryfikowane na jej realnych kolokwiach z farmakologii. Nie produkt dla masowego rynku.

03

OFERTOMAT.

Analizator polskich zamówień publicznych (BZP / TED)

▢ Prototyp · w budowie

Problem

BZP (polskie zamówienia publiczne) i TED (unijne) publikują tysiące przetargów. Większość firm, które mogłyby startować, tego nie robi, bo odsianie sygnału od szumu wymaga czytania setek nieprzejrzystych dokumentów tygodniowo. „Właściwy” przetarg jest mocno kontekstowy — wielkość firmy, kody branżowe, geografia, wygrane w przeszłości — zdefiniowany w głowie operatora, nie w żadnym specu.

Architektura (prototyp)

  • PozyskiwanieBZP / TED przez oficjalne API.
  • Streszczenie przetarguClaude Sonnet nad surowym PDF‑em przetargu, ustrukturyzowane do porównywalnej formy.
  • Profil firmyRównież wyciągany przez LLM z dowolnego opisu (wygrane w przeszłości, liczba osób, technologia) — klient nie musi pisać YAML‑a.
  • Ocena dopasowaniaOgraniczone porównanie profilu ze streszczeniem przetargu, z tagami uzasadnień, żeby pokazana racjonalizacja była audytowalna.

Status

Prototyp w budowie, demo time‑slice live. Aktywnie rozwijany — pipeline BZP / TED → streszczenie → ocena dopasowania działa na realnych próbkach; dopinamy go do użytkowego kształtu.

04

Stack w skrócie.

Produkt
Status
Stack
Dostęp
01
CRM
Płatne wdrożenie na zamówienie
FastAPI + HTMX + SQLite + sync e‑mail + KSeF FA(3) / UPO
▢ Na zamówienie
02
FISZKOMAT
Live, w codziennym użyciu
FastAPI + Anthropic API + SM‑2 reviewer + Stripe
03
OFERTOMAT
Prototyp · w budowie
BZP / TED ingest + Claude Sonnet + time‑slice demo
▢ Wewn.

Dwa własne produkty dzielą ten sam stack ops (systemd + Postmark + Discord) i powstały w kilka dni; komercyjny CRM jest wdrażany u klienta z przeniesieniem praw. Powracające wzorce: dyscyplina granic (probabilistyczne wejście, deterministyczne wyjście — ta sama zasada chroni KSeF‑ową ścieżkę CRM‑a), dobór modelu po tierach wg jednostkowej ekonomii wywołania oraz feedback od prawdziwych użytkowników od pierwszego dnia — dogfooding studentki medycyny na Fiszkomacie i realny proces sprzedaży dystrybutora, który zdefiniował CRM.

§ Kontakt

Jedna skrzynka. Jedna osoba.

W sprawie wdrożenia na zamówienie (strona, konfigurator, CRM), rozmów o integracjach (KSeF, ekstrakcja faktur, łączenie z innymi systemami) albo czegokolwiek, co pasuje do powyższych wzorców — pisz wprost.