Every product problem has two versions.
The one your team is trying to solve. And the one that's actually worth solving. Founders who confuse the two burn months of engineering time building the wrong thing. My job is to make sure you don't.
I help early-stage founders figure out what to build, and whether AI actually belongs in it, before engineering writes a line of code. A few years across product strategy, development, UX, and developer experience means I've watched products fail from every angle: wrong problem, wrong scope, wrong assumptions, wrong tech. I catch those failures while they're still cheap to fix.
Based in India. I work remotely, across US and European hours.
If any of this sounds familiar,
we should talk.
You have an idea (or a half-built product) and you're not sure it solves the right problem.
Someone keeps saying "we should add AI" and nobody can articulate why.
Users are dropping off and everyone has a different theory.
You're about to commit serious engineering time and want a second opinion first.
Clear scope. Clear price.
Clear answer.
A focused pressure-test of what you're building: the problem framing, the assumptions under it, and whether AI genuinely earns its place. You get a written teardown, an assumption map ranked by risk, a clear build / validate / don't-build call, and a walkthrough.
✓ If it doesn't change at least one decision on your roadmap, you don't pay.Separating what users say from what their behaviour reveals, before a dollar of engineering is spent. Assumptions rewritten as falsifiable tests, user interviews, MVP definition, and a roadmap with the reasoning attached. The last founder who ran this was three weeks from building the wrong product. He never did.
Reading a pricing model from the outside and rebuilding what it should sell. I test whether your billing metric tracks both customer value and cost to serve, benchmark the market, then propose changes, each with its tradeoff and the one number that would validate it. The Langfuse teardown is a full working sample.
Docs, onboarding, and DX that cut support load and speed whole teams up. I map the developer journey to first successful call, audit the documentation, and hand back the friction points ranked by what they actually cost you.
Sequencing the bets that matter, and killing the ones that don't, with evidence. Async reviews of specs, roadmaps, and AI decisions, plus a weekly call.
Not sure which fits? Book the free call. Worst case, you leave with a sharper problem statement than you came with.
Book a free discovery callI don't trust the first version of a problem. If a founder tells me "users are dropping off because onboarding is broken," my first question isn't "how's the onboarding?" It's "why do we believe onboarding is the problem?"
That question has saved clients more engineering time than any feature I've ever recommended. Teams rarely struggle because they lack ideas. They struggle because everyone in the room is quietly solving a slightly different version of the same problem. So I spend more time on assumptions than solutions. Once the problem is clear, the right decisions get cheap.
Every project started with a question,
not a feature request.
Who this is for
(and who it isn't).
A good fit
Early-stage founders (pre-seed to Series A) who want their assumptions challenged before they build, and who treat "don't build this" as a valuable answer.
Not a good fit
Teams looking for cheap execution hands, someone to rubber-stamp a decision that's already been made, or "just add AI" without asking whether it should be.
Let's start with your product,
not my services.
The first call is free, 30 minutes, and has one goal: getting your problem statement sharper than it was before the call.
Book a free 30-minute callProducts don't fail
inside one discipline.
I've never been comfortable staying inside one job title. Not because I collect roles, but because products don't fail inside one discipline.
Over the past few years I've worked in development, UX design, technical documentation, and product strategy, and each changed how I see products:
taught me what "small change" actually costs.
taught me users don't read minds, or docs.
taught me that if you can't explain a product clearly, the product usually isn't clear.
taught me the interesting decisions are usually about restraint: knowing which parts have to be correct, and keeping the model away from those.
I work with founders on where AI actually belongs in a product, and I stay close to how AI products should be designed, evaluated, and priced.
Not because it's trending, but because I kept running into the same question in every product conversation: where does AI actually earn its place? I build things to find out. The Langfuse teardown and API Docs Copilot both came out of this.
The path so far.
I started by building. Every step taught me a different way products fail. That's the real qualification.
Worked with founders from idea to execution: discovery, MVP planning, design, and full-stack development. That's where I learned the most expensive mistake in early products isn't bad code. It's confident code in the wrong direction. One of those engagements became the Platform → Wedge story: a company redirected before any engineering was committed.
Moved to where Product, Engineering, and Developer Experience collide, owning API documentation and developer onboarding. Writing docs for developers taught me something no PM course does: if you can't explain a product clearly, the product isn't clear.
Client under NDA
Ran product discovery end to end. Journey mapping, stakeholder workshops, competitor research, turning conflicting inputs into decisions a team could actually act on.
Working with early-stage founders on what to build, and whether AI belongs in it, before engineering starts: product discovery, AI strategy, pricing, and developer experience. Between engagements I go deep on how AI products should be designed, evaluated, and priced. The Langfuse teardown and API Docs Copilot are what that looks like in practice, and it's what I bring to every client.
The toolkit.
You'll usually find me doing one of three things: trying a new AI tool, travelling somewhere for the food, or wondering why a product made a particular decision.
I genuinely enjoy understanding how people think. Different cultures, different products, different behaviours, they all teach me something. Lately I've been slightly obsessed with making Idli Shakshouka, which turned out much better than it had any right to.
Working on something
worth questioning?
Every project started with a question.
Not a feature request. Some are real client engagements; others are independent case studies built to explore hard problems in AI, developer experience, and product strategy. Tap any project for the full story.
Curious how I'd
approach yours?
A fresh idea to validate or an AI feature that isn't landing: the first move is the same. Get the problem right.
Book a free callLet's start with your product,
not my services.
Tell me what you're building, where you're stuck, and what's at stake. The call has one goal: getting your problem statement sharper than it was before. If I can help, I'll say how, and why. If I can't, I'll tell you that too, and you'll still leave with a clearer problem.
Early-stage founders (pre-seed to Series A) who want their assumptions challenged before they build.
Cheap execution hands, rubber-stamping decisions, or "just add AI" without asking whether it should be.
Book the call
30 minutes, free. One goal: getting your problem statement sharper than it was before the call. If I can help, I'll say how and why. If I can't, I'll tell you that too.
Book a free 30-minute callOr just email me
Tell me what you're building, where you're stuck, and what's at stake. A few honest lines beat a long brief. I reply within one business day.
Email meNot sure which engagement fits? Say so. That's what the call is for.