Telegram approvals · daily founders summary · alerts that find you
the cart
a live payment
the manager's Telegram
frollie pos · Ikigai AI Ventures02 / 8
02 · how I work
I never let my own work ship on one pass.
the cheapest mistake to fix is thinking QA is the agents' job. I build my own evaluation workflows — qualitative and deterministic.
you can't outsource taste and quality. you build evaluation systems you trust — and that takes time and millions of tokens of iteration.
frollie pos · Ikigai AI Ventures03 / 8
03 · how I ran it
one person. a whole org chart.
I ran a swarm of AI agents like a company — split the work, make them check each other, loop until it's right. the team I didn't hire saved the coordination, not just the salary.
L1
tools I built for this job
a custom task board · a progress report for non-engineers · a checklist the build won't ship without
L2
my reusable playbooks
how I plan, review, debug, and simplify — written once, reused on every job
L3
the brain + the helpers
the AI that does the work · plus the helpers it spins up to work in parallel
L4
the product's plumbing
the database · the hosting · the payment provider · the messaging · the printer · the security
L5
the workshop floor
version control · 500+ automated tests · the design system · the everyday machinery
the build log · progress report
the progress tracker my non-engineer brain reads every morning
scan → github.com/lucasyhzhu-debug/shipshape the QA skill I built — continuously getting smarter, specs → code reviews. my most-used skill.
frollie pos · Ikigai AI Ventures04 / 8
04 · what I got wrong
five common beliefs I now challenge as an agentic practitioner.
I held every one of them on day one. each broke somewhere on the way to day fifteen.
01
“agentic development is easy”
02
“building alone is hard”
03
“consuming is the same as building”
04
“a better model fixes the quality gaps”
05
“build something you can sell”
frollie pos · Ikigai AI Ventures05 / 8
05 · what it actually cost
the build was the cheap part
features took an afternoon. the boring wiring that keeps them from breaking took the days.
CASE STUDY · the off-site approval system
THE BUILD · pillar by pillar
approvals went up in one pillar, transactions in another. each clean on its own — but they talked past each other in time. async seams no demo ever showed.
THE LEAK · the unglamorous part
some transactions were falling through without proper logging — no error, no alert, nothing to see. I only found it while building the refund flow on top of those logs.
THE SAVE · two fixes, not one
1 — end-to-end testing instructions my testing agents follow on every change. 2 — deeper modules behind simpler interfaces, so the seams get tested without touching the internals.
"deep modules" — John Ousterhout, A Philosophy of Software Design
the safety net grew · the surface area didn't
tests public surfaces (domain APIs)
the dashboards that lied to me
288 tests passing green — while hiding a bug that would have broken every payment in the real world.
an "all clear" check that was quietly checking nothing at all.
a tool swore the phone could reach the app. the firewall was silently blocking it. a day lost to a confident lie.
frollie pos · Ikigai AI Ventures06 / 8
meta
this deck built itself.
same method I used on the product — pointed at my own notes and the live app.
6 agentsa few dollars4m 40s to a first draft
frollie pos · Ikigai AI Ventures07 / 8
06 · the takeaway
force is free now. direction is the whole job.
a wrong vector at full force just gets you to the wrong answer faster — and now with better typography.
before you fire up the AI, ask the only question it can't ask for you: am I sure I'm pointing at the right destination?
Lucas Zhu · Ikigai AI Ventures · thank you scan → the essay + more writing lucas-portfolio-pi.vercel.app
from planning doc to taking real money
frollie pos · Ikigai AI Ventures08 / 8
appendix A · what keeps the money safe
what holds it together?
a few rules every sale obeys, no matter who runs it or where. the on-site path and the off-site path cannot drift apart.
what happens when money moves
one rulebook
every path — on-site or remote — runs the same logic. the system can't contradict itself.
frozen receipts
an old receipt never changes, even if I change the menu tomorrow.
press twice, charge once
a double-tap or a dropped signal can never double-charge a customer.
frollie pos · Ikigai AI Venturesappendix A
appendix B · what changed under me
the rules rewrote themselves
five decisions I wrote down, then tore up mid-build. writing them down is what let me catch them.
share one database with our other product
▸
give each product its own system; let them talk through a clean, defined handoff. "integrate by sharing the database" is the decision you regret first.
we'll keep checking the provider to see if a payment landed
▸
the provider tells us the instant it's paid. we stopped checking. a manager's PIN is the only manual override.
approve things over WhatsApp
▸
approvals run on Telegram. the approve link carries its own permission — nothing to store, nothing to leak.
the provider will notify us when the cash actually settles
▸
no such notification exists. we pull the transaction list and match it to ours. (found out by reading the fine print the hard way.)
the payment QR is ready the instant we ask for it
▸
it wasn't — it handed back a web page instead. one wrong sentence in a spec meant zero payments could complete. caught and fixed.
the fix was not being smarter up front. it was making decisions cheap to reverse, in writing, where someone else could catch them.
