Most product builders share the highlight reel — the launch day, the growth chart, the feature announcement. They skip the part where nothing worked, the architecture was wrong, or the market didn’t care.
This blog exists to document everything. Not just the wins, but the decisions, the failures, and the architecture behind every product built under Vystra.
Why Document?
Three reasons:
- Accountability — writing down your reasoning forces you to actually have reasoning. It’s easy to ship something on instinct. It’s harder to explain why you made a specific technical or product decision. The act of documenting keeps you honest.
- Knowledge sharing — the Indian tech ecosystem is growing fast, but practical build logs are rare. There’s no shortage of tutorials. There’s a massive shortage of “here’s what I actually did, here’s what went wrong, and here’s what I’d do differently.”
- Personal record — two years from now, I want to look back and see exactly how decisions were made. Not a polished narrative, but the raw truth of what happened.
What This Blog Will Cover
- Build logs — detailed breakdowns of how each product and feature is built. Architecture decisions, technology choices, trade-offs, and implementation details.
- Product thinking — how I identify problems, validate ideas, and decide what to build next. The frameworks and mental models behind product decisions.
- Market insights — what I learn about the industries I’m building for. Construction, professional services, and whatever comes next.
- MedTech x Tech — how working in regulated medical technology shapes the way I approach product engineering. The crossover between validation mindset and startup speed.
The Rules
Every post on this blog follows three rules:
- Be honest — if something failed, say it failed. If a decision was wrong, explain why. No revisionist history.
- Share failures — the failures are more instructive than the successes. A post about what went wrong is worth more than ten posts about what went right.
- Optimize for being useful — every post should leave the reader with something actionable. A technique they can use, a mistake they can avoid, or a way of thinking they hadn’t considered.
This isn’t content marketing. It’s an engineering log that happens to be public.
Welcome to the blog. Let’s build.