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

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

Az Invoice Guru nem a HyperCode-nál kezdődött, hanem egy alapítóval, aki valódi piaci rést látott: a brit vállalkozóknak és szakembereknek — vízszerelőknek, villanyszerelőknek, építőknek — professzionális, áfa-szempontból korrekt számlákat kell kiállítaniuk, gyakran közvetlenül a munkaterületről. A bevett eszközök teljes könyvelőprogramok: erősek, de nehézkesek, asztali gépre szabottak, és könyvelőknek készültek — nem olyanoknak, akik épp befejeztek egy munkát, és szeretnék megkapni a pénzüket.

Azt tette, amit ma egyre több nem-fejlesztő: elkezdte maga megépíteni az alkalmazást, Flutterben, AI segítségével. És meglepően messzire jutott. Az alapötlet formát öltött, a képernyők elkészültek, a számlák generálhatók voltak. Validációként ez valódi siker volt — bebizonyította, hogy a koncepcióba érdemes befektetni.

Aztán a haladás lelassult. Minden új funkció tovább tartott, mint az előző. Az egyik helyen végzett javítás máshol rontott el valamit. Ezen a ponton került hozzánk az Invoice Guru — nem kudarcként, hanem olyan prototípusként, amely elvégezte a dolgát, és termékké kellett válnia.

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

A terméktézis világos és szűk fókuszú volt. A tipikus felhasználó egy szakember, aki a helyszínen, telefonról számláz, percekkel 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 professzionális számla kiállítása egy percet vegyen igénybe, ne egy tanfolyamot
• —Brit megfelelőség — korrekt áfakezelés áfakörös és áfakörön kívüli egyéni vállalkozóknak egyaránt
• —Mobil-először — a telefon az iroda; az asztali gép opcionális

Amit az AI-prototípus nem tudott nyújtani

Amikor felmértük a kódbázist, egy olyan mintázatot láttunk, amellyel ma már rendszeresen találkozunk AI-támogatott projekteknél. A látható réteg — képernyők, folyamatok, funkciók — nagyrészt megvolt. A láthatatlan réteg, amely eldönti, hogy egy termék képes-e növekedni, nem.

Nem volt valódi architektúra: a felület, az üzleti logika és az adatelérés összefonódott, így egyetlen változtatás sem maradt lokális. Az állapotkezelés ad-hoc módon működött, nehezen reprodukálható és még nehezebben javítható hibákat okozva. Az adatréteg törékeny volt — komoly kockázat egy olyan appban, amelyben a felhasználók a vállalkozásuk számláit tárolják. É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, boldogan feltalálja újra, ami már létezik.

Mindez nem érv az AI-val való építkezés ellen. Ez az AI-first fejlesztés mai valósága: a termék 60%-át elképesztően gyorsan megkapod — de a maradék 40% pontosan az a rész, amitől stabil, karbantartható és kiadható lesz.

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

Egy rendezetlen kódbázisra a csábító mérnöki válasz az, hogy „dobjuk ki és kezdjük tisztán”. Mi tudatosan nem ezt tettük. A prototípus az alapító többhavi termékgondolkodását kódolta: validált folyamatokat, a felhasználók által már megértett képernyőket, felfedezett határeseteket. Ezt kidobni annyit jelentett volna, hogy ezekért a tanulságokért kétszer fizetünk.

Ehelyett strukturált részleges újraírást végeztünk: a termék viselkedését megtartottuk, az alatta lévő alapokat újjáépítettük. Az óradíjas konstrukció közben teljes kontrollt adott az alapítónak a tempó és a prioritások felett, miközben egy mozgó termék alatt cseréltük ki a talajt.

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

Az új alap szándékosan izgalommentes — pontosan ez a lényege. Az app rétegzett Flutter-architektúrára állt át, tiszta határvonallal a felület, az alkalmazáslogika és az adatok között: feature-ök, providerek, repository-k és service-ek, mindegyik egyetlen feladattal.

Az állapotkezelés Riverpodra költözött, így az állapot kiszámítható és tesztelhető lett a szétszórtság helyett. A lokális adatok Hive-ban élnek — lokális-első megközelítéssel, hogy egy szakember egy térerő nélküli pincében is tudjon számlát írni. A felhőréteget a Firebase adja: autentikáció, Firestore, tárhely, push-üzenetek és távoli konfiguráció. A számlák PDF-ként közvetlenül az eszközön generálódnak, az érzékeny adatokat pedig titkosított biztonságos tároló védi. A vállalkozás számára kritikus folyamatokat — ügyfelek, tételek, korrekt áfás számlák — ma már automatizált tesztek fedik.

A folyamat-tanulság: a specifikáció túléli a meggondolásokat

A kód mellett még valami megváltozott: az, ahogyan a funkciókról döntés születik. Az együttműködés elején a követelmények olykor implementáció közben módosultak — természetes egy alapítónál, aki a termékkel együtt fedezi fel, mit is akar, de drága, ha félkész kód belsejében történik.

A megoldás nem technológiai, hanem folyamatbeli volt. Minden funkció ma egy rövid írásos specifikációval indul, amelyet az alapító a megvalósítás előtt jóváhagy. Amikor az elképzelés változik — és változik —, a változást egy dokumentumhoz képest tárgyaljuk meg, nem félkész munkához képest. És a munkánk része az egyszerűbb út felé terelés is: az ügyfelek gyakran a bonyolult megoldással érkeznek — nem azért, mert az a helyes, hanem mert az volt az első, amit el tudtak képzelni. Néha a legértékesebb mérnöki hozzájárulás ez a mondat: „van erre egy egyszerűbb megoldás”.

Az eredmény

Az Invoice Guru elérhető az App Store-ban és a Google Playen. Az első éles verzió arra fókuszál, amire a célcsoportnak valóban szüksége van: professzionális PDF-számlák, ügyfél- és tételkezelés, korrekt brit áfakezelés — alatta pedig az az unalmas, rétegzett alap, amelytől a következő funkció szállítása olcsóbb lesz az előzőnél, nem drágább.

Az együttműködés ugyanabban az óradíjas modellben folytatódik: új funkciók, karbantartás és termékbeszélgetések — mindegyik egy specifikációval kezdődik.