Invoice Guru: amikor az AI elvisz a termék 60%-áig

A kiindulópont: egy alapító, egy ötlet és egy AI-val épített app

Az Invoice Guru története nem nálunk kezdődött, hanem egy alapítónál, aki valós hiányt vett észre a piacon. A brit szabadúszóknak és iparosoknak – vízvezeték-szerelőknek, villanyszerelőknek, kivitelezőknek – professzionális, áfa szempontjából hibátlan számlákat kell kiállítaniuk, sokszor rögtön a munkaterületről. A bevett megoldások viszont teljes könyvelőrendszerek: tudnak mindent, de nehézkesek, asztali gépre készültek, és könyvelőknek szólnak, nem annak, aki épp végzett egy munkával, és szeretné megkapni a pénzét.

Azt tette, amit ma egyre több nem fejlesztő: nekiállt maga megépíteni az appot, Flutterben, AI segítségével. És meglepően messzire jutott. Az alapötlet formát kapott, a képernyők álltak, a számlák elkészültek. Validációnak ez telitalálat volt: bebizonyította, hogy a koncepcióba érdemes pénzt tenni.

Aztán lelassult a haladás. Minden új funkció tovább tartott, mint az előző, és ami az egyik helyen javult, az máshol elromlott. Ezen a ponton került hozzánk az Invoice Guru – nem kudarcként, hanem olyan prototípusként, amely megtette a dolgát, és most termékké kellett válnia.

A termék: számlázás azoknak, akik nem könyvelők

A termékkoncepció világos és szűkre szabott volt. A tipikus felhasználó egy iparos, aki a helyszínen, telefonról számláz, pár perccel a munka befejezése után. Nem könyvelő, és nem is akar az lenni. Három dolog számított:

• —Egyszerűség – egy profi számla kiállítása egy perc legyen, ne egy tanfolyam
• —Brit megfelelőség – korrekt áfakezelés az áfakörbe tartozó és az azon kívüli egyéni vállalkozóknak egyaránt
• —Mobil az első – a telefon az iroda, az asztali gép csak ráadás

Amit az AI-prototípus nem tudott megadni

Amikor átnéztük a kódbázist, ismerős kép fogadott – AI-támogatással készült projekteknél ma már rendszeresen látjuk ugyanezt. A látható réteg, vagyis a képernyők, a folyamatok és a funkciók nagyrészt megvoltak. A láthatatlan réteg viszont, amelyen az múlik, hogy egy termék tud-e növekedni, hiányzott.

Nem volt valódi architektúra: a felület, az üzleti logika és az adatelérés egymásba gabalyodott, így egyetlen módosítás sem maradt helyi hatású. Az állapotkezelés ad hoc módon működött, és nehezen reprodukálható, még nehezebben javítható hibákat szült. Az adatréteg törékeny volt – egy olyan appnál, amelyben a felhasználók a vállalkozásuk számláit tárolják, ez komoly kockázat. És ugyanazt a problémát három helyen háromféleképpen oldotta meg a kód, mert egy AI-asszisztens, amely nem látja át a teljes kódbázist, vidáman újra feltalálja azt, ami már megvan.

Mindez nem érv az AI-val való fejlesztés ellen. Ma egyszerűen így néz ki az AI-first építkezés: a termék 60%-át elképesztő tempóban megkapod, csakhogy a maradék 40% éppen az a rész, amitől stabil, karbantartható és kiadható lesz.

A döntés: részleges újraírás, nem tiszta lap

Egy kusza kódbázisra a mérnök első, csábító válasza az, hogy „dobjuk ki, és kezdjük tisztán”. Mi tudatosan nem ezt tettük. A prototípusban az alapító több hónapnyi termékgondolkodása lakott: validált folyamatok, képernyők, amelyeket a felhasználók már értettek, és határesetek, amelyek már előkerültek. Kidobni annyit jelentett volna, hogy ezekért a tanulságokért másodszor is fizetünk.

Ehelyett strukturált, részleges újraírás mellett döntöttünk: a termék viselkedése maradt, az alatta lévő alapokat viszont újjáépítettük. Az óradíjas, time & materials konstrukció végig az alapító kezében hagyta a tempót és a prioritásokat, miközben egy mozgásban lévő termék alatt cseréltük ki a talajt.

Az újjáépítés: unalmas, rétegzett, tesztelhető

Az új alap szándékosan unalmas – pontosan ez benne a lényeg. Az app rétegzett Flutter-architektúrára állt át, éles határvonallal a felület, az alkalmazáslogika és az adatok között: feature-ök, providerek, repositoryk és service-ek, mindegyiknek egyetlen feladata van.

Az állapotkezelés Riverpodra került, így az állapot szétszórt helyett kiszámítható és tesztelhető lett. A helyi adatok Hive-ban élnek, local-first módon, hogy egy iparos egy térerő nélküli pincében is meg tudja írni a számlát. A felhőréteget a Firebase adja: bejelentkezés, Firestore, tárhely, push-értesítések és távoli konfiguráció. A számlák PDF-ként közvetlenül az eszközön készülnek el, az érzékeny adatokat pedig titkosított, biztonságos tároló védi. Azokat a folyamatokat, amelyeken egy vállalkozás mindennapjai múlnak – ügyfelek és tételek felvitele, korrekt áfás számlák –, ma már automatizált tesztek fedik le.

A folyamat tanulsága: a specifikáció túléli az irányváltásokat

A kód mellett még valami megváltozott: az, ahogyan egy funkcióról döntés születik. Az együttműködés elején a követelmények olykor a megvalósítás kellős közepén módosultak. Ez természetes egy alapítónál, aki a termékkel együtt jön rá, mit is akar pontosan – csakhogy félkész kód belsejében drága mulatság.

A megoldás nem technológiai volt, hanem folyamatbeli. Ma minden funkció egy rövid írásos specifikációval indul, amelyet az alapító a fejlesztés megkezdése előtt jóváhagy. Ha közben változik az elképzelés – és változik –, a módosítást egy dokumentumhoz mérjük, nem félkész munkához. És a dolgunk része az is, hogy az egyszerűbb út felé tereljünk: az alapítók gyakran a bonyolult megoldással érkeznek, nem azért, mert az a helyes, hanem mert az jutott eszükbe először. Néha a legértékesebb mérnöki hozzájárulás egyetlen mondat: „ezt egyszerűbben is meg lehet csinálni”.

Az eredmény

Az Invoice Guru elérhető az App Store-ban és a Google Playen is. Az első éles verzió arra összpontosít, amire ennek a szűk célcsoportnak tényleg szüksége van: profi PDF-számlák, ügyfél- és tételkezelés, korrekt brit áfakezelés – alatta pedig az az unalmas, rétegzett alap, amelynek köszönhetően a következő funkció olcsóbban készül el, mint az előző, nem drágábban.

Az együttműködés ugyanabban az óradíjas modellben megy tovább: új funkciók, karbantartás, termékről szóló beszélgetések – és mindegyik egy speckel kezdődik.