There’s a version of this story where I describe how AI helped me build faster. That’s not what happened.
What happened is that I used AI to find out where my capabilities actually stopped before designing a product that assumed they extended further.
I’ve been building a Vedic astrology SaaS — an AI-powered report generator that takes a user’s birth data, computes their actual chart, and produces a personalised reading around whatever is weighing on them. The problem it solves is real. The market is there. The technical stack is something I can assemble. What I didn’t know, before I started, was which parts of “the technical stack I can assemble” were accurate and which were optimistic.
So before writing the first version of the implementation plan, I ran a capability assessment.
I gave Claude Sonnet extended thinking mode the documentation from my last project — a live, monetised adult content platform I built and shipped, with a full technical handover document that included architecture decisions, known gaps, and a severity-ranked debt register. Then I asked it to evaluate, honestly, what that evidence said about what I was capable of building next — and what I should be careful of.
What came back had specific scores. Technical understanding: 3.5 out of 5. The line I’ve thought about most: “architectural thinking is at level 4; execution hygiene is at level 2-3.” That’s an accurate description of how I build. I understand why systems are structured the way they are. I am less consistent about the habits that make them maintainable.
The most useful finding was something I hadn’t considered at all. My previous project had no user authentication — no accounts, no sessions, no OAuth, no password handling. In SaaS, authentication is not a feature you add. It’s the layer that touches everything: every route, every permission, every piece of user data. The assessment flagged it as an overconfidence risk — I would likely underestimate how many failure modes existed in the unhappy paths that AI-generated code reliably skips over.
It also flagged database migrations. My previous project had locked its schema before launch and treated “no migrations” as a feature. That works on a static content site. In SaaS, schema changes are unavoidable after users exist. I had no tooling, no experience, and no intuition for this.
Both findings became design constraints in the revised product spec.
Authentication: Supabase Auth. Google OAuth and magic link, sessions handled correctly by default, refresh token rotation not something I’d need to implement or debug. No functionality lost. Several weeks of future debugging saved.
Database: three tables, designed in full before the first line of application code, treated as stable for the entire build. Not because I was lazy about design, but because the assessment told me I’d get surprised by migrations at the worst possible time, and the MVP didn’t need a schema complex enough to require them.
Payment webhooks: the TRD now documents every edge case explicitly — the distinction between different Razorpay events for the same successful payment, HMAC signature verification, idempotent success handlers. Not because I knew to think about these. Because the assessment said payment integration is where money disappears in exactly the gaps that a smooth happy-path implementation doesn’t cover.
The product spec didn’t shrink after the assessment. It sharpened. The same product, with constraints derived from what I’d actually demonstrated rather than what I’d assumed.
I’m still in the planning phase. Week 3 of the build is where the AI prompt quality question becomes real — the whole commercial logic depends on a system prompt producing output specific enough that a user thinks the reading was written specifically for them. That’s the one thing I can’t validate in a document. It only gets tested when real users read a real preview and decide whether to pay.
Everything before that is scaffolding. The scaffolding, at least, is built around an accurate map of the builder.
This is part of an ongoing series of notes about building an AI SaaS product as a solo founder.