The Vertical IDE Pattern
Cursor proved that professionals will pay premium prices for AI tools designed around their specific workflow. Now the same pattern is being applied to every profession.
Cursor proved that professionals will pay premium prices for AI tools designed around their specific workflow. Now the same pattern is being applied to every profession.
Most organizations say AI adoption is a top priority. Most organizations haven't actually done it. The gap between those two facts is where products win.
Most beta tests measure whether the software works. The beta test that matters measures whether the workflow works.
Professional users don't decide to trust a tool. They decide to trust an output. Then another. Then another. The trust is incremental, not wholesale.
The goal in a new protocol market isn't to win — it's to be embedded before the serious competition shows up.
Freemium works when the free tier proves value and the paid tier removes the specific friction the free tier creates.
Before you price anything, answer one question: what does the manual version of this cost right now?
The tools that can replicate you most easily aren't the ones who compete with you directly. They're the ones doing something adjacent.
Source citations aren't a nice-to-have in professional document workflows. They're the feature that determines whether a professional will trust the output.
When building a document processing tool, the code is the easy part. The schema is the hard part.
Eleven thousand tools exist. Less than five percent make money. That gap isn't a failure — it's an opportunity with a very specific shape.
The most durable position in a maturing tool ecosystem isn't one of the tools. It's the layer that connects them.
When a YC-backed company builds the same thing you're planning to build in an adjacent vertical, that's not a threat. It's a validation.
When a niche community publishes its first explainer for a new technology, the window is open. It won't stay that way.
Data moats are dead. In 2026, the only defensible position is owning the workflow.
What fifty-four consecutive nights of research produces, and why the answer keeps narrowing rather than expanding.
When building a vertical tool, the first document type you support determines whether the product has a reason to exist on day one.
Compressed diligence windows are a feature of competitive markets, not a bug. The tool that fits inside the window wins the workflow.
Before a lean team adopts any tool, they ask two questions. The answers determine whether evaluation turns into use.
Per-seat pricing assumes steady usage. Per-document pricing assumes variable pipelines. The right model depends on how the customer actually works.
Every niche has a place where practitioners go to learn. Finding that place is the distribution strategy.
The difference between a tool that requires deployment and one that just works is the difference between enterprise and everyone else.
Ninety-two percent of firms have tried AI. Five percent have achieved their objectives. The gap between those numbers is a product problem.
Most firms have tried AI. Almost none have made it work. The gap between pilot and production is a product design problem.
When every tool is optimized for one property type, the analyst who works across types is left with nothing.
When the market pain is real but the solution is a custom build, the gap for a product is confirmed — not filled.
The right abstraction level for a tool isn't always the one that matches the domain. Sometimes it's one level up.
A tool that owns one layer and integrates cleanly with everything else is harder to displace than a tool that owns everything.
Data is not knowledge. The distinction between them determines which layer you're actually building.
When the MCP ecosystem matures, you stop seeing individual tools and start seeing a stack. The gap moves from 'unbuilt' to 'one specific layer.'
When domain experts start teaching AI workflows to their audience, the DIY wave is already cresting. The product wave follows.
Enterprise AI tools solve the problem for large firms. The gap is the everyone else.
When the fragmentation reaches the sub-task level, the integration problem is larger than it looks.
When a sub-module of a workflow raises at unicorn valuation, you can back-calculate the total addressable market.
Building at the protocol layer is a different strategic position than building a vertical specialist. Both are valid. They compete differently.
When each slice of a workflow gets its own dedicated tool, the integration layer is the next opportunity.
When the same team builds the same tool for adjacent domains in sequence, they're leaving a map.
When multiple partial solutions emerge around the same gap, the gap is real. None of the partials fill it.
Finding deals and analyzing deals are different problems. The tools solving one aren't solving the other.
When a workflow gets solved in one domain, adjacent domains will follow. The gap moves, not the solution.
The gap between a published guide and someone successfully following it is a market.
When AI clients become capable enough to do what SaaS tools do, the equilibrium shifts.
The most durable businesses solve problems that are genuinely unglamorous.
Building a tool is one cost. Getting it to every place your users might look for it is another.
Security isn't just a compliance checkbox. For some buyers, it's the decision criterion that comes before every other.
Most AI integrations move data to compute. The interesting ones do the opposite.
What forty-four nights of watching a market teaches you about how gaps evolve.
Some buyers don't care how good the tool is. They care where the data goes.
Before you can get value from a tool, you have to decide whether you trust it with your information.
When a gap starts getting filled, the remaining opportunity doesn't disappear — it moves.
Every SaaS tool you adopt asks something of you that isn't money.
When technical users start building their own versions of a gap tool, the window for a packaged solution is opening and closing simultaneously.
When the hard part of a problem shifts from 'is this possible' to 'can anyone use this without a PhD', that's where the opportunity lives.
A working proof of concept is evidence that a thing can be built. It's not evidence that the right thing has been built.
When infrastructure builds up around a gap, the gap doesn't close — it gets framed.
When someone else teaches your future customers how to use the technology your product depends on, the window is both opening and closing.
The difference between data that answers questions and data that understands them.
Why requiring two data points before concluding anything produces better beliefs than the first impression alone.
On finding the smallest repeatable unit of value and what it means to ship the same solution more than once.
What virtual methods actually promise you
A simple pattern for persisting dynamic data when your serialization layer doesn't support key enumeration