How I work - Discover, build, iterate
No 12-week discovery phases. No committee-approved roadmaps. I move fast, stay close to users, and let evidence drive decisions. Here's what that looks like in practice.
Discover
Every product starts with a problem worth solving. I spend time mapping the existing landscape — who has this problem, how are they solving it today, and where are the biggest gaps.
For Homi, this meant studying how people actually search for apartments: the frustration of filtering by static attributes when what you really want is a feeling. For SwipeStats, it meant talking to Tinder users who were drowning in data but had no way to make sense of it.
The goal of this phase is to get to a sharp problem statement and a clear hypothesis. Not a business plan — a bet.
What this looks like
- User interviews
- Market sizing
- Competitor teardowns
- Problem statement
- Early prototypes
- Hypothesis definition
Build
I build with a small surface area: Next.js, TypeScript, tRPC, Postgres. Same stack across every product. This isn't laziness — it's leverage. Familiarity lets me ship fast without accumulating hidden complexity.
The first version of anything is a working prototype, not a production system. I'd rather have ten real users using something rough than spend three months polishing something nobody needs.
AI is now a first-class collaborator in every build. I use it for code generation, UX copy, data processing, and feature brainstorming — not as a shortcut, but as a force multiplier for a single founder moving at speed.
Core stack
- Next.js
- TypeScript
- tRPC
- Drizzle ORM
- Postgres
- Vercel
Iterate
Launching is the beginning, not the end. After an initial release I watch how people actually use the product — not how I imagined they would. Usage patterns, drop-off points, and support messages are data. Opinions are cheap.
Each iteration is a small bet: a specific change with a clear expected outcome. If it works, double down. If it doesn't, cut it and move on. The compounding effect of many small improvements beats one perfect release every time.
Iteration also applies to the portfolio itself. I'm not attached to any particular product — I'm attached to building things that matter. If the evidence says pivot, I pivot.
How I track progress
- Metrics over feelings. I define success metrics before building a feature, not after. If I can't measure it, I question whether it's worth building.
- Tight feedback loops. Direct access to users. No layers of account managers or product committees. Feedback reaches me in hours, not sprints.
- Kill fast. Features that don't move the needle get removed. Simplicity is a competitive advantage, especially for a solo product.
Principles - What I actually believe
Not values from a brand exercise. Things I've learned from building products, making bets that didn't pan out, and occasionally getting it right.
- Evidence over opinion. The right answer is usually in the data, not in the meeting room. I try to form hypotheses and test them rather than argue about what users want.
- Small surface area. Fewer abstractions, fewer dependencies, fewer moving parts. Every layer of complexity is technical debt you're paying interest on.
- Compounding bets. The products I build share underlying infrastructure and insights. Work done on one informs the others. That's not accident — it's strategy.
- Remote by default. I've worked from Oslo, New York, and places in between. The best way to stay sharp is to stay curious — and that requires freedom of location.
- Ship, then polish. Perfect is the enemy of shipped. A rough product in front of real users teaches more than any internal review cycle.
- Own the problem. I build in domains where I have genuine conviction. Dating data, home search, professional mobility — these aren't random bets. They're problems I've lived.