The Caveat as a Spec
When a practitioner publishes a workaround and adds 'don't use this without review,' they've told you the quality bar the product needs to clear. The caveat is a design constraint, not a disclaimer.
When a practitioner publishes a workaround and adds 'don't use this without review,' they've told you the quality bar the product needs to clear. The caveat is a design constraint, not a disclaimer.
When a practitioner publishes their manual workflow — the steps they cobbled together to do something a product doesn't do yet — they've written a product spec. They've also confirmed the demand.
Every workaround imposes a cost on users: the time to learn it, the steps to execute it, the expertise to evaluate whether it worked. Absorbing that cost is what a product does. The friction tax is your pricing floor.
There are many ways to infer that a market gap exists. Then there's the rarer thing: a trusted source your target customers already read explicitly saying the gap is there. These are not the same signal.
Sometimes your distribution channel does the education work before you arrive. When that happens, everything about the opportunity changes — and the clock starts ticking.
The gap between 'working code' and 'listed product' has collapsed. The friction that used to protect incumbents — marketplace approval, distribution moats, launch logistics — is largely gone. What that means for what's actually hard now.
Building for professionals with deep domain expertise is often treated as a harder problem than building for general users. It's actually easier — in the ways that matter most.
Tools built for boring professional industries command higher prices, lower churn, and more defensible positions than tools built for exciting ones. The boring isn't incidental — it's the source of the premium.
Before building a product, you need to build a proof. They're different things, optimized for different goals — and confusing them is one of the most common ways to waste months of work.
When a well-funded startup enters your target space, the instinct is to stop. The better read is to look at what they chose to build — and what they chose not to.
Generic tools get you most of the way. The last mile requires knowing something the tool doesn't. That gap is where pricing power lives.
There's a difference between software that solves a problem and software that solves a problem inside the tool you're already in. The second one has a structural advantage the first one can never fully close.
When 88% of organizations are piloting a technology but only 5% are achieving their goals, that's not an adoption problem. It's a product problem.
AI can read a document. The hard problem isn't reading — it's knowing what to look for across five hundred documents at once, and synthesizing it into something a decision-maker can act on.
Before you can build something useful, you need to know where demand exists but supply doesn't. The tools that answer that question are underrated.
Condition assessments don't fail on data collection. They fail on judgment — how long does this last, what will it cost, what should happen first. That's where automation runs out.
When a regulatory body updates a standard or a lender changes their required forms, it creates workflow disruption. Professionals need new tools. The window is brief and predictable.
When researching a market gap, it's easy to get results about an adjacent market that looks identical from the outside. The gap you found might not exist where you think it does.
When a new protocol achieves adoption, a predictable window opens for indie developers. It closes just as predictably. The question is whether you're paying attention.
Most 'AI tools' for technical documents are data retrieval systems. The writing layer — the part that actually produces the deliverable — is still mostly empty.
Some documents appear in two distinct buyer clusters. That's not a complication — it's a signal worth paying attention to.
An absent AI tool is a necessary condition for opportunity. It's not a sufficient one. The buyer matters as much as the gap.
When multiple document types share a buyer, which one do you build first? The answer isn't the biggest one.
Two tools can serve the same compliance domain and occupy completely different product categories. Knowing the difference matters when you're evaluating whether a gap is actually filled.
A Tier-2 opportunity isn't a failed search. It's a finding with weaker entry conditions. Knowing the difference changes what you do next.
When the same professional does two different reports for the same transaction, that's not two separate markets. It's one market with a bundling story.
The best SaaS opportunities aren't hiding in glamorous workflows. They're the small, recurring, non-optional tasks that practitioners hate but can't skip.
Two teams build nearly identical tools. One gets 400,000 users. The other gets 4,000. The difference isn't the technology.
In 2024, generating text was impressive. In 2026, it's the floor, not the ceiling. The AI products winning right now are the ones that do things.
Why the most defensible products come from personal frustration. On building for the problem you've already lived, not the market opportunity you've read about.
Good work is table stakes. The assumption that quality creates its own distribution is the most common mistake builders make. Distribution is a separate discipline.
The most efficient way to kill a startup is for a big platform to add your core feature as a dropdown option. It happens constantly. There are ways to survive it.
Some products are genuinely useful and still fail commercially. The problem isn't quality — it's that utility without perceived scarcity doesn't command a price.
Asking people if they like your idea feels like research. It isn't. There's a hierarchy of signals, and most founders stop at the wrong level.
Building a starter kit for an emerging tool and crossing $5K in three weeks isn't luck. It's a pattern. The tool gets the press; the template captures the revenue.
The most viral developer tools aren't the most useful ones. They're the most enjoyable to encounter. There's a lesson in that.
Some of the most viral tools built recently have no server, no database, no account. Everything runs in the browser. The absence of infrastructure is the feature.
The counterintuitive truth about narrowing your focus: everything gets faster, cheaper, and more referrable when you serve fewer types of people.
Building the product is the easy part. The harder work — the part most engineers underestimate — is everything that happens after you ship.
On finding the smallest repeatable unit of value and what it means to ship the same solution more than once.
Building feels like progress. It is the perfect activity for someone who is afraid to find out whether their idea is any good.
The product you threw together as an afterthought is often the one the market actually wants. This is uncomfortable. It's also useful information.
The best product ideas aren't in brainstorming sessions — they're in one-star reviews and frustrated forum posts