• Building SaaS from scratch using AI coding agents. 🛠️
• Documenting the entire journey—wins, failures, and real numbers. 📈
• Zero to launch. Let's ship.👇
I'm starting from zero.
I don't know how to code, how to build SaaS, how startups work.
So I'm going to learn by actually building.
I'm using AI coding agents to see how far one person can go.
I'll share the wins, failures, lessons and numbers.
Day 1 starts today. 🧵
@GergelyOrosz Don't worry, management is on top of it. They're planning a 6-month initiative to form a committee that will eventually draft a mandate for a token leaderboard. Just hang tight and definitely don't do anything autonomous while they figure it out.
@Mubbi_sk If the 'AI developer' actually understands the code, can debug it, and delivers 3x faster... aren't they just a senior developer using better tooling? It’s about leveraging efficiency.
I thought I was ready to test the password-recovery fix.
Then Supabase returned HTTP 429.
The latest test was rate-limited before I could verify whether the PKCE change worked.
No more repeated emails. I'll wait for the limit to reset and run one controlled test.
I learned something new about Supabase PKCE today.
A verifier cookie can exist and still be the wrong verifier for the authorization code.
Presence isn't proof of correctness.
That one distinction changed how I approached debugging InvoiceFlow's recovery flow.
Today's debugging lesson:
A password-reset email arriving doesn't mean password recovery works.
Delivery, link verification, PKCE exchange, and session creation are different steps.
I used to see one error page. Now I'm learning to find the exact stage that fails.
Day 16 building InvoiceFlow in public.
Today I traced a password-recovery failure to a PKCE bad_code_verifier error, implemented a recovery-only flow-ID change, and passed lint + TypeScript checks.
Still not fixed end to end.
Next: test properly.
This is part of the build.
Day 15 recap:
• Found a Supabase 429 during password recovery
• Confirmed reset emails can arrive
• Recovery links still fail at the callback
• Asked the coding agent to investigate before edits
No fake “shipped it” update today. Just the next debugging step.
Build-in-public isn’t just posting wins.
Sometimes it’s showing the bug, reading the logs, and resisting the urge to make five changes at once.
Day 15: recovery flow still broken. Next step: inspect, understand, then fix.
Today’s reminder: a working login screen is not the same as secure multi-company access.
InvoiceFlow still needs company-scoped permissions and RLS work. I’m not calling tenant isolation “done” until it’s tested.
Quick question for freight, AP, and invoice-processing teams:
When an invoice is flagged for review, what usually happens next in your workflow—spreadsheet, email thread, ERP note, or another tool?
I’m researching the real process before building more into InvoiceFlow.
SaaS founders: What’s one security or architecture decision you wish you’d made earlier?
I’m building InvoiceFlow and mapping out multi-tenant access control before adding database-heavy features.
Drop your hard-earned wisdom below 👇
Debugging rule I’m trying to follow: stop guessing when the logs can narrow it down.
InvoiceFlow’s recovery request returned HTTP 429. The link then failed with otp_expired.
I’m asking my coding agent to inspect the flow before approving any fix.
Beginner lesson from today: “The email arrived” doesn’t mean “password recovery works.”
The link still has to survive the callback, token exchange, and session handling.
I’m learning to test the whole flow—not just the first step.
Day 15 building InvoiceFlow.
Today wasn’t about shipping a shiny feature. I traced a password-reset failure, found Supabase returning 429, and confirmed the recovery link still fails.
Next: inspect the callback before changing more code.