FixIt

Marketplace na Expo / React Native + NestJS + Go — rozpoznání problému z fotky, živé sledování, platby v aplikaci. In-product AI vrstva běží s reálnými provozními kontrolami (rozpočet, souběh, idempotence, sledování nákladů) a Codex-pool gateway, na multi-runner test pyramidě (Playwright + Appium + unit/integration).

Problém

Tržiště služeb stojí a padá na důvěře ve chvíli, kdy vám domů přijde cizí člověk. Těžká část není stránka s nabídkou — je to smyčka mezi „tohle mi nefunguje" a „někdo je na cestě a vím, kolik to bude stát".

FixIt jsem postavil přesně kolem téhle smyčky. Zákazník vyfotí problém, vnitroproduktová AI z fotky udělá strukturovanou zakázku, řemeslník ji přijme a obě strany se navzájem sledují na živé mapě, dokud není práce zaplacená. Každý ten krok je jiný systém s jiným způsobem, jak může selhat — rozpoznání, geografické párování, real-time přenos, platby — a všechny se spolu musí shodnout.

Upřímné omezení v pozadí: tohle je můj vlastní produkt pod LEFTEQ a AI funkce uvnitř živého produktu se umí tiše stát nejdražší položkou ve firmě. Proto AI nebyla od prvního commitu demo přilepené ke straně — od začátku běží se stejnou provozní disciplínou jako platby.

Stavba

FixIt běží jako monorepo nad třemi stacky: Expo/React Native aplikace pro zákazníka i řemeslníka, NestJS API a Go status-service (go-chi), který drží real-time stav, jejž si nemůžu dovolit ztratit. Řada aplikací a sdílených balíčků sedí za jednou typově hlídanou hranicí.

Real-time polovina je geografická: PostGIS s H3 buňkami pro párování zakázek na řemeslníky v okolí a WebSocket kanál, který posílá živou polohu na mapu. Platby jdou přes Stripe a Comgate, takže se zakázka dostane od fotky až k zaplacení, aniž by uživatel opustil aplikaci.

Tržišti, které neumím regresně otestovat, nevěřím — testovací pyramida je proto záměrně postavená na víc runnerech: Playwright na webové plochy, Appium na nativní aplikaci a unit/integrační testy umístěné přímo u kódu. Všechno běží na vlastní flotile self-hosted CI runnerů, aby mobilní a zátěžová vrstva jely na hardwaru, který mám pod kontrolou, a souběh pokrývá k6.

AI vrstva

Vnitroproduktová AI je část, na kterou jsem nejvíc hrdý — protože je nudná přesně tam, kde má být. Před každým voláním modelu běží tři pojistky: budgetová pojistka per-tenant, která odmítne práci, jakmile se narazí na strop útraty; pojistka souběhu, která omezuje, kolik volání běží naráz; a idempotenční pojistka, aby opakovaný požadavek nezaplatil dvakrát za stejnou odpověď.

Každé volání pak skončí ve vyhrazeném modulu pro sledování nákladů — hodinové souhrny plus účetní kniha nákladů na třetí strany — takže útrata za LLM je prvotřídní, dotazovatelné číslo, ne překvapení na faktuře od poskytovatele. Každá z těch služeb má vlastní test umístěný hned vedle ní; ty kontroly jsou testované jako plnohodnotná funkce, kterou jsou.

Před poskytovateli modelů stojí samostatná gateway jako mikroslužba: vlastnoručně postavený pool Codex účtů, takže kapacita a přihlašovací údaje žijí za jednou hranicí, místo aby byly rozmazané po celém API. Výsledkem je AI vrstva se stejnou governance, jakou bych dal pohybu peněz — budget, limity, idempotence, auditní stopa — a právě proto může sedět uvnitř živého produktu na fixit.app, ne v pískovišti.