In Practice: How I Actually Start a Product From Scratch

The two products I've built for myself started the same way. Not with a market analysis or a TAM calculation. With frustration.

The first time, I was sitting with a lease in front of me — a long one, dense with clauses I didn't fully understand — knowing that signing it meant committing to a place I'd live in for the next year or more, possibly giving up rights I hadn't read carefully enough to notice. Hiring a lawyer for every lease I considered wasn't realistic. Reading through every clause with the legal literacy to understand what I was agreeing to wasn't either. I was effectively signing blind, and I knew it.

The second one started with a LinkedIn post. Someone had built virtual fences for cows using AI-powered collars — a genuinely interesting product. It made me ask myself: could I do something like this?

I ran the assumptions fast. I don't know anything about livestock. I don't have capital for hardware. The people I'd be selling to would need to buy a device before they got any value from the product — and most of them already had a phone.

That last part was the pivot. I have a dog. I care about his health. And I realized that most dog owners I knew were already cobbling together a picture of their dog's health across apps that didn't talk to each other — a vet portal that didn't carry over to their groomer, no easy way to share records with a partner or a boarding facility, and vet-owned apps with UX that hadn't been updated in years. The problem wasn't that there was nothing — it was that none of it was for the owner. It was all built for the facilities.

I wasn't trying to compete with the vet portal. I was solving a different problem: keeping a complete, shareable health record for your dog that goes wherever your dog goes, owned by you, not by whoever last saw them.

The phone was the distribution. The dog was the customer. The problem was already being worked around, badly, by every dog owner I knew.

Neither of these started with a product idea. They started with a problem I was already living with — or in the second case, a conversation that forced me to challenge my assumptions until I found one I could actually build on.

That's the first principle, and it's the only one that actually matters before you build anything.

Start with a problem you're already solving badly

The founders who waste the least time and money building the wrong thing have one thing in common: they already have the problem. Not a problem they identified through research or spotted in a forum. A problem they personally encounter, work around, and find expensive or annoying enough that they'd pay for a better solution.

This isn't the only way to find a good product idea. But it's the most reliable filter for whether the problem is real. If you're living with the friction, you know it's real. You don't have to convince yourself it exists.

The test I run before anything else: am I already spending time, money, or stress working around this problem? With the lease, the answer was yes — time reading clauses I didn't understand, stress about what I was signing, and the background cost of decisions made with incomplete information. With Moose, the answer was yes — the problem was established before I wrote a line of code.

If the answer is no — if the problem is something you've observed or imagined but don't personally encounter — that's not disqualifying, but it raises the bar on everything that comes next. You'll need other people's evidence, not just your instinct, to validate that the pain is real enough to build around.

Find out if someone else has already solved it

The reflex for most founders at this point is to start building. That's a mistake. Before anything gets built, spend a day finding out what already exists.

For both products, I did this before writing a single line of code. I searched for lease analysis tools, looked at what lawyers were charging for this kind of review, read the reviews of every pet health app I could find. I wasn't looking for a clear gap — I was looking for an honest picture of the landscape.

What I found was more useful than a gap: existing tools that were either too expensive, too complicated, too generic, or solving an adjacent problem rather than the specific one I had. The lease analysis tools that existed were built for commercial real estate or for legal professionals — not for a renter trying to understand what they were signing. The pet health apps were either vet-facing, built for clinical records rather than the owner, or required expensive hardware for fitness tracking — a cost that would be disproportionate to the rest of the product and a constant source of churn for anyone whose dog didn't take to wearing a device.

That's the competitive research output you're actually looking for: not "nobody is doing this" but "here's exactly what's being done and here's the specific gap where what I need doesn't exist." The former is usually wrong. The latter is actionable.

If what exists already solves your problem well, that's valuable information. Either the opportunity isn't there, or you need to get more specific about what isn't working in the existing solutions before you build.

Get ruthlessly specific about the smallest version

