Building
Vaulth AI, as its founder and still its only engineer.
The platform runs: seven services on Docker Swarm, 207 endpoints, a mobile app across fifty screens in six Indian languages. It is pre-launch. My week is consent architecture, AI guardrails, infrastructure cost, and the compliance work that decides what the product is allowed to promise. The case study has the decisions and what each one cost.
What I am working on this month is the shortest path from "runs" to "someone depends on it" — which is a distribution problem, not an engineering one, and I am deliberately worse at it.
Exploring
Arth is at phase 4 of 5. Phase 5 is blocked on measurement on purpose — its design depends on numbers the app has to collect from real use first, and inventing those numbers to unblock myself would defeat the point of the phase.
Cricket Manager exists and runs. Whether it becomes something other people play is an open question I have not answered.
Separately: how far a deterministic-first cascade can carry a product before a model is needed at all, which is the question underneath both of the above, and one I would like a better answer to than "further than people assume."
Current bets
Three things I am acting on rather than just believing — and the finding that argues with all of them.
Small teams, directed. My working bet is that a small team with clear product judgment, strong verification, and capable tools can take on more than its headcount suggests. I am testing that by running a pre-launch healthcare platform as one person with agents, and finding out precisely where it breaks.
Governance is a solo-founder problem, not an enterprise one. A single engineer has no code review by default. The engineering constitution, the blocking CI gates and the claims-verification labels at Vaulth exist because I needed to manufacture the friction that a team would have provided for free.
Constraints that competitors won't accept. Arth's zero-transmission rule and Vaulth's refusal to claim certification both cost real capability. Both are the only durable thing about those products.
And the counter-evidence I keep in front of me. A controlled trial of experienced developers, working in codebases they knew well, found them measurably slower with AI assistance — while predicting beforehand that they would be faster, and still believing afterwards that they had been. That result is inconvenient for all three bets above, which is why the essay argues with it directly rather than around it — and says there what I can and cannot currently source for it. If the first bet is wrong, it will be wrong in that direction.
Next
Getting Vaulth in front of the five people it was designed for — a caregiver managing a parent's records at distance is the one I understand least well and need to be wrong about early. Then the first design partners, then the numbers that decide whether the consent thesis survives contact with people who did not think of it.
Underneath that: getting materially better at distribution, which is the weakest thing I do and the one skill that would change what every future project is capable of. And writing more — the thesis has been a single essay for too long, and the arguments I have changed my mind about since are the interesting ones.
Positions, not predictions — and not a reading list. What I change my mind about lands here when it changes, rather than when it would look good.
If this page ever looks polished, I've stopped updating it.