Cześć, jestem
Michał Franczak.

Full-stack TypeScript developer. Buduję produkty od bazy danych po interfejs.

O mnie

Nazywam się Michał Franczak, mam 23 lata i jestem full-stack developerem, który lubi budować produkty od pierwszego pomysłu po działający system.

Pracowałem nad aplikacjami SaaS, panelami operacyjnymi, automatyzacjami i stronami, które mają rozwiązywać konkretne problemy, a nie tylko dobrze wyglądać na makiecie. Dbam o szczegóły, czytelny interfejs i solidne fundamenty techniczne.

Szukam miejsca, w którym mogę rozwijać się jako developer, pracować z zespołem i dowozić rzeczy, z których realnie korzystają ludzie.

Projekty od strony kodu

Problem, architektura i najważniejsze decyzje techniczne.

matchcn

open source

francesco0242 / matchcn

Semantyczna wyszukiwarka komponentów dla agentów AI. Opisujesz potrzebny interfejs, a matchcn znajduje rzeczywisty, instalowalny komponent i zwraca gotową komendę. Opublikowany na npm jako serwer MCP, działa w Claude Code, Cursorze i VS Code.

Kod źródłowy

Zobacz projekt npm

4 578

zaindeksowanych komponentów

rejestrów

wymiarów klasyfikacji

1 527

pobrań z npm w 30 dni

issiofy

open source

francesco0242 / issiofy

Biblioteka animowanych komponentów React dostarczanych jako kod źródłowy. Każdy komponent to jeden plik TSX z własnym rendererem (shader WebGL albo Canvas 2D), pełnym typowaniem i instalacją jedną komendą.

Kod źródłowy

Zobacz na żywo

komponenty

≈4 000

linii TypeScript

15 / 17

plików z obsługą reduced motion

kont i kluczy do instalacji

Zrealizowane produkty

Aplikacje, które zaprojektowałem i zbudowałem: od SaaS po systemy operacyjne.

Aerivo

SaaS

aerivo.net

Zaprojektowałem i zbudowałem platformę dla pilotów lotnictwa ogólnego: planowanie lotu VFR, masa i wyważenie, pogoda i dziennik lotów w jednym miejscu.

Planowanie trasy VFR
Masa i wyważenie
METAR / TAF
NOTAM
Dziennik lotów
Checklisty

Zobacz na żywo

Problem

Piloci lotnictwa ogólnego w Europie żonglowali osobnymi narzędziami do planowania lotu, obliczania masy i wyważenia oraz prowadzenia dziennika. Żadne z nich nie powstało z myślą o tym, jak naprawdę latają: oprogramowanie dziennikowe wyglądało, jakby zaprojektowano je dla linii lotniczych, a nie dla kogoś, kto w weekend startuje cessną z trawiastego pasa.

Rozwiązanie

Zbudowałem aplikację webową, która łączy planowanie trasy, obliczenia bezpieczeństwa i dziennik na wspólnych danych. Tam, gdzie błąd mógłby wpłynąć na bezpieczeństwo lub dokumentację pilota, oparłem logikę na rzeczywistych zasadach, a nie na przybliżeniach.

Wybrane problemy techniczne

Masa i wyważenie dla różnych typów samolotów

Każdy samolot ma inną masę własną, pojemność paliwa i obwiednię środka ciężkości. Zbudowałem system, który dobiera wartości referencyjne dla danego typu i waliduje obliczenia na bieżąco, wyłapując przekroczenia zanim pilot dotrze na pas.

Parsowanie METAR

METAR to gęsty, skrótowy kod. Przebudowałem parser tak, by obsługiwał nietypowe formaty stacji, brakujące pola i niestandardowe zapisy wiatru, zamiast po cichu zawodzić, bo błędne dane pogodowe to problem bezpieczeństwa, a nie zwykły bug.

Trasa a przestrzeń powietrzna

Sprawdzam trasę względem stref (m.in. TMA i CTR) własną geometrią: przecięcia odcinków i test punktu w wielokącie, bez dodatkowych bibliotek.

Czas cross-country według przepisów

Dziennik liczy czas przelotowy inaczej niż całkowity czas lotu, według wymagań dotyczących dystansu i lądowań. Oparłem logikę na faktycznych definicjach regulacyjnych, a nie na przybliżeniach.

Eksport, który się nie psuje

Dane muszą być przenośne (ubezpieczenie, odnowienie uprawnień, zmiana narzędzia). Przebudowałem eksport do PDF i CSV tak, by radził sobie z dużymi dziennikami i nietypowymi wpisami bez rozjeżdżającego się formatowania.

Procedury dopasowane do typu samolotu

