I build when platforms fail specific users
Every venture I've started began with the same observation: a category where the dominant platforms were too generic, too slow, or structurally misaligned with actual user behavior. Not broken in obvious ways. Just indifferent to the specific audience that needed them most.
Dropped Pin came from watching international fashion remain inaccessible to Indian consumers despite clear demand. PurvX came from watching the secondhand market grow while South Asian fashion was ignored entirely. Evryfit came from a product gap in fitness that no existing brand was addressing.
Niche specificity is a structural choice
I build narrow. Not because I lack ambition to go broad, but because specificity creates structural advantages that generalist platforms can't replicate. When you build for a defined audience, you make product decisions a horizontal competitor would never prioritize.
The instinct to go niche trades total addressable market for depth of fit. In my experience, that trade pays off, especially in markets where trust and cultural context matter more than selection volume.
Community precedes the transaction layer
The ventures that worked started with an audience before they started with a product. A blog became a customer base. A content strategy became an acquisition channel. Understanding what people wanted, and earning their attention, came before asking them to buy anything.
Build the transaction layer first and you're competing on features and price. Build the community first and you're competing on trust and relevance. The second is harder to replicate.
Bootstrapping forces clarity
Every company I've built has been bootstrapped. Not because raising wasn't an option. Because I didn't want the distortion. When there's no runway buffer, every decision is cash-accountable. You can't paper over a weak product with paid acquisition. You can't delay hard trade-offs because the next round will fund them.
Bootstrapping compresses decision quality. It forces you to find organic demand, build products people actually pay for, and maintain unit economics from the start.
Operating experience changes what you build first
Having run large operations changes what a founder prioritizes. You think about data infrastructure earlier. You build seller tools before marketing dashboards. You design for operational load at scale, not just launch day. You measure decay signals, not just growth signals.
This isn't about applying enterprise process to a startup. It's about knowing which parts of that thinking are worth keeping and which to discard entirely.
My founder work sits alongside my operating career. It's the part where the patterns I kept seeing became problems I decided to solve directly.