Speed is a feature you can feel
Every interaction has a budget. Under 100ms feels like thought; over a second feels like waiting. We treat a regression in latency the same way we treat a regression in correctness — as a bug that blocks release.
Bahukhandi Labs exists to build a small number of genuinely finished products and keep them working for a long time. It is independent, self-funded, and deliberately unhurried.
Bahukhandi comes from Sanskrit — bahu, many, and khaṇḍa, parts. It is also a family name, which is how it ended up on the door. The reading we build against is the literal one: many parts that hold together as one system.
That is the whole operating model. Every product is genuinely its own thing, with its own problem and its own users. Underneath, they share one design language, one account system, one deployment pipeline and one standard. The foundation is what makes the 6th product cheap to start — and it is why the mark is three squares and a circle: the parts are not identical, but they belong to the same frame.
There is no growth target here and no investor clock. That buys one specific freedom: the ability to say a product is not ready.
Every interaction has a budget. Under 100ms feels like thought; over a second feels like waiting. We treat a regression in latency the same way we treat a regression in correctness — as a bug that blocks release.
A promise in a privacy page is worth very little. We prefer designs where the data never reaches us: local-first storage, per-tenant encryption, and defaults that collect nothing. What we cannot see, we cannot leak.
Care in an interface signals care underneath it. Typography, spacing and motion are not decoration — they are how software tells you whether it was made by someone paying attention.
Every feature we ship makes the next one harder. Most requests are better answered by making something existing work properly. Saying no is the main tool we have for keeping products understandable.
We build for the version of the product that exists in five years. That means boring dependencies, documented decisions, plain-file formats, and an export button that works before anyone asks for it.
Systems that assert without evidence are hard to trust and harder to debug. Where a product makes a claim — a citation, a score, a recommendation — it should be able to show you exactly where that came from.
I started Bahukhandi Labs because the software I wanted to use mostly did not exist, and the software that did exist kept getting worse. Design, engineering and research here are the same job — I do not think you can make a genuinely good product by treating them as separate ones.
The lab is built to outgrow me. Everything is documented, the foundation is shared, and the brand is the lab rather than a person, so adding people does not require rebuilding the identity. If you care about this kind of work, I would like to hear from you.