Zbudowałem interaktywne checklisty przedlotowe i karty procedur awaryjnych dobierane do konkretnego samolotu, zamiast jednego uniwersalnego zestawu dla wszystkich.

Stack techniczny

TypeScript
Next.js
React
Supabase
PostgreSQL
Leaflet
Route Handlers

March Bunny

Platforma B2B

System zamówień i operacji dla cateringu

Zaprojektowałem i zbudowałem panel dla firmy cateringowej obsługującej ponad 50 placówek (żłobki, przedszkola, szkoły): zamówienia, kuchnia, dostawy, jadłospisy i rozliczenia w jednym systemie, z rozdzielonymi rolami użytkowników.

Zamówienia placówek
Monitor kuchni na żywo
Dostawy
Jadłospisy i receptury
Lista zakupów
Raporty i cenniki
Asystent AI
Etykiety

50+

obsługiwanych placówek

ról z izolacją danych w bazie

migracji SQL

≈34 tys.

linii TypeScript

Problem

Firma cateringowa obsługująca kilkadziesiąt placówek przyjmowała zamówienia telefonicznie i rozliczała je ręcznie: placówki dzwoniły z liczbą porcji, kuchnia pracowała z wydruków, kierowcy zgłaszali dostawy słownie, a miesięczne rozliczenie wymagało przeliczania porcji dla każdej lokalizacji z osobna.

Rozwiązanie

Zbudowałem system webowy, w którym placówka składa zamówienie online, a kuchnia widzi je na żywo. Każda rola (administrator, biuro, placówka, kuchnia, kierowca) ma własny panel, a dostęp do danych wymuszam na poziomie bazy, nie tylko w interfejsie.

Wybrane problemy techniczne

Izolacja danych na poziomie bazy

Napisałem polityki RLS w PostgreSQL, które korzystają z roli i placówki odczytywanych z JWT przez funkcje SECURITY DEFINER z pustym search_path. Placówka widzi wyłącznie własne dane, a uprawnienia sub-kont dodatkowo wymuszam po stronie serwera.

Monitor kuchni w czasie rzeczywistym

Zbudowałem widok kuchni, który subskrybuje zmiany przez Supabase Realtime, filtrując tylko dzisiejsze zamówienia. Status przechodzi od oczekującego przez realizację do gotowego, a kuchnia jest bramką dla każdej zmiany liczby posiłków.

Asystent AI z twardymi limitami

Asystent działa na wywołaniach narzędzi, ale limit wielkości korekty liczę od niezmiennej kolumny z pierwotną ilością, bo sesja AI jest bezstanowa, a baza jest jedynym wiarygodnym stanem. Większe lub spóźnione zmiany trafiają do kolejki zatwierdzeń kuchni.

Zadania cykliczne, które nie giną

Vercel Cron na planie Hobby gubił i opóźniał przebiegi, więc przeniosłem przenoszenie zamówień na kolejny dzień do pg_cron jako funkcję SQL, bez zależności od zewnętrznego schedulera i sekretów, z idempotentnym guardem przed duplikatami.

Jadłospisy, receptury i lista zakupów

Wczytuję jadłospis z pliku DOCX przez Mammoth i parsuję go modelem językowym do ustrukturyzowanego JSON. Lista zakupów mnoży gramaturę składników przez liczbę porcji, agreguje je i eksportuje do CSV.

Rozliczenia przygotowane pod KSeF

Zaprojektowałem model danych, który rozróżnia wystawcę, nabywcę i odbiorcę (wymóg dla placówek publicznych). Faktura jest niezmiennym snapshotem liczonym z netto i stawki VAT, a nie z brutto, żeby groszowe różnice nie kumulowały się. Generowanie XML i wysyłka do KSeF to kolejne etapy.

Naprawa skażonych danych

Zbiorczy UPDATE w mojej migracji nadpisał znaczniki czasu wielu wierszy jednym momentem, bo Postgres liczy now() raz na instrukcję. Dodałem do analizy godzin zamawiania wykrywanie identycznych znaczników u co najmniej trzech placówek i ich pomijanie, a medianę liczę z 14 dni roboczych.

Kampanie e-mail bez limitu czasu

Zaprojektowałem wysyłkę do listy placówek jako dwufazową: odbiorcy trafiają do bazy, a klient wywołuje partie po maksymalnie 25 adresów, co wymusza też serwer. Stan przetrwa zamknięcie karty, a do parsowania Excela wybrałem exceljs zamiast xlsx przez znane podatności.

Kolejne rundy audytu bezpieczeństwa

