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. It's the same core loop I taught in Lean Startup talks in 2016 to 2018, updated for how I build today.
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 is to turn the vision into testable assumptions: a sharp problem statement and a clear hypothesis. Not a business plan. A bet. Product development should feel more like driving a car and making small corrections than launching a spaceship on a fixed trajectory.
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 is a working learning instrument, not a smaller list of features or a bad version of the final product. I'd rather have ten real users teach me something 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. It isn't a shortcut, but a force multiplier for a single founder moving at speed.
Core stack
- Next.js
- TypeScript
- tRPC
- Drizzle ORM
- Postgres
- Vercel
Product Atlas
Map the job. Then map where the product does it.
A feature list loses the thread. I start with the job someone is trying to get done, break it into concrete stories, then connect those stories to the screens, routes, data, and services that make them real.
The result is a product map that a founder, designer, or coding agent can inspect. It shows what exists, what has been verified, and where the experience has holes.
Homi example: job steps by product view
This is an experience inventory, not a replacement for the delivery backlog.
An early Homi product view from 2024. Old screens are useful evidence when the map records what they were and when they were observed.
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.
First establish a baseline. Then tune the engine through small bets: a specific change with a clear expected outcome. If it works, double down. If it doesn't, cut it and move on.
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 an 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. 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, and professional mobility aren't random bets. They're problems I've lived.