This is where most founders go wrong, including me. The Lease Analyzer was ready — functional, useful, genuinely solving the core problem — and I kept building anyway. I added landlord ratings, apartment mapping, features nobody had asked for. I had a working MVP and I built past it before a single person had paid to use it.

The question to ask before you build anything is: what is the single smallest thing that would tell me whether this problem is worth solving at scale?

For the lease analyzer, the answer was: can I surface the clauses a renter should pay attention to from a raw lease document? Everything else could wait until someone had paid to use the core thing.

For Furvalis, the answer was: can a dog owner maintain a health timeline their vet can actually reference? The co-owner sharing, the AI summary, the document extraction — all of it came later, after the core record was useful enough that people were actually using it.

The smallest version isn't the version with everything stripped out. It's the version that tests whether the core assumption holds: that this problem is real, that people will use something to solve it, and that what you've built is the right shape of solution. Everything else is a hypothesis you don't get to test until that one is confirmed.

On prototypes: design first, code second

Before any code exists, the fastest way to test whether your smallest version makes sense is to draw it.

Not a high-fidelity mockup. A rough sketch — in Figma, on paper, in any tool that lets you move boxes around faster than you can write code. The goal is to find out whether the product you have in your head is coherent before you commit any engineering to it. Most of the time, the act of drawing forces questions you hadn't thought to ask: what happens after the user does this? Where does this data come from? What does empty state look like?

For non-technical founders, this step is especially important — because the design prototype is also the thing you put in front of potential users before building anything. A Figma mockup you can click through gives you real feedback on whether the solution makes sense to the people who would use it. That feedback is almost always more valuable than the first version of the code.

For the actual build, tools like Lovable, Bolt, and v0 have changed the calculus significantly. A non-technical founder can get a working product in the browser in a day — not a mockup, but something that actually runs — using these tools. I tend to start from a blank repo rather than a managed environment, using tools like Claude Code to move fast while keeping full control of the stack. But that's a personal preference rooted in where I want to be technically, not a recommendation for most founders. The honest truth is that Lovable and similar tools handle infrastructure and hosting automatically — things that genuinely don't matter at the early stage — which means a non-technical founder can move faster than I do in the first sprint without any of the setup overhead. When the product has paying customers and real scale pressure, that's when custom development becomes necessary. Until then, iterate with real users first.

The distinction between a design prototype and a code prototype matters here. A design prototype tests whether the solution makes sense. A code prototype tests whether the solution works. Both are useful at different stages. The mistake is skipping the design prototype and going straight to code — you end up building something that works but doesn't quite fit, and the rework costs more than the sketch would have.

The defensibility question

Before you commit to building the full thing, there's one more question worth asking: if this works, can it be defended?

This is the question most lean startup content skips, and it's the one I've learned to take most seriously. An MVP that proves product-market fit is only the beginning — the question is whether what you're building can become something that's hard to copy once a better-funded competitor notices it exists.

For Furvalis, the defensibility isn't in the app — it's in the data that accumulates as more owners and vets use it. The health records, the behavioral observations, the longitudinal data on outcomes — that's the moat, and it gets stronger with every user. For Turnkey, the defensibility is in the network: the more verified lease reviews and landlord ratings exist in the system, the harder it is to replicate from scratch.

Neither of these was fully clear on day one. But asking the question early changes what you build toward. If the answer is "I'm not sure," that's not a reason to stop — it's a reason to make sure the decisions you make in the MVP preserve your options rather than closing them.

A product that proves the market exists is worth building. A product that proves the market exists and sets you up to own a piece of it is worth building and scaling.

The short version

Start with a problem you're living with. Verify it's real by checking whether you're already spending money, time, or stress working around it. Find out what exists. Get specific about the smallest thing that tests your core assumption. Draw it before you build it. Build the minimum version. Then ask whether it can be defended.

This isn't a novel framework. It's how every product that lasted was built. The specific version we run — with the defensibility test as the final gate — is the piece that most process frameworks leave out. It's also the piece that saves the most wasted time.

If you're at the start of this process and want a second set of eyes on whether the problem is real and the solution is the right shape — that's the conversation worth having.