Przeprowadziłem ręczne audyty server actions, polityk RLS i przepływu danych. Wykryłem i zamknąłem m.in. brak guardu w raporcie finansowym, samo-eskalację roli i host-header injection. Każde znalezisko weryfikowałem w kodzie przed poprawką, a pełny log prowadzę w repozytorium.

Stack techniczny

TypeScript (strict)
Next.js 15
React 19
Supabase
PostgreSQL
Row Level Security
Realtime
pg_cron
Server Actions
Tailwind CSS
Sentry
Resend
GitHub Actions

Tallybook

Zamknięty przed wdrożeniem

Silnik fakturowania, self-hosted

Zaprojektowałem i zbudowałem silnik fakturowania: od szkicu, przez zatwierdzenie z numeracją bez luk, po niezmienny dokument, noty korygujące i płatności. Nacisk położyłem na atomowość, współbieżność i niezmienność danych.

Numeracja bez luk
Niezmienne faktury
Noty korygujące
Oferty i zaliczki
PDF i XLSX
Płatności i Stripe
E-mail i przypomnienia

Projekt nie ujrzał światła dziennego: klient zmienił decyzję w trakcie realizacji. Gotowe są model danych, cykl życia faktury, noty korygujące, oferty, dokumenty PDF i XLSX, płatności oraz wysyłka e-mail z webhookami. Nie powstały wdrożenie produkcyjne i integracja z Factur-X.

approveInvoice(): jedna transakcja, stała kolejność blokad

BEGIN;

SELECT * FROM invoices WHERE id = $1 FOR UPDATE -- ta sama faktura

SELECT * FROM invoice_number_counters FOR UPDATE -- licznik firmy

UPDATE invoice_number_counters SET last_number = last_number + 1;

UPDATE invoices SET status = 'approved',

number = $n, seller_snapshot, buyer_snapshot;

COMMIT;

luk i duplikatów numerów w testach równoległego zatwierdzania

skryptów testów integracyjnych, w tym współbieżności

migracji SQL, z ręcznie pisanymi triggerami

≈8 tys.

linii TypeScript

Problem

Firma potrzebowała systemu fakturowania, który nadąży za realną złożonością biznesu: płatności częściowe, noty korygujące, oferty zamieniane w faktury i faktury zaliczkowe, przy zachowaniu wymogów prawnych, czyli numeracji bez luk i niezmienności zatwierdzonych faktur. Gotowe narzędzia albo obsługiwały podstawy i łamały się na przypadkach brzegowych, albo miały więcej narzutu, niż firma potrzebowała, i oddawały kontrolę nad danymi.

Rozwiązanie

Zbudowałem silnik do samodzielnego hostingu, w którym reguły prawne wymusza baza i transakcje, a nie tylko interfejs. Zatwierdzona faktura jest niezmienna, numeracja nie ma luk, a każda operacja zmieniająca stan jest atomowa i odporna na wyścigi.

Wybrane problemy techniczne

Numeracja bez luk pod współbieżnością

Sekwencja Postgresa przeskakuje po wycofanej transakcji, a MAX+1 ściga się z równoległymi zatwierdzeniami. Zatwierdzenie to jedna transakcja z dwiema blokadami FOR UPDATE: najpierw na fakturze, potem na liczniku firmy, zawsze w tej samej kolejności, co wyklucza deadlocki. W teście 5 równoległych zatwierdzeń dało dokładnie kolejne numery, bez duplikatów i luk.

Niezmienność wymuszona w bazie

Ręcznie napisane triggery Postgresa blokują UPDATE i DELETE zatwierdzonych faktur i ich pozycji, bo Drizzle nie ma DSL dla triggerów. Do tego CHECK-i wymagają terminu płatności i danych stron po zatwierdzeniu. Błąd w kodzie lub pospieszny skrypt nie zmutuje zatwierdzonej faktury.

Noty korygujące, które nie przekredytują

Noty mają własną numerację bez luk na tym samym wzorcu blokad. Kwota jest walidowana względem sumy wcześniejszych not do tej samej faktury wewnątrz zablokowanej transakcji. Ten błąd wyłapał przegląd: walidacja w izolacji pozwalała kumulować noty ponad wartość faktury.

Migawka sprzedawcy i nabywcy

Zatwierdzona faktura zamraża dane stron i branding PDF w kolumnach JSONB, więc późniejsza zmiana danych klienta nie zmienia dokumentu. Oferty czytają dane na żywo, bo nie mają wagi prawnej. To świadomy kompromis: dwie strategie odczytu w jednym systemie.

Brak utraconych aktualizacji w sumach

Dwa równoległe dodania pozycji mogły nadpisać zbuforowaną sumę faktury. Blokada wiersza faktury na początku każdej mutacji szkicu zamyka tę lukę dla wszystkich ścieżek naraz. Test równoległego dodania pozycji i powiązania zaliczki potwierdza, że żaden skutek nie ginie.

