Krishna Palle — product, systems, and the code underneath them · Hyderabad
I follow a problem past the handoff: from user behaviour and interface to the product model, the system, and the code. The pattern shows up in three calls: make consent the product, not a setting; build one platform under five games; reject a flattering model result when it is wrong. Ten case studies show the decisions, trade-offs, and ownership behind work in health, finance, games, payments, and SaaS.
Explore the work → What I'm building now ↓ Read what I think →
The work is easiest to judge by the calls I got to make and the options I gave up to make them.
Vaulth AI · architecture
Seven caregiver scopes enforced across 61 endpoint applications, every external view token-gated and revocable, family circles that share a trend and never the raw number.
Rejected: the aggregator posture — access in exchange for custody. The faster product and the better-funded business model.
Read the decision →Arth · architecture
Bank SMS, PDF statements, and CSV exports converge on one on-device pipeline: deterministic rules for the common case, a 4-bit model only for the uncertain tail.
Rejected: model-first parsing, which would have made the product slower, more expensive to run, and harder to trust.
Read the decision →Cricket Manager · judgment
A 0.98 correlation on the ratings model was the most flattering number the project ever produced. I read it as evidence of a problem and went looking for the leak.
Rejected: reporting it as the headline validation result, which would have been true, checkable, and misleading.
Read the decision →A family's medical records should answer to the family.
In India those records are scattered further than the software assumes — hospital silos, WhatsApp threads, prescription drawers, lab portals — and every existing answer has an owner problem. Portals hold records hostage to one provider; aggregators take custody in exchange for access. Vaulth's answer is that the family is the owner, and that consent, not storage, is the product. I built the consent architecture first and hung everything else off it.
The case study — ten decisions and what each cost →
vaulthai.health — the platform itself
Can a finance app understand your money without ever being told what it is? Bank SMS, PDF statements and CSV exports parsed on-device by a deterministic-first cascade, with a 4-bit Gemma-3 behind a hand-written FFI bridge for the long tail.
0 bytes transmittedphase 4 of 5 — unreleased
How do you make a simulated cricketer behave like the real one — and how would you know if you had failed? A ball-by-ball engine calibrated on 2.07 million real T20 deliveries, player ratings adapted from the Earth Similarity Index, and a live event-sourced auction.
2.07M deliveries modelled 0.98 correlation — rejected as headline
Ten projects across product platforms, independent systems, and research-led builds →
Every year the question changed. That was the trajectory — not the titles.
Figma, user flows, design systems, and the negotiation between beauty and the frontend.
How should this screen work?I stopped treating the handoff as the edge of my job — instrumentation, funnels, the data behind the interface, and enough of the system to argue with the people building it. The backend and infrastructure depth came later, and deliberately.
How does this entire product work?A multi-product portfolio. Retention curves, onboarding funnels, pricing, roadmaps. I stopped optimising components and started optimising outcomes.
Why should this exist?Depth again, at a different altitude: shared platforms under many products, failure direction chosen per surface, and infrastructure cost treated as a design constraint rather than a bill.
What breaks at scale — and what survives it?Product, architecture and code on one surface, with nobody to hand any of it to. The backend and infrastructure depth is recent and deliberate — it is what this rung cost.
What is worth building, and who does it answer to?The stack matters when it changes the product. The decisions show why.
Half a century ago programmers stopped reading assembly. I think we are living through that moment a second time, and the thing we stop reading is source code.
If that is right, value stops sitting in the typing and moves to the six places the machine cannot go: choosing the problem, judging the product, taste, systems thinking, understanding people, and distribution. It is a position rather than a prediction, it is fine to disagree with, and the essay argues it properly — including the controlled trial that cuts against it.
Software is learning to write itself. Someone still has to know what's worth writing.
Building something that should exist? Or want to argue with something on this site? Open to conversations.