From Code-First to Outcome-First: How Owning a Product Changed the Way I Think
Before this, I looked at code and saw the outcome.
Now I look at the outcome and figure out the code.
That one inversion changed how I think, what I build, and what I now care about.
What Happened
I was handed SpaEra — a half-built, un-monetised spa and salon management product with 18 months of prior work and zero revenue. No one told me what to do with it. No tickets, no roadmap, no PM.
Just a codebase, a market, and a deadline.
So I did what the moment asked. I studied the industry. Segmented the market. Wrote a business plan. Figured out pricing. Designed a PLG flow. Bought the domain. Presented to the board.
And then — still — wrote all the code.
The Shift
I've always been good at the technical side. Distributed systems, Redis locks, real-time OTA sync across four booking platforms — that's my native context at Bookingjini building Hotelkite.
But that skill set had a blind spot: I built what I was asked to build. The why was someone else's job.
With SpaEra, there was no someone else.
I had to understand that India's spa market is ₹20,000 Cr, growing at 15.5% CAGR, and mostly running on WhatsApp and paper. I had to identify our real target — mid-market urban spas, 3–10 staff — and size it (4,500–6,000 businesses under-served). I had to argue against freemium pricing to the board, with logic, not instinct.
None of this was in my job description. All of it made me better at my actual job.
What "Owning" Really Means
Owning a product isn't being the sole developer. That's just being alone.
Owning means every feature starts with a question: what behaviour am I trying to change? When I built the PLG onboarding flow, I wasn't optimising for clean code. I was optimising for one thing: getting a spa owner to their first booking and first invoice within a week. Everything else was noise.
The code still matters — it has to scale, it has to hold. But it's in service of something now. That's the difference.
The Part Nobody Tells You
There are questions in this work that don't have test cases.
When do you launch? How do you price without anchoring too low? When a hotel says "we're interested" — how do you turn that into a paid trial without overselling?
I've had to make calls with incomplete information and own the outcome either way. That's uncomfortable for someone trained to verify everything. But it's learnable. And it's made the technical decisions sharper — because now they connect to something real.
More to Come
This is the overview. Each piece of this journey has a full story behind it:
- The pricing argument I made to the board — and why I argued against freemium
- Architecture decisions and what we got wrong first
- How I broke down an industry from scratch to find the opportunity
- Building a PLG flow for a B2B SaaS with a lean team
If you're an engineer thinking about the product side — this is what it actually looks like. Not a career pivot. A capability upgrade.
Harsha Vardhan Raju is a Full Stack Engineer at Bookingjini, building Hotelkite and SpaEra.