Płatności: inkrementacja, nie nadpisywanie

Kwota wpłacona jest zwiększana w zablokowanej transakcji, nigdy ustawiana wprost, nadpłata jest odrzucana, a status paid ustawia się automatycznie. Status nigdy się nie cofa: ponowna wysyłka faktury nie zamieni opłaconej w wysłaną.

Wyścig e-maila z płatnością

Stary odczyt sprzed wywołania zewnętrznego API potrafił cofnąć fakturę z paid na sent. Nie trzymam blokady przez żądanie HTTPS, bo wolny dostawca zablokowałby wszystkie operacje na fakturze. Warunek przeniosłem do jednego UPDATE ... WHERE status = 'approved'. Test z prawdziwym wywołaniem API potwierdza wynik.

Webhooki: podpisy i idempotencja

Podpisy weryfikuję SDK Stripe i biblioteką svix zamiast ręcznego HMAC. Płatność idzie przez to samo recordPayment(), więc duplikat dostarczenia jest odrzucany kontrolą nadpłaty i zwraca 200, żeby dostawca nie ponawiał w nieskończoność.

Zaliczki i konwersja ofert bez podwójnych operacji

Powiązanie faktury zaliczkowej blokuje oba wiersze w stałej kolejności, a konwersja oferty w fakturę jest chroniona blokadą przed podwójnym wykonaniem. Oba scenariusze mają testy równoległych wywołań.

Stack techniczny

TypeScript
Next.js 16
React 19
PostgreSQL 17
Drizzle ORM
Better Auth
Stripe
Resend
svix
@react-pdf/renderer
ExcelJS
Docker

Mój stack

Technologie i narzędzia, z których korzystam w swoich projektach.

Chmura i wdrożenia

Cloudflare Workers
Wrangler
D1
Vercel
Docker
GitHub Actions

issiofy.com działa produkcyjnie na Cloudflare Workers, z D1, Analytics Engine i sekretami w Wranglerze.

Automatyzacja i AI

Playwright
MCP
API modeli AI
Claude Code
Codex

Asystent AI z wywoływaniem narzędzi w systemie zamówień, serwer MCP w matchcn i automatyzacje w Playwright.

Język i frontend

TypeScript
React
Next.js
Tailwind CSS
Vite
Three.js
WebGL

Backend i dane

Node.js
PostgreSQL
Supabase
Drizzle ORM
Better Auth
Zod

Integracje i monitoring

Stripe
Resend
Sentry

Narzędzia

VS Code
Vitest
Git
GitHub

Cześć, jestemMichał Franczak.

O mnieO mnie

matchcn

Jak działa pipeline

Ingest

Tag

Match

Resolve

Surface

Wybrane decyzje techniczne

Deterministyczny ranking

Jawne wyniki

Wznawialny pipeline

Dane sprawdzone w praktyce

Briefy w każdym języku

CI pilnuje spójności

Stack techniczny

issiofy

Wybrane decyzje techniczne

Kod zamiast zależności

Render tylko wtedy, gdy ma sens

Dostępność od początku

Czytelne dla agentów AI

Stack techniczny

Aerivo

Wybrane problemy techniczne

Masa i wyważenie dla różnych typów samolotów

Parsowanie METAR

Trasa a przestrzeń powietrzna

Czas cross-country według przepisów

Eksport, który się nie psuje

Procedury dopasowane do typu samolotu

Stack techniczny

March Bunny

Wybrane problemy techniczne

Izolacja danych na poziomie bazy

Monitor kuchni w czasie rzeczywistym

Asystent AI z twardymi limitami

Zadania cykliczne, które nie giną

Jadłospisy, receptury i lista zakupów

Rozliczenia przygotowane pod KSeF

Naprawa skażonych danych

Kampanie e-mail bez limitu czasu

Kolejne rundy audytu bezpieczeństwa

Stack techniczny

Tallybook

Wybrane problemy techniczne

Numeracja bez luk pod współbieżnością

Niezmienność wymuszona w bazie

Noty korygujące, które nie przekredytują

Migawka sprzedawcy i nabywcy

Brak utraconych aktualizacji w sumach

Płatności: inkrementacja, nie nadpisywanie

Wyścig e-maila z płatnością

Webhooki: podpisy i idempotencja

Zaliczki i konwersja ofert bez podwójnych operacji

Stack techniczny

Chmura i wdrożenia

Automatyzacja i AI

Język i frontend

Backend i dane

Integracje i monitoring

Narzędzia

Cześć, jestem
Michał Franczak.

O mnie