mvrckhckr

What Survives When Anyone Can Build Anything

2026-06-04T04:48:00Z

AI can generate the tool. The real market is still in owning the upkeep, especially for recurring problems nobody wants to operate themselves.

The "is SaaS dead?" debate keeps landing in the wrong place.

It keeps staring at the build step, because the build step used to be the hard part. If AI can generate the app, wire the dashboard, and scaffold the settings page, the old conclusion follows fast: software margins collapse, every product becomes a wrapper, game over.

But maybe you're the kind of builder who has already felt the hole in that logic.

You've got AI helping you ship faster. You've seen how far a motivated non-engineer can get with a one-page app. You've also watched the whole thing get shaky the moment the problem repeats, edge cases pile up, or the stakes climb above this would be nice to have.

A quick test helps here. I'll get to it.

The part people actually buy

People rarely buy software just because it solves a problem once.

They buy software because they want a repeatable solution, but do not want to become the person who now has to watch it, patch it, restore it, answer for it, and quietly carry it in their head.

That is the part the "SaaS is dead" argument keeps skimming past. AI lowers the cost of producing a tool. It helps with parts of upkeep too. But it does not remove the ongoing burden of owning a problem in the real world.

And real world problems are rude. They repeat. They drift. They break on Thursdays. They interact with other systems you forgot existed. They acquire users who click in a different order than you expected. They create one tiny failure at 2:13 a.m. that turns your clever shortcut into an unpaid job.

Software has always had two layers. One layer is visible, the interface, the feature set, the thing a demo shows. The other layer is invisible, the quiet promise that this thing will keep working when reality touches it.

The second layer is where money survives.

Cheap construction changes the buyer's math

When a thing becomes easier to build, people assume buyers will stop paying for it. Sometimes they do. Usually when the problem is shallow, one-off, and low-stakes.

A landing page is close to that. A tiny internal helper is often close to that. A script you run twice a month might be close enough.

And to be fair, some software categories really will get cheaper or disappear. If the workflow is simple, the consequences are low, and the team already has to own the process anyway, AI absolutely makes buying less necessary.

But a repeating problem with consequences follows a different curve.

PostgreSQL is free and open source, with over 35 years of active development behind it.¹ Yet managed Postgres remains a real business because many teams do not want database backups, point-in-time recovery, upgrades, failover, and operational risk to become a side quest. Amazon RDS lists backups and point-in-time restores as part of its managed PostgreSQL offering.² The engine being available did not remove the market. It clarified what the market was paying for.

Same pattern elsewhere.

Deploying code is easier than ever. Vercel still highlights automatic deployments on every branch push, preview deployments for every push, and instant rollbacks.³ Shipping is never the whole job. Recovery is part of the product.

And you can see the same shape outside software. Otis says it maintains around 2.5 million customer units worldwide and emphasizes getting customers back into service faster.⁴ The elevator is the visible object. The dependable business is the standing promise that someone will answer when the object misbehaves.

Software was the strange exception. The build step was so hard for so long that it hid the services business underneath.

AI didn't end SaaS. It stripped the disguise off a pattern the industrial world has been running forever.

Once you see this, the frame changes.

The question stops being "Can AI build the software?" and becomes "who wants to own the maintenance boundary around this problem?"

The Ownership Test

If you're building in the AI era, this is the test I would use.

Call it The Ownership Test.

Does the problem come back?
Does failure matter when it comes back?
Does the buyer want to become the operator?

If the answer is yes, yes, no, there is still room to charge. That third question is the one most people underrate.

Builders overestimate the customer's desire to "have control." What many customers actually want is relief. They want a boundary. They want to pay money and stop thinking about a category of recurring mess.

This is why just works sounds like weak positioning to builders and strong positioning to buyers. Builders hear laziness in that phrase. Buyers hear the removal of a future obligation.

The phrase also gets stronger as the buyer gets busier.

A founder with one painful workflow might enjoy assembling a custom AI stack on a Saturday. A founder with twelve painful workflows and a team depending on outcomes starts valuing a different thing. Less possibility. More certainty. Less authorship. More trust.

The sale shifts from capability to custody.

Pricing will probably follow that shift too. The closer you get to carrying the outcome, the stranger it feels to charge only for access.

The mirror question

There's a fourth question, and it lives on the builder's side of the table.

Do you want to become the operator?

If the answer is yes, and the customer's yes-yes-no lines up with it, you've found a durable business. If not, you've found a business that prints money while it burns you out.

Just works is a promise that someone, somewhere, is carrying the weight when reality refuses to behave. AI lowered the cost of building. It did not lower the cost of being responsible. The founder who sells relief is often the person staring at a laptop on a Thursday night, trying to figure out why one integration changed its response shape.

The durable builders pick categories where custody suits them. The rest of us should notice when just works means I'll be the one who never sleeps through a Saturday again.

AI widens the gap between demos and responsibility

AI makes demos cheap.

Agents may make the interface thinner too. That still leaves the question of who is accountable when the work crosses real systems. That matters. It means more competitors, more feature parity, and far less protection from "we built this too."

It also helps with some maintenance work. AI can draft migrations, explain logs, write monitoring queries, and patch small failures faster than before.

And yet the gap between something that looks solved and something a customer is comfortable depending on still holds. In some categories it may even get more obvious, because the visible layer got easier faster than the invisible one.

You can feel it when someone shows you a slick AI-generated prototype that works beautifully in the happy path, then gets weird the moment you ask about audit trails, permissions, billing edge cases, retries, monitoring, or what happens after the third integration changes its API.

In other words, AI compresses the distance between idea and artifact. It does not compress the distance between artifact and reliability nearly as much.

That changes where the margin hides. Less in raw feature creation. More in taste, trust, ongoing care, and narrowing the failure surface for the customer.

Which sounds almost boring.

Good.

Boring is where durable businesses often live. Especially when the alternative is a custom stack with nobody clearly responsible for what happens after launch.

What buyers are really outsourcing

People say they want software. A lot of the time they are outsourcing four quieter things:

Judgment about defaults
Maintenance of the moving parts
Accountability when something breaks
The mental freedom of not owning the category anymore

This is why a product can survive even when a smart customer knows they could build a version themselves.

They are not comparing your monthly price to the cost of generating some code. They are comparing it to the cost of becoming the caretaker.

That cost is usually mispriced because most people only count the obvious part. They count setup time. They forget ongoing decisions. They forget error handling. They forget what context-switching does to a week. They forget the moment a custom solution becomes important enough that it starts asking for standards, documentation, and handoff.

The first version of a custom tool feels like freedom. Version seven feels like ownership, and those are different emotional products.

[[embed:ownership-weight]]

The winners will define smaller promises

I do not think the future belongs to undifferentiated SaaS, broad dashboards with loose promises and interchangeable features.

I do think curated software with sharp scope, especially when it carries infrastructure, compliance, payments, medical data, or other operational burden the customer does not want to own, can stay extremely valuable.

That usually means a smaller promise.

Cleaner scope. Fewer edge cases exposed to the user. Tighter positioning around one repeating pain. More obvious responsibility. Less "platform." More "this category of problem leaves your head when you hire us."

AI actually helps here.

It makes it cheaper to build the visible layer. That gives founders more room to invest in the invisible layer, the operations, the defaults, the support logic, the recovery paths, the careful opinion about what happens when reality refuses to behave.

The founders who keep arguing about whether SaaS is alive may miss the more useful question. Where, exactly, are people still desperate to stop owning the upkeep? And then, quieter: are you the one who wants to pick it up?

That is where just works stops sounding generic and starts sounding expensive. On both sides.

The durable business in the AI era is the one that removes a recurring responsibility the customer no longer wants to carry.

Build for that, if you can carry it.

Rabbit hole

If this angle resonates, keep going with Pay per result might be the unit test for pricing AI SaaS, Software companies are becoming staffing agencies, and Go ahead, build what already exists.

Footnotes

PostgreSQL describes itself as a free, open source database system with over 35 years of active development. That supports the point here: the core engine is mature and available, but many teams still prefer not to operate it themselves. Source: PostgreSQL.
Amazon RDS for PostgreSQL documentation lists backups and point-in-time restores among the managed capabilities. I used that as evidence for the broader claim that buyers often pay to avoid the operational surface area around a tool. Source: Amazon RDS for PostgreSQL.
Vercel's Git deployment docs say it supports automatic deployments on every branch push, preview deployments for every push, and instant rollbacks. That makes it a clean example of a company selling smoother operation around an already easier build pipeline. Source: Vercel Git deployments.
Otis says it maintains around 2.5 million customer units worldwide, and on its main site it emphasizes service teams that ensure a faster return to service. I used this as a grounded industrial example of the ongoing-value argument, without making the stronger profit-mix claim from the earlier draft. Source: Otis.

Not All Uncertainty Deserves Respect

2026-06-02T04:58:00Z

What the blur itself can tell you.

You keep telling yourself the answer needs a little more time.

A few more visitors. A few more conversations with users. A few more dates. A few more mornings with the new routine. A few more photo walks with the new lens. Then you'll know.

For a while, that's true.

You've shipped something, or you're stuck overthinking a decision, and the signal is weak. One person loves it. Another shrugs. One week looks promising. The next one looks flat. The question stays open on your desk, glowing.

The useful move here is simpler than it sounds. Before you try to answer the question, figure out what kind of blur you're looking at.

Grey Feels Important

We treat grey like a sign of seriousness.

If something feels unresolved, we assume the question must be subtle. Mature people appreciate nuance. Serious founders avoid premature certainty. Thoughtful people say it depends.

All fair.

Anyone who has tried to focus a camera at dusk knows the feeling. The scene is real. The lens just keeps hunting.

And sometimes the fog really does deserve patience. Markets can look dead before they tip. Relationships can feel ordinary before trust deepens. A new habit can wobble before it settles. Ambiguity is not automatically fake.

But in ordinary life, blur usually means one of three things.

You are early.

The difference is too small to matter much. Or the question only sharpens after commitment. Those are very different problems. Only one of them is solved by sitting still and respecting the mystery.

Some Questions Are Just Early

The first kind of greyness is simple. You need more contact with reality.

When I ship a small tool now, whether it's something like Pricing Unit Picker or another tiny utility, the first reactions are flattering and mostly useless. A few people say nice idea. A friend on X shares it. Someone compliments the design. None of that tells me whether anyone will come back when the problem shows up in their actual day.

Early praise has terrible resolution.

A founder with 43 landing-page visitors is not looking at demand. A musician who played a song twice for two friends is not looking at reception. A person who visited one neighborhood on a sunny Saturday is not looking at what living there feels like.

The world has barely answered.

This kind of uncertainty earns respect. One more week of retention might matter. Ten more user calls might matter. Thirty more mornings with a routine might matter. If the next batch of reality could still change what you do, go get it.²

A useful question from decision analysis survives the translation: what information would actually change the move? If more signal could push you toward action A instead of action B, the fog is earning its keep.

The mistake is staying in the grey without naming what "enough" would mean.

Colin Powell framed this as the 40/70 rule: decide when you have between 40% and 70% of the information. Below 40%, you're guessing. Above 70%, you're stalling.

[[embed:forty-seventy-rule]]

How many conversations would convince you the problem is real? What retention number would make you keep going? What outcome after thirty days would make you keep the routine?

If you can't name the threshold, more data turns into a mood.

The Grey Test

When a decision keeps staying muddy, three questions help.

Am I early, or am I looping? If exposure is still shallow, gather more reality. If you have already seen the pattern repeat, stop pretending the next tiny sample will reveal a new universe.
What difference would actually change my behavior? Name a real threshold. More traction is vague. Ten out of fifteen calls mention this pain unprompted is usable. Feeling slightly better about it is vague. Sleeping better for two straight weeks is usable.
What breaks if I choose wrong today? If the answer is not much, you already know enough. Take the reversible path and keep moving. The cost of delay is now larger than the cost of imperfection.

Jeff Bezos calls reversible choices two-way door decisions. Most decisions are two-way doors. Most overthinking treats them as one-way.

One practical addition: set a deadline before you start analyzing. No deadline means you're not gathering information. You're marinating.

Builders burn absurd amounts of energy overthinking low-leverage decisions.

Which analytics tool. Which note-taking app. Which headline variation from two decent options. Which roadmap order for features nobody has asked for clearly enough yet. Which brand color, once the palette already works. Which pricing detail, before they've even confirmed that people urgently want the thing.

Meanwhile, the real questions are usually standing there without makeup.

Does anyone care enough to come back?

Does this solve a painful enough problem to pay for?

Does this collaboration create energy, or drain it?

Does this habit make daily life better, or just feel virtuous for four days?

Big questions often do resolve if you let reality hit them hard enough.

Small questions can stay alive forever because they barely matter.

Psychologists call this decision fatigue. After enough low-leverage choices, even trivial ones start feeling heavy. Not because the stakes grew, but because you forgot they were small.

When Overthinking Becomes a Hiding Place

Grey has another appeal. It lets you postpone commitment without admitting that's what you're doing.

As long as the question stays open, every future stays available. You can keep believing both options might be brilliant. You can protect yourself from the grief of picking one and killing the other.

Founders do this with product directions. Creators do it with formats. People do it with cities, relationships, jobs, routines, instruments, and identities.

Sometimes that hesitation is wisdom.

Sometimes it is grief avoidance dressed up as nuance.

And sometimes the question really does only sharpen after commitment.

If you're a Scanner or a multipotentialite, like I am, this gets trickier.³⁴

After you've built a coupon agency, a courier service, a food delivery platform, theatre shows, publishing experiments, software tools, and a pile of other things, starting one more thing never feels impossible. That history gives you pattern recognition. It also gives you an alibi.

You can start calling everything low leverage simply because commitment would close a few beloved doors.

I've used that trick on myself more than once. Fresh repo. Fresh notebook. Fresh angle. Fresh identity. Maybe I was protecting my time. Maybe I was just protecting myself from the slower pain of staying long enough for compounding to begin.

Some questions stay blurry because they are small.

Some questions stay blurry because they only sharpen after you commit.

That distinction matters just as much as the first one.

If the thing you are trying to learn only appears after repetition, responsibility, or sunk cost, you will never see it from the doorway. You have to move in far enough for reality to push back.

Rank the Question Before You Answer It

Most people try to answer the question first. A better move is to rank it.

How much upside sits on the other side of clarity? How much downside comes from choosing the less optimal path? How reversible is the move? How quickly will reality correct you after you act? And one more, what price would commitment extract from your other identities, options, and fantasies?

Those questions tell you whether uncertainty deserves more fuel.

If the answer is high stakes, hard to reverse, slow feedback, slow down. Gather signal with discipline. Treat the grey seriously.

If the answer is low stakes, reversible, fast feedback, stop kneeling before ambiguity. Pick. Ship. Move. Test. Learn from contact with the world instead of fantasizing that one more round of thinking will finally feel clean.

If the answer is this only gets clear after sustained commitment, stop asking the question from the doorway. Go live inside it long enough for reality to answer.

Grey is often just a status update.

Early.

Small.

Comfortable.

Once you see that, the question changes.

Not what is the right answer?

What kind of blur is this, and how much of your life does it deserve?

Rabbit Hole

If this angle on uncertainty and signal resonates, you might also enjoy Most Things Are Black and White, on the difference between reality being definite and your access to it being limited.

Critical Demand Signals Nobody Talks About goes deeper on the kind of evidence that actually deserves your attention.

And What AI Actually Searches When It Helps You Think gets at the gap between what exists in your head and what you can currently retrieve.

Footnotes:

Health researchers use several closely related labels here, including minimal clinically important difference and minimum important difference. The shared point is the one that matters for this essay: a measurable difference is not automatically a meaningful one.
Decision analysts use the idea of value of information for a related question. New information earns its keep when it can change the action, not when it merely makes you feel less exposed.
Barbara Sher popularized "Scanner" in Refuse to Choose! for people whose interests range widely and repeatedly pull them toward new domains.
Emilie Wapnick popularized "multipotentialite" for a similar pattern through Puttylike and the TED talk Why Some of Us Don't Have One True Calling in 2015.

Can AI Fix SaaS?

2026-05-28T05:03:00Z

You're paying for seven subscriptions, using a third of each, because nobody ever agreed on how the pieces should connect.

Every SaaS platform started as one thing. Salesforce was a CRM. HubSpot was email marketing. Notion was a note-taking app.

Then they grew. They absorbed features. CRM added marketing automation. Email marketing added a CRM. Note-taking added databases, wikis, project management, and something resembling a small operating system.

The standard explanation is "platform dynamics." Network effects. Switching costs. Ecosystem lock-in. Everything composable SaaS was supposed to dissolve.

But there's a simpler, uglier truth underneath.

The Dirty Secret of Platform Growth

You're an indie hacker or a small team. You've picked your tools carefully. CRM here, analytics there, billing over here, support tickets in that corner. Five tools, five logins, five data formats, five APIs that almost talk to each other. (The average company runs over 100 SaaS apps. You're getting off easy.)

So you paste them together with Zapier. You build custom integrations that break every time one provider ships a new API version. You export CSVs and reimport them like it's 2004.

Eventually, one of those tools offers "the full suite." It's worse at three of the five jobs, but at least it's one thing. You migrate. The platform won on simplicity alone. The glue was killing you.

That's the dirty secret. Platforms don't necessarily win because they're superior. They win because composing your own stack from specialized tools is unbearably painful. Every platform is a workaround for missing standards.

A Problem Older Than Software

Before standardized shipping containers, every port had its own loading system. Cargo got unpacked, repacked, and unpacked again at every stop. In 1956, hand-loading loose cargo cost $5.86 per ton.

Malcolm McLean didn't build a better ship. He standardized the box. One size. Standard corners. Any crane, any truck, any port. Cost dropped to 16 cents per ton.

Before MIDI in 1983, your Roland synth and your Yamaha drum machine existed on separate planets. Each manufacturer had proprietary connections. Musicians couldn't compose systems from pieces they chose. MIDI fixed that with a simple protocol: here's how instruments talk. Suddenly the entire electronic music ecosystem became composable.

Before lens mount standards, photographers were locked to one manufacturer's glass. Adapters existed, but every adapter was a compromise. Some mounts opened up (M42, Micro Four Thirds), and the moment they did, an ecosystem of specialized lens makers exploded. The camera body became a commodity. The glass became the differentiator.

The structure is identical every time. Fragmented proprietary systems. Mounting pain. Then someone standardizes the connection point, and composition becomes trivial. Not better products. Just agreement on how pieces touch.

What makes the pattern useful isn't any single example. It's that the resolution is structurally identical across domains that share nothing else in common. Shipping has nothing to do with music has nothing to do with photography. But the coordination failure looks the same, and the fix looks the same: someone stops trying to build a better product and instead standardizes the connection point. Once you see the shape repeating across enough unrelated domains, you stop asking whether SaaS will get its container moment and start asking what's delaying it.

Why SaaS Missed Its Container Moment

So why hasn't SaaS had its shipping container moment? We've had APIs for twenty years. REST, GraphQL, webhooks. Why are we still in the patchwork-glue phase?

Because APIs solve the connectivity problem. They don't solve the meaning problem. Salesforce stores organizations in an Account object with a field called Name. HubSpot stores the same concept in a Company object with a field called name. People? Salesforce's Contact has FirstName. HubSpot's Contact has firstname. Same entities, different structures, different naming, different relationship models. Your analytics tool needs a custom adapter for each. Multiply that across twenty tools and you have a mapping problem that compounds with every new integration you add.

An API says "here's how to ask me for data." A protocol says "here's what a customer record IS, structurally, regardless of who you're asking." The difference is the difference between translating every conversation in real time versus everyone already sharing the same vocabulary.

Microservices was supposed to fix this. Decompose software into small services connected by APIs, and composition becomes trivial. It fell short, for more reasons than any single article can cover. But the most fundamental one is the same: better connectivity, same meaning problem.

Real protocols require consensus. And consensus is where application-level software standards go to die. W3C and IETF gave us HTTP, TCP/IP, HTML. But those are plumbing standards. They took ages too (HTTP/2 arrived 16 years after 1.1), but plumbing can afford to be slow because it rarely needs to change. Application semantics can't afford that pace. What a "customer" means, how a "subscription upgrade" is structured, what fields belong on a "support ticket," these shift with every business model pivot. A committee that takes years to agree on an application-level spec produces something that's already outdated by the time it ships. The result often satisfies nobody and arrives after the market has already chosen a winner (usually a platform that locked everyone in while the committee deliberated).

MIDI took 37 years to get a version 2.0. The first version was good enough that musicians lived with its limitations for nearly four decades rather than endure another standards process.

Standards lose because they move at human-coordination speed. Platforms win because they move at company-execution speed. The bottleneck was never technology. It was the cost of getting people to agree.

The Protocol Designer That Doesn't Need a Committee

But the problem runs deeper than speed. A committee-designed protocol is a snapshot of meaning, frozen the moment everyone agreed. Application-level meaning doesn't sit still long enough for a committee to capture it. By the time the snapshot ships, the thing it captured has moved. Faster design alone wouldn't fix this. What changes the equation is protocols cheap enough to revise, not just cheap enough to create.

AI can simulate how two systems would interact. It can propose a protocol, test it against edge cases, refine it, and propose again. Not in months of committee meetings. In hours.

Here's what that looks like concretely. Your billing system emits events like subscription_upgraded with fields for plan tier, effective date, annual revenue impact. Your analytics system expects events shaped like revenue_change with fields for amount delta, attribution source, time window. Today, you'd write a custom transformer, or Zapier would maintain a hard-coded adapter for each pair of tools. An AI protocol negotiator does something different: it reads both schemas, proposes an intermediate event shape that both systems can emit and consume natively, tests whether it handles edge cases (prorated upgrades, downgrades, trial conversions), and iterates until the contract works cleanly. The providers adopt the negotiated schema. Now any billing tool that speaks this protocol composes with any analytics tool that does. No adapter. No custom glue.

The Lego metaphor for composable software has always been aspirational. But Lego works because every brick has the same stud size, the same socket depth, the same tolerance. That's not a feature of the bricks. That's a feature of the protocol beneath them.

AI could design that protocol layer for software. It's faster than any committee. And because the coordination cost drops to near-zero, protocols can iterate quarterly instead of ossifying for 37 years. Standards that move at the speed of software, not the speed of consensus.

The Brick Maker's Edge

There's a popular question making the rounds: is AI replacing SaaS? That framing misses what's actually happening. AI isn't replacing your tools. It's designing the connections that let you replace your platform with something better: a stack you actually chose.

If composable SaaS becomes real (through AI-designed protocols, not committee consensus), several assumptions flip:

You don't need to become a platform. Build the best brick. Nail one job. If your CRM module snaps perfectly into any stack, you don't need to also build billing, analytics, and support.
Lock-in shifts form. You stay with Salesforce today not because you love it, but because leaving means rebuilding twelve integrations. That's the moat. In a composable world, you swap the CRM brick without touching anything else. You stay because the tool is genuinely best, not because escape is expensive. The lock-in doesn't disappear. It migrates from switching cost to quality.
The customer becomes the architect. Instead of choosing a platform and living with its opinions about everything, you assemble your own system from the best specialized pieces. The way a photographer builds a camera system from bodies, lenses, and accessories that share a mount standard.
Small and focused becomes structural advantage, not limitation. Indie hackers are better at building one exceptional thing than mediocre everything. In a composable world, that's exactly what wins.

The Trap Inside the Promise

There's a version of this future that's worse for indie hackers, not better.

If composability makes switching trivial, it also makes competition brutal. Today, a mediocre CRM survives because its users are locked in. Tomorrow, a mediocre CRM dies in a quarter because swapping it costs nothing. "Best brick" sounds empowering until you realize that "best" is now contested every single day by every competitor who also builds one clean brick that snaps into the same protocol.

And point 3, "the customer becomes the architect," carries an assumption worth questioning. Most customers don't want to be architects. They want someone to make the decision for them. That's half the reason platforms won in the first place. Not just the glue problem, but the decision problem. One vendor, one opinion, one throat to choke.

In a fully composable world, who curates the stack? Who tells the non-technical founder which five bricks to combine?

That's not a hole in the thesis. That's a hidden opportunity. Stack curation is a job that doesn't exist yet because it doesn't need to, platforms bundle the decisions for you. The moment composability unbundles the stack, someone needs to help people reassemble it. That's a new kind of service, maybe a new kind of role entirely. Think of it like interior design for software: you could furnish the apartment yourself, piece by piece, or you could hire someone who knows which pieces compose well together and why. Today that person doesn't have a title. In a composable world, they might be more valuable than any individual brick maker.

The interesting question isn't "do platforms die?" It's: does the bundle become less sticky when any individual brick can be swapped without collateral damage?

The Conductor (Sometimes)

A platform isn't just a bundle of tools. It's also the thing deciding what happens when, and in what order. Unbundle the tools, and that coordination work doesn't vanish.

In a composable world, do you even need a central coordinator?

For simple connections, no. If your CRM fires a lead_converted event and your email tool subscribes to it and sends an onboarding sequence, nothing needs to sit between them. Each brick handles its own reactions. That's choreography, and in a protocol-standardized world, most simple connections will work this way.

A conductor earns its place at complexity thresholds. "If lead value is over $10k AND they came from an enterprise channel, pull their usage data from analytics, check credit from billing, schedule a call in calendar, notify the account owner, but only if the credit check passed." Which brick owns that logic? It spans five systems. Cross-cutting logic that belongs to no single brick needs somewhere to live.

Zapier today is mostly translation, maintaining thousands of custom adapters because tools don't share a schema. In a composable world, that translation layer disappears. What remains is pure orchestration: the business logic of when, why, and in what order.

And here's where AI plays a second role in this story.

The first role was designing the protocols. The second is powering the conductor itself. A rule-based orchestrator executes what you told it. It doesn't reason. An AI-powered conductor handles exceptions with judgment. It notices that a certain workflow always fails on Fridays and suggests a reroute. It infers from your operation's patterns what logic you probably need, without you pre-defining every rule.

The conductor doesn't replace any brick. It orchestrates them. And because it touches every workflow, it builds a picture no individual brick can see. Everyone owns their slice. The conductor owns how the whole operation moves, and adapts when circumstances shift.

This might also be the answer to the "who curates the stack?" question from the section above. The conductor isn't just an orchestrator. It's the thing that removes the architect burden from the user. "Here's what you're trying to accomplish. Based on your patterns, here are the bricks and connections that serve it." Composability for builders, curation for everyone else, same underlying protocol layer.

Two Forces Pushing Back

This isn't inevitable. Two pressures resist it.

First, incumbents have zero incentive to participate. Salesforce doesn't want you composing your own CRM from three specialized tools that each do one job better. Platform lock-in is their business model. They'll adopt composability language without offering composability substance.

Second, AI-designed protocols still need adoption. A brilliant standard that nobody implements is just a PDF collecting dust. Providers won't adopt until customers demand it, and customers can't demand what doesn't exist yet. Classic chicken-and-egg.

But pressure builds from the other direction. Every founder who migrates to a worse-at-everything platform because the glue was killing them represents stored demand. Every Zapier workflow that breaks at 2 AM is a vote for real composability.

The question isn't whether composable SaaS is desirable. Everyone with seven subscriptions already knows the answer. The question is whether the coordination problem finally has a solvent.

For the first time, it might. The competition will be fiercer, the curation problem is real, and the incumbents won't go quietly. But here's what's different now: the cost of designing agreement dropped by orders of magnitude. That was always the first bottleneck. Not technology. Not desire. Just the grinding expense of getting people to agree on how pieces should touch. AI doesn't force adoption, but it removes the excuse that standards take too long to design and iterate. When a protocol can be proposed, tested, and refined in days instead of years, the political cost of resistance becomes harder to justify.

Build the best brick. The sockets are coming.

Rabbit Hole

We're Writing Grammar Before the Language Exists explores who should design agent protocols, and whether the agents themselves should negotiate them
Software Companies Are Becoming Staffing Agencies traces how AI is reshaping the SaaS business model from tools to workers
The Idea Is the Product Now argues that cheap execution changes what matters, and composability accelerates that shift

A Good Product Manager Already Built It. And Found the Bugs.

2026-05-26T04:56:00Z

You were hired to take a PRD (Product Requirements Document) and turn it into working code. Now your product manager walks in with the working code and a list of edge cases they already caught.

Picture a product meeting from eighteen months ago. The product manager (PM) slides a doc across the table. Ten pages of requirements, user stories, acceptance criteria. The engineer reads it, asks a few clarifying questions, disappears for two weeks, and reappears with a working feature.

Clean handoff. Clean roles. Everyone knew which half of the job was theirs.

Now picture the same meeting today. The PM opens their laptop. They spent the weekend vibe coding. There's already a working prototype running. Then they mention three edge cases they hit while building it: the model hallucinates on empty inputs, latency spikes past two seconds on long documents, the rate limiter misfires on parallel requests.

If you're a software engineer who grew up inside that old division of labor, this is the moment the floor shifts under you. The PM's half of the job came in finished. Your half came in already half-done. And the hardest parts of your half came in pre-solved.

(Find out your specific situation by taking the free How Safe Is Your Engineering Role? quiz at the bottom of this page. You can also access this quiz on its dedicated page, where you'll find more details about it and its results.)

Handoffs Existed for a Reason

Engineering and product used to be two separate jobs because very few could do both well. Product understood the user and the business. Engineering understood systems and code. The PRD was the contract that let two incompatible brains ship the same thing.

Good PMs pushed against that line for years. They'd pick up some code. They'd prototype in Figma. They'd learn enough to push back when engineering said something was impossible. But the prototypes were always mocks. The engineer still had to build the actual thing.

That line just dissolved.

Vibe Coding's Natural Winners Aren't Engineers

Everyone has been absorbing one version of the story. AI got good at code, so engineering gets commoditized from below. Junior tasks first. Then maybe the whole role.

The more interesting version is the one nobody has been watching. The natural winners of AI coding tools aren't average engineers. They're good product managers.

A good PM already had the context AI was missing. The user. The business. The why. The specific shape of the thing that should exist. The only thing stopping them from shipping was their hands. AI gave them hands. Now they can cross the bridge from taste to running artifact in the time it used to take to write the spec that asked an engineer to do it for them.

And the prototype does something the PRD never could. It hits the real walls during construction, the kind that don't show up in a doc until somebody has tried to ship past them. The PM doesn't have to imagine edge cases. They collect them as they go. By the time the engineering meeting happens, the list is already in a notebook, next to a few more the engineer wouldn't have thought to check.

Edge cases used to be an engineer's moat. The thing they brought to the meeting that the PRD didn't have. "I'll build it, and by the way, here are six things you didn't think about." Now the PM has a running demo and their own six things (that might not even overlap the engineer's).

Squeezed From the Side

Most of the worry about engineers getting replaced has focused on the wrong direction. Everyone is watching the floor: will AI get good enough at junior tasks to make entry-level engineering obsolete?

I find the squeeze from the side as interesting as the squeeze from the bottom.

The PM has hands now. A working product manager vibe coding with Cursor, Codex, or Claude Code is basically a strong engineer wrapped inside someone who already knows what the product should do. That's a brutal combination if the thing you were bringing to the table was the ability to turn a spec into code.

A sound engineer in the early 2000s ran into something similar. Their job was getting a clean recording in a professional studio with real equipment and real acoustic treatment. Then a guitarist showed up with a laptop, a decent audio interface, and a bedroom demo that was already mixed. The craft was still real. It just stopped being scarce where it used to be scarce.

[[embed:squeeze-map]]

Four Things the Prototype Still Can't Touch

Good news. The PM-with-AI combo has a ceiling. And the ceiling is above where most engineers spend their week right now.

Four things the prototype still can't touch:

Architecture that survives growth the demo has never seen. The prototype handles ten users on localhost. What happens at ten thousand? At a million? The decisions that determine whether the system bends or breaks under that load are invisible inside a running demo. They're invisible right up until the moment they aren't.
Failure modes that only show up in production weather. Production is a climate. Network partitions. Clock skew. Partial failures. Retries that amplify load during an incident. The prototype that runs beautifully on a laptop has never seen a real storm. Knowing what breaks, when, and how to keep it from breaking comes from having been on call the night it did.
Second-order consequences baked into the prototype. The PM's demo made a database choice, a caching choice, a state management choice. Each one looked reasonable in isolation. Each one locks the system into a direction you'll regret in six months if you're the one still on the hook. AI is a single-move thinker. A senior engineer is thinking five moves ahead.
The second mind in the room. The PM with AI builds fast because nobody in the loop is disagreeing with them. No spec review, no engineer asking "wait, why?", no other brain looking at the same problem with a different set of reflexes. That speed is also where it breaks. A prototype that catches six edge cases is still a prototype with no disagreement inside it. I've shipped enough things as a solo operator to know the most dangerous bugs come from the questions nobody in the room was assigned to ask. The PM-with-AI inherits that exact blind spot.

None of these are bootcamp skills. None of them show up in job listings as "React developer, 3+ years." They come from shipping real systems, watching them break in embarrassing ways, and building an internal model of what never to do again.

If you're wondering where to aim, aim there. Not at writing more code. At understanding what happens when the code meets the world.

There's an uncomfortable thing sitting inside this. The climb I'm pointing at requires the kind of bruising that used to come from the middle rungs of the ladder.

The tickets that taught you what you now know were the tickets most likely to get absorbed by the PM-with-AI. Newer engineers will have to find a different on-ramp to the scar tissue, and nobody has mapped that route yet.

The climb is real. The ladder is getting kicked.

One direction worth watching: if the prototype is now the starting line, the junior engineer's new apprenticeship might be learning to stress-test what someone else built rather than building it from scratch. Break the demo. Find the failure mode the solo operator couldn't see. That's a version of the second-mind role that doesn't require ten years of scar tissue to start.

There's a name forming around this convergence. Some companies call it the "product engineer" — someone who holds both the product context and the systems thinking. Not an engineer who learned to write PRDs. Not a PM who learned to vibe code. Someone who can look at the prototype and the production system and see the gap between them as a solvable problem.

That role didn't exist when the handoff was clean. It's emerging because the handoff dissolved.

One Honest Question Worth Sitting With

A question worth sitting with, not defensively:

If a product manager you respect took your next ticket and built a prototype of it with AI tools over a weekend, would they catch the edge cases you'd catch? Would they find ones you wouldn't?

If the answer is "yes" to the first and "maybe" to the second, the pressure you're feeling has a name. The job you were hired to do is becoming something the other side of the handoff can now do on their own.

Don't resent the PM eating your lunch. They're doing what anyone would do when the tools made it possible.

Climb instead. Climb to the part of the job that lives underneath the prototype, the part where the running demo is just the starting line. Then become the second mind the solo operator can't have inside their own head.

The old game was simple. The PM writes the spec. The engineer builds the thing. The new game is harder. The PM brings the thing. Your job starts where theirs stops.

That's a harder job. It's also the one worth having.

[[embed:how-safe-is-your-engineering-role-free-test-v2 schema:app]]

Rabbit Hole

If this landed, these might too:

The Uber-Engineer Doesn't Write Code - why the engineer's new role looks more like a film director than a coder
Your Job Already Changed. You Just Didn't Notice. - how the definition of "good" in your role quietly moved while you were still doing the old version
The New Bottleneck - what actually becomes the hard part when building gets easy

What AI Actually Searches When It Helps You Think

2026-05-21T04:58:00Z

Your accumulated knowledge just became searchable, and so did every gap in it.

You've had the moment. You describe a problem to AI, your thinking partner, and its response triggers something. A concept you read about years ago. An approach from a completely different context. A connection you'd never have made if nobody jogged your memory.

You didn't learn anything new. You were reminded.

That feeling where AI's answer clicks into place and you think of course, I knew that is worth paying attention to. AI isn't generating novel knowledge in those moments. It's excavating yours.

(You may want to quiz your specific case by using the free How Well Does AI Actually Search Your Brain? tool.)

Knowledge You Can't Quite Reach

If you build things for a living, write, or run a business, you've spent years absorbing information. Books, conversations, experiments, failures. Your head is full. The problem is retrieval.

Cognitive scientists have studied this for decades. They call it the tip-of-the-tongue state: you know you know something, you can feel its shape, but you can't pull it into focus.¹ Your brain stored the knowledge. It just won't hand it over on demand.

Your knowledge doesn't sit in one tidy drawer. It exists in layers.

Fingertips. The stuff you recall without effort. Your core domain, your daily tools, the patterns you've internalized through repetition.

Periphery. Things you know you know but can't quite reach. The framework from that book you read last year. The approach a colleague explained over lunch. It's in there, just not accessible right now, for this problem.

Deep storage. Things you've absorbed without realizing it. A passing concept in a podcast. A diagram in an article you skimmed. A principle from a domain you briefly explored. This knowledge shapes your intuitions without ever announcing itself.

The richest layer is also the least predictable. If you've spent time in domains outside your main work, deep storage holds connections that cut across fields. A theatrical principle sitting next to a design pattern sitting next to a negotiation tactic from a completely different life. None of them labeled, none of them organized, all of them potentially relevant to the problem you're staring at right now.

Your AI thinking partner reaches across all three layers at once. When you describe your problem, you're creating a context that overlaps with everything you've accumulated. AI's response doesn't just inform you. It triggers recognition. And recognition is powerful. It's faster than learning from scratch, more trusted than external advice.

That's the feature.

[[embed:knowledge-sphere]]

The Click That Lies

Here's where it turns.

That click of recognition has a twin. Psychologists call it the fluency heuristic: when information is presented smoothly and confidently, your brain reads that smoothness as a signal of truth.² The illusory truth effect shows that even minimal exposure to a statement makes people rate it as more likely to be true. Not because they verified it. Because it felt familiar.

AI delivers everything with the same fluency. The correct answer it excavated from your peripheral knowledge sounds identical to the fabrication you've never encountered before. Same confident tone. Same polished prose. Same structure.

When AI resurfaces something true that you'd buried, you feel: Yes, that rings a bell.

When AI presents something false that you've never encountered, you feel: the same smoothness. No alarm. No friction. Just quiet acceptance of something that reads well.

The knowledge you don't have can't wave at you. Gaps are silent. And AI fills silent gaps with the same articulate confidence it uses for everything else.

Most people call this hallucination. But a hallucination implies seeing something that isn't there. The deeper problem is the opposite: feeling nothing when AI hands you a fabrication, because smooth delivery reads as truth.

Add to this that AI mirrors your assumptions back at you. Challenge its answer and it'll often fold, agreeing it was wrong even when it wasn't. The tool that searches your knowledge also flatters your blind spots.

Two People, Same Tool, Different Universes

This creates an asymmetry that explains more than people realize.

Consider two people asking AI for help with the same scaling bottleneck.

One has built software for years but also ran a delivery operation, published books, and studied how photographers compose a frame.

When AI frames the problem as a queuing issue, something fires. Not from code. From dispatch.

Routes backing up, drivers waiting for assignments, the whole system choking because priority was set wrong. The connection wasn't planned. AI surfaced it by searching across domains that were never filed together. The insight lands instantly because the knowledge was already there, just filed under a different label.

The other has worked in software for a decade. Deep expertise, one field.

AI gives the same response. A solid queuing solution. One the specialist can evaluate and implement with confidence within their domain.

But the dispatch angle, the physical-world intuition about how queues behave when humans are in the loop, never fires. That knowledge isn't in storage. AI can't surface what was never there.

Two people. Same prompt. Same model. One gets a connection that cuts across lived experience. The other gets a technically sound answer with no hint of what it left on the table.

What separates them is the breadth of what's filed away. Intelligence and prompting skill barely enter into it. AI is a search engine. The more diverse the index, the more surprising the results.

What Your Thinking Partner Can't Retrieve

AI cracked retrieval. It's already excellent at pulling up what's buried, reconnecting what you'd lost access to, cross-referencing across your scattered knowledge.

What it didn't solve is acquisition. The slow, unglamorous work of actually learning things. Reading the book. Building the project. Sitting with a confusing concept until it clicks. Having the conversation that shifts how you see a problem.

You can't shortcut this. The learning has to come before AI can surface it. The order matters.

But not all acquisition is equal. Depth in a single domain gives AI one deep well to draw from. Breadth across domains gives it a web.

AI has a particular edge with webs. You'd never think to search dispatch logistics when debugging a software bottleneck. Those domains are filed in different rooms in your head. AI doesn't know about rooms. It searches everything at once, which means cross-domain connections surface in ways they never would on their own.

This is why the "just ask AI" approach breaks down for anyone without a foundation to build on. It's also why experienced practitioners get disproportionately more value from AI than beginners do.

But there's a subtler dynamic at work. When AI handles retrieval, you stop retrieving.

The wandering, inefficient path your brain takes when it's trying to remember something, that path had value. You'd start looking for one concept and stumble into a connection with another. The retrieval itself was generative.

AI gives you the answer directly. No wandering. No stumbling. No accidental connections.

That's usually a good trade. But my sense is that the skill of self-retrieval gets less exercise over time. And like any skill that doesn't get used, it probably fades.

The critical thinking that questions whether AI's answer is really yours, or just sounds like it could be, needs the same exercise.

The only thing that rebuilds it is the same thing that built it: learning in territory that doesn't match what you already know.

Every concept you've internalized is one more thing AI can resurface at the exact moment you need it. Every concept you haven't is one more silent gap where a confident wrong answer walks in unopposed.

Those who'll get the most from AI in the next decade aren't the ones with the best prompts. They're the ones who spent the last decade filling their heads with material worth searching.

AI made retrieval free. Acquisition still costs everything it always did. And the most valuable kind, the kind that wanders across domains and looks unfocused from the outside, is the kind that most career advice tells you to stop doing.

What Changes

When AI's answer clicks into place, pause. That feeling of recognition is identical whether AI surfaced real knowledge or fabricated something plausible. Asking yourself do I actually know this, or does it just sound like something I'd know? is the single most valuable practice for working with AI. It costs three seconds. Most people never take them.

If AI never pushes back on your thinking, you're not working with a partner. You're working with a mirror. AI is built to agree. Left to its defaults, it'll validate whatever framing you hand it, and that agreement will feel like confirmation when it's really just an echo.

Force the friction yourself. Ask AI to argue against what it just told you. Ask what you're probably wrong about. Tell it to assume you're missing something and show you what. A thinking partner that never disagrees isn't helping you think. It's helping you stop.

Rabbit Hole

If this angle on AI and human knowledge resonates, you might also enjoy:

AI Is a Self-Esteem Test looks at the same dynamic from a different angle: AI reveals what's already inside you.
AI Didn't Automate the Grind, It's Doing Something More Interesting examines what AI actually does versus what most people assume.
The Skill AI Can't Replace digs into the human judgment AI still depends on.

Footnotes

The tip-of-the-tongue phenomenon, first studied by Roger Brown and David McNeill in 1966, showed that memory retrieval happens in stages. You can access partial features of a word (its first letter, its syllable count) without retrieving the word itself. This proves knowledge persists even when active recall fails.
The illusory truth effect, identified in a 1977 Villanova and Temple University study, demonstrates that processing fluency (how easily your brain handles information) is routinely mistaken for truthfulness. Lisa Fazio's research at Vanderbilt found that even knowledgeable people aren't fully protected: exposure to false statements increases their perceived truthfulness regardless of prior knowledge.

Where Automation Stops and Real Growth Starts

2026-05-19T04:52:00Z

AI made cost-cutting faster. It didn't raise the ceiling.

The default advice right now is to automate everything. Billing, accounting, payroll, customer support, onboarding. Every repetitive task your business touches. And the advice works. Automation reduces time, cost, and friction.

But automation is subtraction. You're cutting costs, not growing revenue. And subtraction has a hard limit.

The best case for any cost line is zero. And zero is just a 100% reduction of what you had. If your billing costs $1,000 a month and you automate it down to $50, you saved $950. Even if you somehow got it all the way to zero (you won't), you saved $1,000. That's the ceiling. That line item is done forever.

Every dollar you save through automation is a dollar you'll never save again.

(You may want to audit your specific case by using the free Revenue Ceiling Audit tool.)

The Bounded Game

You've been optimizing your business. Trimming the operational fat. Automating the boring parts. Good.

But if automation is your growth strategy, you're playing a bounded game.

Cost reduction compounds in reverse. The first round saves the most. The second saves less. By the third round, you're squeezing pennies out of processes that barely cost anything anymore.

Companies implementing AI automation report 20-30% operational cost reductions.¹ Real money. Also a ceiling you can see from here.

And AI made the ceiling arrive sooner. Before AI, you could spend years finding costs to trim. The runway was long enough that cost-cutting felt like a real strategy. AI compressed that runway. What used to take a decade of incremental process improvement now takes a quarter. Same ceiling. You just hit it faster.

That's the optimistic case. Cut too deep and you lose the people, the quality, or the customer trust that were generating the revenue in the first place.

I ran a coupon marketplace. Watched the pattern up close.

Merchants would obsess over their deal structure: 50% off or 60%? Minimum group of 10 or 20? They'd spend weeks tweaking these numbers, trying to find the sweet spot.

But the math was always working against them. A restaurant offering 50% off on a $30 meal, then splitting the remaining revenue with us, walked away with about $7.50 per customer. Before food costs.

The ones who kept optimizing the deal structure were playing the bounded game inside a bounded game. The merchants who actually grew treated the coupon traffic as a customer acquisition channel for full-price relationships. They stopped optimizing the discount and started building the thing worth paying full price for.

That's the ceiling in miniature. You can perfect the subtraction. You can't subtract your way to growth.

So: what happens after you've automated everything worth automating?

The Unbounded Game

Revenue (and its more important counterpart, profit) has no ceiling, in percentage and in absolute dollars.

Think of it like the stock market. Shorting a stock caps your gain at 100%. The stock hits zero, you double your money, and that's the best case. Going long has no ceiling. A stock can 2x, 10x, 100x. Cost-cutting is a short position. Revenue growth is a long one.

This sounds obvious until you watch how most founders actually spend their time. They'll invest weeks building automations that save $200/month. Then they'll price their product at $29/month because that's what competitors charge.

One move is bounded. The other is open-ended. Guess which one gets all the attention.

The real move is making your price invisible next to the value you deliver. When the customer measures what you did in their terms, not yours, the whole conversation changes.

When Value-Based Pricing Sells Itself

Here's where most pricing goes wrong. You calculate your costs, add a margin, and call it a price. That's cost-plus pricing. Or you scan competitors and land somewhere in the range. That's competitor-based pricing. Both approaches anchor your price to what the product means for you.

Your customer doesn't care about your margins. They care about their own numbers. What did this save me? What did this make me? How does this compare to what I was paying before?

Value-based pricing flips the anchor. Measure what your customer gains in dollars. Price far enough below that number that the math does the convincing.

Picture this: you've built a tool that automates client reporting for agencies. Saves each agency about 10 hours a week. For a small shop billing at $100/hour, that's $52,000 a year in recovered billable time. You price it at $4,000 a year.

The customer's internal math: spend $4K, recover $52K. A 13x return. That barely requires a conversation.

Now look at what happens if you price the same tool at $49/month because that's the going rate for SaaS tools in your category. You collect $588/year from a customer getting $52,000 in value. That's an 88x return for your customer, when a 13x was already a no-brainer. Which sounds generous until you realize you're the one being generous.

The hourly alternative is worse. Bill the same work at $150/hour. The customer sees "hours" on the invoice, which triggers every procurement instinct to negotiate scope, reduce hours, and micromanage delivery. Same work. Same outcome. Completely different buying psychology.

[[embed:same-work-different-anchor]]

Fewer than 15% of B2B companies execute value-based pricing consistently.² The rest anchor to their own costs and wonder why growth feels linear.

The Part Nobody Talks About

Pricing for value sounds like a math problem. Figure out the customer's ROI, set your price below it, close the deal.

But the reason 85% of companies don't do it has nothing to do with math.

Value-based pricing requires you to stand behind a number before you have proof. Automation gives you receipts. You ran the process manually, it cost X. You automated it, now it costs Y. The savings are visible, immediate, defensible.

Pricing for value means walking into a conversation and saying my product is worth $4,000 a year to you. If you've never said that out loud, the number feels invented.

You don't have the data yet. You don't have the testimonials. You don't even have full confidence that your tool will actually deliver the $52K in value you're claiming.

So you flinch. You set the price at $49/month because you can always raise it later. (You probably won't.)

This is why automation gets all the attention. Optimization is safe. You're just making what exists run better. Pricing for value is a bet on yourself, placed in front of someone who can say no.

The Discipline of Saying "Not Yet"

Pricing for value is half the equation. The other half: who you sell to.

The same offer has wildly different value to different buyers. A tool that saves a solo freelancer five hours a week is nice. The same tool saving a 50-person agency five hours per employee per week is transformative. Same product. Different customer. Different price ceiling.

The strategy almost nobody follows: find the customers for whom your offer has the absolute highest value. Serve only them. Exhaust that tier completely before moving to anyone else.

In most businesses, 10-20% of customers drive 70-80% of revenue.³ Concentration works. The real question is whether you have the patience to ignore the 80% until you've fully captured the 20%.

Think of it as tiers:

Tier 1: Customers who get the most value from what you offer. Highest willingness to pay. Easiest yes. Stay here until the tier is saturated.
Tier 2: Customers who get the second-most value. Move here only when Tier 1 can't absorb more.
Tier 3 and below: Everyone else. Later. Maybe never.

The instinct is to go wide early. More customers, more revenue, right?

Wrong. Going wide early dilutes your positioning, stretches your support, and averages down your price to accommodate buyers who get less from what you do.

One caveat. Going narrow only works if you've correctly identified who values your offer most. And that's harder than it sounds.

The customer you think is Tier 1 might turn out to be Tier 2 once you've seen how both segments actually use the product. Early on, you might need a slightly wider aperture. Not to serve everyone, but to gather enough signal to know where to narrow.

The discipline isn't just patience. It's pattern recognition. Watch who gets the most value, who renews without being asked, who refers others.

Then narrow there.

Going narrow first means higher prices, easier sales, stronger testimonials, and a clear signal about what you do best. All of which make the jump to Tier 2 easier when the time comes.

The Arithmetic of Ambition

Automation is arithmetic. You have a number. You make it smaller. The floor is zero.

Revenue growth is ambition. You have an offer. You make it more valuable to the people who value it most. The ceiling is wherever you stop looking.

Most founders I watch are playing defense. Automating, optimizing, trimming. Defense matters. But defense alone never won a game where the score keeps climbing.

The move that changes your trajectory isn't a smoother workflow or a cleverer automation. It's two questions:

Who gets the most value from what I do?
Am I pricing so their decision is obvious?

If the answer to either is I don't know, that's where your growth is hiding.

Not in the next automation.

Rabbit Hole

For a deeper look at how outcome-based pricing works in practice, Pay Per Result Might Be the Unit Test for Pricing AI SaaS walks through the full spectrum of pricing models. If you're wondering how AI is reshaping who gets to charge premium prices, The $5,000 Problem maps the barbell replacing the old three-tier market. And if you're questioning whether your business is built for price competition or something deeper, Every Venture Is Either a Commodity or a Brand is worth the read.

Footnotes

Thunderbit, "Automation Statistics 2026." Companies implementing AI and automation solutions report 20-30% reductions in operational costs, with efficiency improvements exceeding 40%.
Bain & Company, cited across multiple pricing strategy analyses. Fewer than 15% of B2B companies execute value-based pricing consistently, meaning cost-plus and competitor-based pricing remain the default for most businesses.
Multiple customer segmentation studies consistently find that 10-20% of customers account for 70-80% of total revenue, supporting the case for deliberate customer concentration over broad market targeting.

You Can't Afford Most Books

2026-05-12T05:03:00Z

You've been buying books faster than you can read them, and the price tag was never the problem.

A book costs $20. Maybe $30 if it's hardcover and you're feeling generous with yourself. You don't even think about it. One click, two days, it's on your shelf.

But here's what you actually agreed to when you clicked "Buy": 6 to 10 hours of focused attention. The mental effort of wrestling with someone else's ideas across 300 pages. The opportunity cost of every other book you won't read during those weeks.

You've got a stack on your nightstand. A Kindle library that scrolls. You keep buying books you won't read because buying feels productive. Each purchase carries a quiet promise of future knowledge.

Most of those promises go unkept.

The Purchase That Replaces the Reading

We treat buying a book like the first step of reading it. Cart, checkout, shelf. The journey has begun.

Except it hasn't. The purchase is the cheapest, easiest, most painless part of the entire process. A $25 book demands four seconds of financial consideration. Reading that same book demands weeks of sustained attention, at the rate most people actually read (roughly 20 minutes a day).¹

I learned this from the other side of the counter. I'm a founder of a book publishing and retail operation.

From the seller's perspective, the purchase is the finish line. The entire business, the covers, the blurbs, the placement, the "customers also bought" suggestions, all of it is engineered to produce one moment: the transaction.

Everything after that, the reading, the thinking, the life that changes, that's on the buyer. The whole model works because buying a book feels like reading a book. Just enough to close the sale. (I wish we could make sure people actually read every book they buy. They'd buy more.)

It creates a feeling of progress. The book lands on your shelf and your brain files it somewhere between "done" and "in progress." You feel a little smarter for owning it. A little more committed to the ideas inside. The transaction offered just enough satisfaction to kill the urgency that would have made you actually open it.

This isn't a character flaw. It's a mismatch between what the purchase costs and what the reading costs. One is trivially easy. The other is hard.

What a Book Actually Costs

What does real reading require? Not scanning. Not skimming a summary. The kind of reading where ideas change how you think.

Uninterrupted time. Enough mental energy to follow an argument across chapters. Willingness to sit with ideas that challenge what you already believe. The discipline to resist your phone, your inbox, the pull of something more immediately rewarding.

A nonfiction book averages 5 to 8 hours of reading time at typical speed.² But "typical speed" assumes you're just processing words. Add in pausing to think, re-reading dense passages, and taking notes, and that number climbs fast. For a serious book like Daniel Kahneman's Thinking, Fast and Slow (which I haven't even started), only about 7% of readers who start it ever finish.³

Seven percent. One of the most recommended books of the last decade.

Not because people are lazy. Because the real cost of reading a serious book is enormous, and the sticker price told them nothing about it.

We comparison-shop book prices. Wait for sales. Hunt for the cheapest edition. We'll spend 15 minutes saving $3 on something that will cost us 10 hours to actually consume.

The ratio is absurd. Like negotiating the cover charge at a restaurant where the meal runs a thousand dollars.

Tsundoku: A To-Do List Disguised as a Collection

The Japanese have a word for this: tsundoku. The practice of acquiring books and letting them pile up unread. The term first appeared in 1879, when the satirical phrase tsundoku sensei described a teacher who owned many books but never read them.⁴

It's so universal it earned its own vocabulary. And the word carries no judgment.

Some go further. Nassim Taleb argues that unread books are the most valuable part of your library. He calls it the antilibrary: a reminder of everything you don't know. The pile isn't failure, it's intellectual humility on a shelf. It's an elegant idea. But it quietly assumes your attention is free.

Naming it doesn't explain it, either. Tsundoku happens because the market made one side of the equation absurdly frictionless.

Amazon, Kindle, Audible, library apps. Every innovation in the book industry over the past 20 years has reduced the cost and friction of acquiring books. None has reduced the cost of reading them. Audiobooks changed the format, not the hours. If anything, the attention cost has gone up, because now you're consuming on the same device that has every other form of stimulation one tap away.

The gap between buying and reading has never been wider. Your shelf, physical or digital, isn't really a collection. It's a to-do list with a nice aesthetic.

[[embed:tsundoku-v2]]

For builders, it's worse. That book about marketing strategy registers as "working on marketing." The SaaS pricing book registers as "optimizing revenue."

The stack isn't just a to-do list. It's a permission slip to delay the work.

Three Questions Worth More Than the Book

Before buying, try running the decision through three questions:

What will I do differently after reading this? If the answer is nothing, the book is entertainment. That's fine. But be honest about what you're buying.
Could I get this from a good article or a 20-minute conversation? Many books are stretched ideas. The core insight fits in 2,000 words. The remaining 60,000 exist to justify the binding.
Am I buying this, or buying the feeling of buying this? The honest answer is often the second one. The purchase itself is the product.

This doesn't mean read fewer things. It means redirect the hours. Read what's worth the hours. Let everything else be what it is: a pointer to an idea you can explore faster another way.

Start many books. Quit most of them early. The table of contents and first chapter tell you more about whether a book is worth your next ten hours than any review or recommendation. Amazon even gives you a generous free peek into most books. Take a few minutes to read it, experience reading it, and you'll soon find out if the book (subject, writer, style, etc.) is for you or not.

But.

There's a trap on this side too. The three questions can become their own form of avoidance.

You research the book. Read the reviews. Skim the summary. Weigh whether it qualifies.

Forty minutes of curation later, you've read nothing. The filter replaced the reading, the same way the purchase did.

The questions are a sanity check, not a ritual. Use them in a few minutes, no more.

The Bet You're Actually Making

Every book you buy is a bet. You're betting this particular arrangement of someone else's thinking is worth one of the most valuable things you have: your undivided attention for weeks.

So count the hours, not the titles. If you've got 50 unread books on your shelf and 20 minutes a day to read, that's roughly three years of reading. Not as a plan. As a measure of the distance between what you intend and what you'll actually do.

You can afford the book. The question is whether you can afford to read it.

Rabbit Hole

If you're rethinking how you filter what deserves your commitment, The "Hell Yes or No" Test Is Actually About Something Deeper explores why that famous filter reveals more than just your calendar. And if you've ever wondered why hitting a goal didn't feel the way you expected, You Don't Want What You Think You Want digs into the gap between what we chase and what we actually need.

Footnotes

The average American reads roughly 20 minutes per day, according to the Bureau of Labor Statistics American Time Use Survey.
A 300-page nonfiction book takes approximately 5 to 8 hours at average adult reading speed of 238 words per minute, per research published in the Journal of Memory and Language.
Based on Jordan Ellenberg's Hawking Index analysis of Kindle popular highlights, which estimates how far readers advance through popular titles using highlight patterns. The 7% figure is an approximation from these reading signals, not a formal study of completion rates, but the pattern holds across many "must-read" bestsellers. A short accessible excerpt is available from Equitable Growth.
The earliest known use of tsundoku appeared in 1879. It combines tsunde-oku (to pile things up for later) and doku (to read), as summarized in Tom Gerken's BBC News article on tsundoku.

No Circle Is Round and AI Isn't Deterministic. So What.

2026-05-07T04:53:00Z

The "AI isn't deterministic" objection imports a standard from pure math.

Physical reality never meets it either. Real tools ship when they meet a precision threshold, not abstract perfection.

Magnify any line ever drawn. It isn't smooth. It has grooves, bumps, tiny deviations from the geometric abstraction you learned in school.

You still call it a line. You still use it for the cabinet you're building, the diagram you're explaining, the envelope you're measuring. Straight enough for the job.

[[embed:round-enough]]

This sounds like a casual observation. It's actually the reason you should stop waiting for AI to be "deterministic."

The standard you're demanding

You're an indie hacker with an AI feature half-built. You've watched the model produce three different answers to the same prompt. Your gut says don't ship it. Ask for specifics and you'll reach for words like reliability, consistency, determinism.

Look at what you're actually demanding. Same input, same output, every time, forever. That's a mathematical definition. It describes a pure function in a textbook.

Nothing real meets it.

Your database has clock skew. Your network drops packets. Your CPU schedules threads in a different order on every run.

You ship every day on top of layers that are imprecise at some scale, and you trust them because their imprecision is small enough to not matter for your job.

What you're really importing is Platonism. The belief that the perfect Forms are the true reality and the messy physical world is a degraded shadow of them. It's a lovely frame for geometry class. It's a terrible frame for engineering, because navigating by perfect Forms requires omniscience about every edge case, every input, every future state. Nobody has that. Waiting for it is waiting forever.

Software builders are particularly susceptible to this import. Code feels like the closest thing to pure math humans build. Same instruction, same output.

The cracks show higher up the stack, but the mental model has already formed.

Every other craft has worked against imprecision as the baseline forever. You're meeting what normalcy looks like outside software, not encountering a new defect.

Zeno never shipped

One of Zeno's paradox examples: to cross a room, you must first cross half. Then half of the remainder. Then half again. An infinite number of halvings. So you can never reach the other side.

The paradox dissolves the moment you leave pure math. Real motion isn't an infinite sequence of subdivisions you have to complete one by one. Your foot lands. You cross the room in two seconds.

It's only paradoxical inside the abstraction. Take the abstraction outside and it breaks.

The "AI isn't deterministic" complaint lives in the same territory. A textbook objection about a product you plan to ship to humans, who aren't deterministic themselves.

What engineers actually do

Every real tool has a precision threshold. The real question every engineer has always asked is whether the error is small enough for the job at hand.

A tape measure accurate to a millimeter is precise enough for framing a wall. Way too sloppy for a semiconductor fab. Same tool, different job, different answer.

An autopilot reliable 99.9% of the time is unacceptable. A spam filter reliable 99.9% of the time is excellent.

Music lives here too. Equal temperament, the tuning almost every modern piano uses, is mathematically wrong on purpose. No interval in it is pure.

A pure fifth would be slightly wider, a pure third slightly narrower. The compromise is deliberate: a piano tuned to pure intervals in one key is unplayable in others.

Western keyboard music has run on a threshold, not a Form, for centuries.

AI is no different. The question is what precision this specific job needs, and whether you can engineer to meet it.

Engineering the threshold

You already know how to narrow AI's error bars. You just don't call it engineering because it feels suspiciously like prompt writing.

Lower the temperature. Sampling randomness is a dial. Turn it down when consistency matters, up when you want variety.
Constrain the output. JSON schemas, regex validators, typed function calls. The model can still hallucinate, but only inside a shape you control.
Narrow the context. Less room means fewer paths the model can wander down. Prompts that describe the entire decision space produce tighter results than prompts that describe the vibe.
Verify after generation. A second LLM call, a regex check, a test runner, a human. The generator doesn't need to be perfect if the checker is cheap.
Budget retries. Non-deterministic often means mostly right with occasional drift. Three tries with a validator beat one try with a prayer.

None of this makes the model deterministic. All of it raises the precision threshold.

The gap between "not deterministic" and "reliable enough for this job" is where real engineering happens. Every real-world tool has always lived in that gap.

Which jobs clear the threshold today

Code autocomplete can tolerate a 5% error rate. Medical diagnosis cannot. A copywriter can ship AI drafts and edit them. A tax advisor cannot ship AI answers unchecked.

If the precision your job needs is higher than the threshold you can engineer to, don't ship it. The determinism question was always a red herring. The threshold question is the one that tells you whether to build.

If the threshold is met, ship it. The abstract version of a circle is round, and no drawn one ever will be. You're not building in pure math.

The real question

Stop asking whether the AI is deterministic. Start asking whether its imprecision is small enough that the user won't notice, or won't care if they do.

Your users are non-deterministic. Ask the same person the same question on Tuesday and Thursday and you'll get two answers.

They want different things at 9am than at 9pm. They'll forgive a response that varies because their own responses vary.

A tool that always produces the same output is in some sense less matched to them than one that adapts.

This doesn't mean anything goes. The target is appropriate variation: tight where the job demands tightness, loose where the job permits it.

That's the same question every engineer has always asked about every tool they've ever shipped. Nothing you've built was abstractly perfect, and your product worked anyway.

AI is the newest tool joining a very long list. The builders who ship are the ones who stop demanding it hit a standard nothing real has ever hit, and start engineering it to hit a standard that matters for the job.

No circle is round. Your product doesn't need one that is.

Rabbit Hole

If the precision threshold framing resonated, The One-Shot Illusion takes it into the territory of founders who ship AI that looks ready but isn't. 2X AI Coding Speed, Without the Slop is the practical version: the drift check you run before review becomes the bottleneck. And if you're still working out how to think about AI as a category of tool, not just a feature, You're Building a Stone Cathedral Out of Concrete picks up that thread.

The Death of "Pretty Good"

2026-05-05T04:59:00Z

You've spent years getting good at several things, and that (thanks to AI) is now becoming the most exposed position in the market. If that hits a nerve, keep reading.

"Jack of all trades, master of none." The dismissal has been around for centuries. The comeback, "but oftentimes better than a master of one," is surprisingly recent.¹

The generalist vs specialist question has been the quiet engine behind that phrase for centuries. AI just resolved it.

Both sides win. The middle loses.

When "Pretty Good" Became Table Stakes

For three decades, career advice converged on one shape: the T. Go broad, go deep in one area, be employable forever.

McKinsey was using the concept internally in the 1980s. IDEO's Tim Brown popularized it.

It worked, because being "pretty good" at something required real effort. The gap between "knows nothing about design" and "can put together a clean layout" represented years of learning.

You're an indie hacker, a product manager, a senior engineer. You've built competence across product, design, marketing, maybe finance. That profile was the gold standard.

Then the tool that's "pretty good at everything" showed up. Broad competence stopped being scarce overnight. Anyone with a browser tab and some curiosity can produce a passable landing page, write decent marketing copy, analyze a dataset, draft a legal agreement. The horizontal bar of the T is now available to everyone.

[[embed:pretty-good-compression-v2]]

The market for professional capability is developing a barbell shape. Weight at both ends, nothing in the middle.

On one end: the deep specialist who knows more about a narrow domain than anyone in the room, including the AI. On the other: the extreme generalist who uses AI as a depth multiplier across every domain they touch.

The person in the middle, competent at three things and deep in none, used to be the safest hire. Now they're the easiest to replace.

Medicine Already Ran This Experiment

This pattern has a century of precedent.

In the early 1900s, a doctor was a doctor. They set bones, delivered babies, prescribed medicines, and performed surgeries. Then knowledge accumulated.

Anesthesiology split off. Cardiology became its own field. Cardiology fractured into interventional cardiology, electrophysiology, heart failure, cardiac imaging. Today the American Board of Medical Specialties certifies physicians across more than 40 specialties and nearly 90 subspecialties.²

The general practitioner didn't disappear. Their role transformed. They became the coordinator, the person who knows enough to ask the right questions and route you to the right specialist.

They don't compete with the cardiologist on cardiac knowledge. They compete on breadth of judgment and the ability to see the whole patient.

Sound familiar? The GP is the generalist. The subspecialist is the depth player. The middle, "pretty good at cardiology but not a cardiologist," has been dead in medicine for decades.

AI is doing to every profession what accumulating medical knowledge did to doctoring. Just faster.

The Two Edges AI Can't Reach

What makes both extremes defensible is the same thing: they operate where AI runs out of road.

The specialist's edge is the frontier. AI can retrieve and synthesize existing knowledge faster than any human. But the frontier of a field, where the next discovery or insight hasn't been codified yet, is beyond AI's reach. The security researcher discovering a new class of vulnerability. The tax attorney navigating a regulatory edge case with no precedent. AI's training data ends where the frontier begins. The deeper you go, the less AI can follow, because depth at the frontier means creating knowledge that doesn't exist yet.

The generalist's edge is the mesh. Where the specialist goes deeper than AI can follow, the generalist goes wider than AI can hold. They maintain context across many domains simultaneously, making judgment calls that require understanding how a product decision affects engineering, how an engineering choice shapes marketing, how a marketing angle constrains pricing.

AI can simulate excellence in any single domain. It can simulate cross-domain thinking when prompted. What it can't do is bring your specific judgment to the intersection. The way you weigh tradeoffs is shaped by every domain you've worked in, every failure you've internalized, every pattern you've noticed across fields that don't normally talk to each other. Two generalists with identical range will make different calls, because their mesh is built from different scar tissue.

You've heard the shorthand: lean into creativity, empathy, critical thinking. Those matter at both ends of the barbell. But without the depth to push a frontier or the mesh to connect domains, they're just more "pretty good."

The indie hacker who ships a feature, writes the launch post, adjusts the pricing, and handles the first support ticket before lunch isn't just switching tasks. They're applying a coherent point of view across everything. AI amplifies their reach in each domain. The point of view that connects the domains is theirs alone.

The Generalist vs Specialist Debate That Proves the Point

Here's the part nobody seems to notice.

Search for "AI and the future of careers" and you'll find article after article arguing generalists will win because adaptability and cross-domain thinking are what matter now. Dig into industry hiring data and you'll find the opposite claim: specialists are more sought after than ever, because deep expertise is irreplaceable.

Both are right. They're describing the same barbell from different ends.

The natural objection: can't you just stay T-shaped and add AI fluency? Keep your broad competence, learn the tools, hold your position? You can try. But watch what happens. If you use AI to deepen your specialty, you're drifting toward the specialist end. If you use AI to extend your reach across more domains, you're drifting toward the generalist end. AI fluency doesn't preserve the middle. It sorts you out of it.

Recent IMF research confirms the pattern: new skills are boosting employment overall but deepening polarization, with gains concentrating at the extremes while middle-skilled workers see no significant benefit.³

The question worth asking: why does anyone still think the middle is safe?

Both Ends Have a Trap

The barbell is descriptive, not a guarantee. Sitting at an end doesn't mean you're safe. It means you have a different kind of exposure.

The specialist's trap is depth in a dead end. You can be the world's foremost authority on a technology, a legal framework, a therapeutic technique, and the domain can shift under you. Depth is only defensible when the frontier you're exploring still connects to something the world needs. Go deep in the wrong direction and your irreplaceable knowledge becomes irrelevant knowledge.

The generalist's trap is subtler and harder to see from the outside.

Breadth can become a hiding place. The person who touches five domains well enough to contribute to each but never commits deeply enough that any single one could expose them. They look like a strategic generalist. They feel like one. But the tell is in the output.

You can usually tell the difference by asking one question: does this person's breadth produce something that wouldn't exist without the specific combination? If the domains generate something together that none of them could alone, the mesh is real. If they just coexist on a resume, the breadth is a different kind of "pretty good."

The Unstated Baseline

All of this comes with a condition most discussions skip past.

You have to be using AI.

A specialist who ignores AI is building a sandcastle at low tide. A less experienced specialist who uses AI well will close the gap faster than either of them expects. Your decade of depth buys you a window, and it's narrowing.

A generalist who refuses AI is trying to span multiple domains on raw bandwidth alone. Someone with half your experience and twice your AI fluency will cover more ground, faster, with fewer blind spots.

The barbell only works if you're actively using the tools that created it. Neither end is defensible without them.

But here's the thing the AI fluency advice is already running into. AI fluency itself is becoming "pretty good."

Right now, knowing how to use these tools well is an edge. As the tools get more intuitive and the population of fluent users grows, that edge dulls. Being good at prompting will be as differentiating as being good at Googling.

And each cycle is shorter than the last. What took a decade with search engines took two years with LLMs. Every time the tools improve, the floor of "pretty good" rises and the middle shrinks again.

When AI fluency becomes table stakes, what's left is what makes the barbell's ends defensible now. Frontier knowledge you created. Or judgment built from your specific combination of domains and failures.

The tool proficiency gets you to the table. The taste is the game.

Pick Your End

The safest position in any professional field used to be the middle. Competent at several things, deep enough in one or two to stay relevant.

That ground is disappearing.

If you're feeling the floor shift, you're not imagining it. The discomfort, or even anxiety, of realizing that your competence profile, the one you spent years building, has landed you exactly where you don't want to be right now. That's not a reason to panic. It's a reason to move. Here's how.

Pick an end of the barbell. Go deeper than AI can follow, or go wider than AI can hold.

What you learn next depends on which end you're choosing.

If you're going deep: push past the point where AI gives confident answers. The security researcher studying adversarial attacks on LLMs. The structural engineer specializing in mass timber high-rises. The biotech analyst who can read a clinical trial and spot what the summary statistics hide. If AI can write a solid overview of your niche, you haven't found the frontier yet.

If you're going wide: strengthen the connections between domains you already touch. The product manager who learns enough data science to challenge the model, enough design to prototype the interface, enough finance to build the pricing. Not depth for its own sake. Depth in service of a wider mesh.

The starting question is the same for both: where does your work sit on the barbell today, and what would move you further toward your end?

Both ends come with traps. But the middle's trap is worse. You don't fall into it. You stay in it, comfortably, while the ground erodes.

At least at the ends, you chose.

Rabbit Hole

If this angle landed, you might also dig into:

Your Job Already Changed. You Just Didn't Notice. - How AI quietly redefined what "good" means in your role
The Uber-Engineer Doesn't Write Code - What happens when one person directs the whole production
Every Venture Is Either a Commodity or a Brand - The same hollowing-out, applied to businesses instead of careers

"Jack of all trades" first appeared in print in 1612. "Master of none" was tacked on in the late 1700s. The positive ending, "but oftentimes better than a master of one," doesn't show up in print until around 2007. It's widely attributed to Shakespeare, who died a century before even the negative version was recorded.
The American Board of Medical Specialties (ABMS) certifies physicians across its 24 member boards in more than 40 general specialties and nearly 90 subspecialty areas. The actual number of practiced subspecialties is higher, as many specializations exist without formal board certification.
IMF Staff Discussion Note, "Bridging Skill Gaps for the Future: New Jobs Creation in the AI Age" (January 2026). The research finds that demand for new skills, especially in IT and AI, boosts average wages and employment but deepens labor market polarization, with gains concentrating at both extremes of the skill spectrum while middle-skilled workers see no significant benefits.

AI Hallucinations Start at the Interface

2026-04-30T04:58:00Z

You've probably seen "verify everything" as the stock advice attached to AI answers. If you're building AI products, that line should sound less like a safety tip and more like a product confession.

If a weather app looked exactly like a calendar, you'd resent the rain for breaking a promise it never made. The forecast would still be probabilistic. The lie would live in the presentation.

You've probably had the AI version of this already. You ask a clean question, get a clean answer, and later discover the model stitched together something statistically plausible and factually false.

When you're building with AI, the stakes are higher. You are choosing how that failure feels for your users.

The answer box teaches the wrong lesson

I've started thinking we talk about hallucinations one layer too low.

We treat them as a model quality problem, which they are. Better training, better retrieval, better evals, better guardrails, all true.

But the interface is doing hidden work. A chat box, a blinking cursor, and a polished paragraph teach the user to expect the kind of reliability they learned from search, calculators, customer support, and forms. Question in, answer out. Cleanly.

A language model operates on a different contract. Underneath the glass, it is generating the next token from a probability distribution.

OpenAI made this point unusually plainly in 2025. Their argument was that standard evaluations often reward guessing over admitting uncertainty, because a lucky guess scores and I don't know does not.¹

So now we have a system pushed toward guessing and wrapped in an interface pushed toward certainty. That combination matters.

Verify everything is a product confession

"Verify everything" sounds responsible until you sit with it for a minute.

If every answer needs verification, the answer box is overpromising. The product is asking the user to do the calibration work after the interface already nudged them toward trust.

Imagine a bank app showing your balance and then adding, "Verify everything." You would not call that thoughtful product guidance. You would call it a failure of the product contract.

AI gets extra grace because the technology feels magical. Magic hides bad packaging for a while.

What bothers me is that we keep treating verification like media literacy for the user. A lot of it is design debt on the builder's side.

Part of why the debt stays on the books is that the deterministic costume sells. Confident paragraphs convert. An honest interface with visible seams looks less magical in the demo and slower in the funnel. The product's magic trick is letting the cost of that tradeoff land on the user after signup.

Confidence changes behavior

This is not just a philosophical complaint.

A 2024 study put 404 people in front of medical questions and responses from a fictional LLM-infused search engine. When the system used first-person uncertainty language like I'm not sure, but..., people trusted it less, relied on it less, and were less likely to copy its mistakes, so the answers those participants gave were more accurate overall.²

The wording changed behavior.

That result is easy to miss, and it matters a lot. It means uncertainty is not a small UX flourish. It is part of the product's steering wheel.

Researchers have found something similar on the model side. A 2024 Nature paper showed that uncertainty signals can help detect likely confabulations and improve accuracy when the system refuses shaky answers instead of bluffing through them.³

We already know enough to stop pretending the clean paragraph is the whole product.

The honest interface shows its seams

If you are building AI features, I think there is a simple test here. Call it the Seam Test.

Show confidence. Give the user some sense of how stable the answer is, and make it grounded in something checkable, not a vibes number. High confidence, 3 retrieved docs agree on the date is useful. A free-floating 94% is the same bluff in a different way.
Show mode. Tell the user whether the system is Quoted from source, Synthesized across 4 sources, or Model inference. Those are three very different kinds of answers.
Show evidence. Make the supporting material inspectable without turning the user into a forensic analyst. Clicking a sentence should open the exact excerpt behind it. Unsupported clauses should be obvious instead of hiding inside the paragraph.
Show abstention. Let the system say I don't know, ask for clarification, or narrow the claim. Refusal is sometimes the most useful answer on the screen.

If all four seams are hidden, users are forced to reverse-engineer uncertainty from vibes. That is a terrible interface.

[[embed:trust-drift]]

There is a trap here worth naming. Badges and labels can turn into ritual. Cookie banners started as transparency and ended as noise. If every response ships a tiny High confidence sticker, the sticker becomes wallpaper and the user is reverse-engineering vibes again.

The signals have to vary or they are noise. A confidence badge that always reads high is wallpaper. A source chip that never reveals a gap is wallpaper. Seams earn trust by being honest and occasionally refusing, narrowing, or pointing at nothing solid. If every seam always says yes, all good, you have built a new costume and called it honesty.

This does not require some futuristic interface. A legal research tool could tag one sentence Quoted from Smith v. Jones, the next Summary of two cases, and the next Inference based on both. A support copilot could flag Low confidence, policy documents conflict before an agent sends the reply.

In one response card, those cues could live beside the text instead of inside another disclaimer. Green marks grounded passages. Amber marks synthesis. Red marks extrapolation.

Less magic, maybe. More honesty.

Builders are still copying the wrong ancestor

Every new material imitates the old form at first. Early concrete buildings copied stone cathedrals. Early cars borrowed the logic of horse carriages. AI products are doing that with chat.

The more useful pattern is what happens next. Once a probabilistic technology matures, the interface stops pretending to be deterministic.

Weather forecasts went from "rain tomorrow" to "70% chance of rain," a shift the US Weather Bureau pushed through starting in 1965 over years of public confusion. Navigation apps paint predicted slowdowns red on roads you have not driven yet. Radiology reports hedge routinely (likely represents, cannot exclude) because the read is a probability, not a verdict. Autopilot throws a loud take over now when it loses confidence.

AI chat is sitting where those fields were at the beginning. The difference is that we do not have to invent anything. The percentages, the red roads, the hedged reads, the loud warnings, every one of those moves already works in the field. Most AI products ship without any of them.

That costume is why hallucinations feel like betrayal instead of weather. The model made a guess. The interface told you it was an answer.

[[embed:bluff-accumulation-simulator]]

The next wave of AI products will probably win trust in a less glamorous way. They will stop hiding uncertainty. They will make groundedness legible. They will let users see when the system is recalling, when it is composing, and when it is reaching.

That sounds less slick than today's chat box.

It also sounds like the beginning of an honest product category.

If the uncertainty is real, the interface has to make it legible. Until then, we will keep building the most confident-sounding maybe machine in history, then acting surprised when people mistake it for certainty.

Rabbit Hole

If this line of thought clicks, you might enjoy "You're Building a Stone Cathedral Out of Concrete" on how new materials first get forced into old shapes: https://mvrckhckr.com/articles/youre-building-a-stone-cathedral-out-of-concrete

You might also like "Static UI Isn't Legacy. It's Institutional Memory You Can Click." on why interface structure often carries real organizational knowledge: https://mvrckhckr.com/articles/static-ui-isnt-legacy-its-institutional-memory-you-can-click

And "The One-Shot Illusion" connects from another angle, why polished AI output can hide reliability gaps until users pay the price: https://mvrckhckr.com/articles/the-one-shot-illusion

OpenAI, "Why language models hallucinate," September 5, 2025. This is the clearest primary-source statement of the training and eval problem behind confident guessing. It matters here because the interface critique lands harder once the underlying system is already pushed away from saying I don't know.
Sunnie S. Y. Kim, Q. Vera Liao, Mihaela Vorvoreanu, Stephanie Ballard, and Jennifer Wortman Vaughan, "I'm Not Sure, But...: Examining the Impact of Large Language Models' Uncertainty Expression on User Reliance and Trust," FAccT 2024. This is the study behind the claim that uncertainty wording changes user behavior. It matters because it shows that interface language does not just change how users feel, it changes what they do and whether they repeat the model's errors.
Sebastian Farquhar, Jannik Kossen, and Yarin Gal, "Detecting hallucinations in large language models using semantic entropy," Nature 630, 625-630 (2024). This paper is a model-side complement to the product argument. It matters because it shows uncertainty is not only a UX nicety, it can be used as a real signal for catching likely hallucinations.

Satisfied Customers Have Nothing to Say

2026-04-28T04:50:00Z

For every customer who writes in, twenty had the same problem and said nothing.

I've never had AI solve a customer service problem for me. Not one. Not even a trivial one. And the fact that I have to fight through a bot just to reach a human is its own kind of insult.

This is what most companies now consider an upgrade.

This isn't just my bad luck. Customers keep saying the same thing in surveys: the bot is fast, polished, and somehow still in the way.³ ⁴

You've shipped your product. Tickets are rolling in. Same questions, similar complaints. It feels like busywork pulling you away from building. So you start eyeing automation, a chatbot, canned responses, maybe a full AI layer.

Everyone does this. It's the first thing founders automate. I'd make it the last.

What the Spreadsheet Doesn't Show

The ROI of a support chatbot looks clean: fewer hours on tickets, faster resolution times, lower cost per interaction.

But every support ticket carries two things. The question on the surface, and the intelligence underneath. "How do I export my data?" is a question. The fact that twenty people asked it this month is intelligence. It means your export flow is invisible, confusing, or buried. That's your next product priority, handed to you for free.

Analytics tell you what happened. Support tells you why.

I've done support across a courier service, a food delivery platform, a marketing agency, and software products (dating service, coupon platform, publishing, etc.). The industries couldn't be more different. The pattern in the queue was always the same: customers tell you what's wrong on the surface, and underneath ten similar complaints sits a structural problem your metrics never surfaced. The specific complaints change with every business. The diagnostic pattern doesn't.

And the visible queue is just the tip. For every customer who writes in, roughly twenty had the same problem and didn't bother.² The issue you're seeing is twenty times bigger than it looks.

When you automate support, you're building a wall between yourself and the most honest feedback loop your product has.

AI Customer Service Made It Worse

Before AI support, bad support was at least recognizably bad. You waited on hold, you got a scripted answer, you knew you were dealing with a system that didn't care.

Now bad support wears a mask. The chatbot sounds helpful. It asks clarifying questions. It radiates confidence. And it solves nothing. You end up in a loop, rephrasing the same problem three different ways, hoping the machine will finally understand what you need.

The worst part isn't that it's wrong. It's that it's wrong with perfect posture.

Most companies have made the bot a gatekeeper. You can't reach a human without first proving to an algorithm that your problem is real enough. An obstacle course with a customer service logo on it.

And when you finally reach a person, the context usually doesn't come with you. The bot took your story, then made you tell it again.

That's the customer's experience. From the operator side, it's worse.

The bot resolves tickets without you ever reading them. It classifies problems into categories that sound neat on a report but lose all the texture.

A frustrated user who would have written "I keep clicking the blue button and nothing happens" gets silently routed to "UI Bug - Resolved." You see a clean dashboard. You never learn that "the blue button" is actually your onboarding flow, and five people hit the same wall this week.

The bot doesn't just frustrate your customers. It makes you think everything is fine.

Rescued Customers Are Your Loudest Advocates

A customer who had a problem and was helped by a real human often becomes a stronger advocate than one who never had a problem at all.

Service researchers call this the service recovery paradox.¹ When someone hits a wall and a real person helps them through it, something shifts. They move from "this product works" to "these people care." The second feeling is the one they tell friends about.

Think about the last time you had a genuinely great support experience. You probably still remember the company. Now think about the last product that just worked fine. You probably can't name it.

Chewy sends handwritten sympathy cards when a customer's pet dies. A thousand hand-painted pet portraits every week. When Anna Brose tweeted about receiving flowers after her dog passed, it got over 600,000 likes. One moment of care that reached more people than most ad campaigns ever will.

Satisfied customers are silent. Rescued customers are loud. And that loudness is worth more than most ad budgets (which says a lot about ad budgets, but that's a topic on its own). A real user saying "I had a problem and they fixed it in ten minutes" carries more weight than your entire landing page (better still, put it on your landing page).

You cannot manufacture that with a chatbot.

Sit in the Queue

Founders doing support personally is one of those known success secrets everyone nods at and almost nobody follows. It keeps showing up on lists. It keeps being ignored. Because it feels like a step backward when you're supposed to be the CEO.

Jason Fried at Basecamp calls it "Everyone on Support" and rotates every employee through the queue, founders included. The reasoning is simple: stop hearing from users directly and you start building for an imaginary customer.

In my own ventures, when I have enough control over the operation, the approach is simple:

Founders do support first. Always. No exceptions until the volume genuinely exceeds your capacity.
When you hire for it, the instructions are short. Listen to the customer until they finish. Actually try to help them. And if you can't, help them understand why, even if the reason is company policy. We regularly part ways with clients who aren't a good fit, and we tell them why honestly.

That's it. In most markets, for at least the past fifty years, this is enough to become the best support in your category. The bar is that low.

But.

There's a trap in this, and it's worth knowing going in. The people who write support tickets are self-selected. They care enough to complain, or they're invested enough to ask for help. They're valuable. They're also not the whole picture.

The twenty who didn't write in? Some of them worked around the problem. Some of them are tolerating it. And some of them already left, with no ticket, no complaint, no signal.

The satisfied customers who have nothing to say are one kind of silence. The dissatisfied ones who gave up on you are another.

Sitting in the queue is necessary. But the people who reach out are always a biased sample.

Support tells you where the friction is for people who are still trying. It tells you nothing about the people who already stopped.

The mechanical parts (password resets, order tracking, basic FAQ) can and should be streamlined eventually (but not when you start). Everything else, every edge case, every frustrated user whose ticket doesn't match a template, keep that human. Those messy tickets reveal where your product's mental model diverges from your users'. That gap is where the real improvements live.

An AI agent may resolve the ticket. A human will hear the subtext.

The Product That Listens

Support is where your product talks back to you. Every other channel (analytics, surveys, interviews) gives you a filtered, delayed, partial picture. Support is raw, immediate, and honest.

Surveys ask the questions you already know to ask. Support shows you the question you missed.

The founders who understand this mine the queue. They read tickets the way a trader reads the tape, looking for signals everyone else is filtering out. But they also watch the exits: the users who go quiet, the trials that end without a word, the accounts that slowly stop logging in.

Counting tickets is the shallow version. The real work is noticing when ten different complaints are all pointing at the same broken assumption.

Your support inbox is a competitive advantage. The silence around it is a warning. Pay attention to both.

Rabbit Hole

If you're optimizing metrics instead of understanding your customers, you might be measuring yourself into irrelevance: Every Metric Is Green, the Customer Is Lost.

The most reliable demand signals come from what people do, not what they say: The Critical Demand Signals Nobody Talks About.

And if your signups look promising but nobody converts, your support queue might tell you why before your funnel does: Your Signups Are Lying to You.

The service recovery paradox, first described by McCollough and Bharadwaj in 1992, shows that customers who experience a failure followed by strong recovery can end up more satisfied than those who never had a problem. Subsequent research has yielded mixed results, but the effect appears strongest when the failure is modest and the recovery feels personal and immediate. Sources: Michael A. McCollough, "The Recovery Paradox", 1995; Celso Augusto de Matos, Jorge Luiz Henrique, and Carlos Alberto Vargas Rossi, "Service Recovery Paradox: A Meta-Analysis", 2007.
TARP (Technical Assistance Research Programs) found that for every customer who complains, 26 others remain silent. The piece uses "roughly twenty" as a conservative round number. Sources: John A. Goodman, "Basic Facts on Customer Complaint Behavior and the Impact of Service on the Bottom Line," Competitive Advantage (ASQ Service Quality Division), June 1999; John Goodman and Steve Newman, "Understand Customer Behavior and Complaints", Quality Progress, January 2003.
Qualtrics reported in 2025 that AI-powered customer service failed at four times the rate of other AI tasks in its consumer-experience research. Source: Qualtrics, "AI-Powered Customer Service Fails at Four Times the Rate of Other Tasks", October 7, 2025.
Gartner reported in 2024 that 64% of customers surveyed would prefer companies not use AI for customer service, with difficulty reaching a person among the top concerns. Source: Gartner, "Gartner Survey Finds 64% of Customers Would Prefer That Companies Didn't Use AI For Customer Service", July 9, 2024.

Knowing Is Already Doing

2026-04-23T05:01:00Z

You keep hearing "learn less, do more." But what if learning was always a form of doing?

"Stop reading. Start shipping."

It's one of the most repeated lines in the indie hacker world. And it's half right, which is the most dangerous kind of wrong.

You've been building something. Maybe you've shipped, maybe you haven't yet. Either way, the message follows you everywhere: bias to action, learn by doing, stop overthinking, just ship. You've seen founders who read about startups for years without launching anything. You don't want to become that person.

So you ship fast. You skip the reading. You build first and ask questions later.

Sometimes it works. But often you build the wrong thing entirely. Or, more rarely, the right thing, the wrong way. And you spend twice as long fixing what you could have avoided by spending some time understanding the problem first.

The Binary That Doesn't Exist

People frame "knowing vs. doing" like a choice. Pick one.

But think about what knowing actually requires. You read. You study. You research your market. You analyze what worked for others and why. Each of these takes time, effort, and intention. You don't absorb knowledge by osmosis. Nobody downloads it into your brain. (We haven't built the Matrix yet.)

Acquiring knowledge is an act. It just happens to be an act that doesn't produce a visible artifact, so people dismiss it as the opposite of action.¹

The real question was never "should I know or should I do?" It was always: what is this activity for?

Purpose Is the Variable

A founder who reads 20 books about startups before writing a line of code might be wasting time. Or might be doing the most important work of the project. It depends entirely on why they're reading.

Reading because it feels productive without the risk of shipping? That's avoidance wearing a learning costume. I wrote about that trap before: pattern recognition becoming a comfortable substitute for pattern creation.

Reading because you identified a specific gap, something you need to grasp before you can build well? That's preparation. The axe-sharpening that makes the chopping fast.

Same behavior. Same bookshelf. Completely different purposes.

This is why "just do more" misfires as advice. It treats the symptom (inaction) without diagnosing the cause (unclear purpose). A founder who ships blindly has the same problem as one who studies endlessly. Both are running half a cycle.

What Bridge Engineers Already Know

Before a single beam goes up, a bridge engineer spends months. Studying soil samples. Analyzing wind loads. Running stress calculations. Reviewing material properties. Reading about failures of similar bridges in similar conditions.

Most of the project timeline is this invisible work. Spreadsheets, tables, papers. No steel, no concrete, no visible progress. To anyone watching, it looks like someone staring at numbers.

Often, the actual construction is the shorter phase. The knowing is where the bridge gets built. The doing is where it becomes visible.

Imagine telling a bridge engineer: "Stop studying load tables. Just start building."

The bridge falls down. The stakes make it obvious. Skip the knowing phase and the doing phase produces something that collapses under its own weight.

Yet in the startup world, we say exactly this. "Stop researching. Just build." The stakes are lower, sure. Nobody dies. But the structure is the same. Skip the understanding, and what you build won't hold up.

Know, Build, Know Again

The effective version of "bias to action" is a cycle, not a direction.

Study a problem deeply enough to form a point of view. Build something based on that point of view. The build reveals what the knowledge missed.

Go learn the missing piece. Build again.

Some knowledge only arrives through building. You won't understand your users by reading about them. You have to ship something and watch what happens. The "bias to action" crowd is right about this. The mistake is using it to dismiss the other half entirely.

Every "knowing" phase sharpens the next "doing" phase. Every "doing" phase reveals what the next "knowing" phase needs to focus on.

The cycle breaks when one phase disconnects from the other. Learning that never reaches building is escapism. Building that never incorporates learning is thrashing.

But...

The cycle has a subtler failure mode. You can cycle between knowing and doing efficiently, purposefully, and still build nothing that compounds. Each loop produces a small output. A micro-app. A thread. A prototype. The loop spins, you ship, you learn, you ship again.

A year later, you have fifteen small things and no big thing.

The cycle works when each loop feeds the next one. When what you learned in loop three shapes what you build in loop seven. When it stops being a series of isolated sprints and starts compounding into something with a trajectory.

Which raises a question: what kind of knowing compounds best?

The Knowing You Can't Plan

Earlier I said purpose is the variable. That's true for the knowing/doing cycle within a project. But some of the most valuable knowing arrives without a purpose at all.

You run a logistics operation and spend months learning route optimization, driver scheduling, real-time dispatch under pressure. Then you build a software product and realize the delivery routing problem is structurally identical to user onboarding: both are about sequencing steps to minimize drop-off at each transition.

That pattern didn't come from reading about UX. It came from watching drivers quit routes that had too many awkward turns.

This is the kind of knowing the "just ship it" crowd can't account for. It wasn't gathered as preparation for anything. It was gathered by living a different kind of life, working across different kinds of problems, paying attention in rooms you weren't expected to be in.

And now AI has made this kind of knowing more important, not less.

A prototype that took a week now takes an afternoon. Code that took days appears in minutes. When building is that cheap, a thousand founders can ship the same landing page this week.

The one whose landing page actually converts is the one who knows something the others don't. Who ran a different kind of business before, or studied a completely unrelated field, or spent years paying attention to problems outside the startup bubble.

When the cost of doing drops to near zero, the value of knowing doesn't drop with it. It goes up. The cheaper the build, the more your understanding is what differentiates.

That's compound interest on curiosity. And you can't manufacture it by "biasing to action."

One Question Worth Asking

Before you read that next book, take that next course, or start that next prototype, try one question:

"What will I do differently because of this?"

If you can name the concrete action this knowledge enables, you're inside the cycle. The knowing is feeding the doing.

If you can't, pay attention. It might be genuine exploration, which has its own value. Or it might be avoidance.

Sometimes the answer is obvious. Often it isn't. The ambiguity is worth sitting with rather than resolving with a rule.

What It Actually Looks Like

The "learn less, do more" crowd points at a real failure mode. Knowledge hoarding exists. People do hide in preparation because creation feels risky.

But the fix was never to pick a side.

The best work happens when you can't quite tell which phase you're in. Reading about an unrelated problem gives you the architecture for the thing you're building. Shipping a prototype teaches you something about your users that no research could have surfaced.

The line between preparation and creation stops mattering. The two feed each other faster than you can categorize them.

That's when knowing and doing become the same thing. Not as a philosophical claim, but as something you feel in the work itself.

Rabbit Hole

If this resonated, you might also enjoy:

The Most Dangerous Skill for Builders looks at when pattern recognition becomes a comfortable substitute for creation.
Why I Work Like I'm Slacking makes the case that eighty percent exploration might be the right ratio.
AI Didn't Automate the Grind explores what happens when the distance between curiosity and execution shrinks.

John Dewey spent decades arguing that separating knowing from doing is both philosophically mistaken and practically harmful. He saw the two as aspects of a single process, a view that remains underappreciated a century later. See Democracy and Education (1916), particularly the chapters on experience and thinking.

The Most Dangerous Skill for Builders

2026-04-21T04:55:00Z

Pattern recognition feels exactly like progress. That's what makes it dangerous.

You've read the case studies. You can identify why some products win and others don't. You spot gaps in every market you look at. Your friends come to you for takes on products, trends, entire industries.

You have incredible pattern recognition.

And it might be the thing keeping you from building anything.

Seeing the Board vs Moving the Pieces

Two fundamentally different skills look almost identical from the inside.

Pattern recognition is seeing what's already there. Spotting the trend. Identifying why something works. Connecting dots between data points that seemed unrelated a moment ago.

Pattern creation is making something new that becomes a pattern others recognize later.

The analyst who explains why a hit song works. The songwriter who writes the next one. Both deal in patterns. Only one puts a new one into the world.

Here's what makes this tricky: your brain's reward system can't tell the difference.¹ You spot a connection nobody else sees, and it feels like you made something. Your brain hands you the satisfaction of building without any of the risk of shipping.

The Comfortable Substitute

If you're a founder who's been "researching the market" for six months, you know exactly what I'm talking about.

Pattern recognition is seductive because it IS a real skill. It IS valuable. The problem starts when it becomes a hiding place for the harder thing.

Watch how it plays out. You notice a gap in the market. Genuine insight. You study competitors and identify what they're missing. You read about similar companies in adjacent industries and connect the dots.

At every step, you're doing real intellectual work. Getting smarter about the space. Feeling productive.

But you haven't built anything.

And if you've worked across different industries, the substitute gets even more comfortable. Every domain you've touched gives you lenses nobody else has. It feels like a superpower because it IS a superpower.

But lenses aren't buildings.

The distance between "I see the opportunity" and "I shipped the thing" isn't a knowledge gap. Recognition and creation are different muscles. Practicing one doesn't automatically build the other.

The Cooking Test

You can taste a dish and name every spice. Read a recipe and predict the result. Compare techniques across cuisines and explain why Thai curries work differently than Indian ones.

All pattern recognition. Valuable, interesting, even impressive.

None of it tells you whether you can create a dish that becomes someone else's favorite recipe.

The same holds for products, essays, songs, anything that gets built. Analyzing what exists and creating what doesn't exist yet are different acts entirely. One feels like preparation. The other feels like jumping.

Lightning in a Bottle

But the reverse also holds. Plenty of brilliant songwriters can't explain why their melodies work. They create patterns purely by feel.

The two muscles really are independent.

But the creators who also recognize what they're doing have a genuine edge. They compound. Each thing they build teaches them something they can name, and naming it means they can use it again. They don't depend on the same intuition striking twice.

Pure creation without recognition is lightning in a bottle. Beautiful, powerful, unreliable.

Where the Best Builders Live

So should you stop recognizing patterns?

No. The best builders I've watched do something specific: they use recognition as fuel for creation. Never as a destination.

They spot a pattern, then immediately ask: "What can I build with this?" The insight becomes raw material for the next thing they ship.

Three questions that separate pattern fuel from pattern traps:

Does this insight change what I'm building right now? If not, it's entertainment disguised as research.
What am I avoiding by doing this research? If nothing comes to mind, carry on. If something does, you already know.
When did I last ship something that came from a pattern I spotted? If you can't trace a recent insight to a concrete thing you made, the loop is broken.

The rhythm is simple. Spot, build, learn. Spot, build, learn. The moment "spot" starts running without "build," you've left the game.

The Version Nobody Warns You About

That's the obvious trap. Here's the one that's harder to catch.

Some builders aren't stuck in analysis. They ship constantly. They spot a pattern in one domain, build something, spot another pattern in a different domain, build something else. They pass all three questions above. Every insight changes what they're building. They're not avoiding anything. They shipped last week.

But they're building in five directions at once.

The pattern trap has a quieter version. For people who work across multiple domains, pattern recognition doesn't generate one insight to act on. It generates dozens. Every new field you've touched becomes a lens, and every lens reveals a viable build. The courier industry shows you something about logistics that applies to content delivery. Publishing shows you something about curation that applies to product design. Each connection is real. Each build is genuine.

But the connections stay locked inside your head.

Your pattern recognition ties everything together beautifully, for you. From the outside, it's five unrelated projects, each standing on its own. The thing that makes you valuable, your ability to spot patterns across domains, stays invisible in the finished work.

This is the trap the "just ship it" advice can't reach. You ARE shipping. But the superpower that drives each build never makes it into the build itself.

The Throughline

This shows up everywhere, not just in startups.

In photography, you can study composition rules until you dream in thirds and leading lines. At some point you have to point the camera and create a composition someone else will study.

In code, you can review other people's pull requests and spot elegant patterns all day. Eventually you have to open a blank file and write your own.

The first courage is starting. Most advice stops here.

But for multi-domain builders, there's a second challenge that has nothing to do with courage. It's about throughline.

The photographer who shoots landscapes, then portraits, then street, then food isn't wasting time by switching. But there's a difference between switching subjects and developing a recognizable eye that carries across subjects. The first is a portfolio. The second is a body of work. People follow the eye, not the subject.

The same applies to building. A courier service and a publishing company don't need to be "related." But if people can see the same perspective running through both, the same way of noticing what others miss, the work starts to compound. The projects don't need to connect to each other. The person behind them becomes someone worth following into the next domain.

Pattern recognition feels like insight. Pattern creation feels like risk. And making your cross-domain connections visible, not just using them to start the next build? That's the move nobody tells you is even an option.

Feed the Loop or Thread It

The most interesting builders are the ones who recognize and create in a continuous loop. They see a pattern. They build something. The thing they built creates a new pattern. They recognize it. They build the next thing.

Recognition without creation is commentary. Creation without recognition is lightning in a bottle. And creation without a throughline is just a portfolio.

Next time you catch yourself deep in analysis, ask one question: am I feeding the loop, or hiding in it?

But if you already know you're not hiding, ask the harder one: is the thing that connects all my builds visible in the work, or locked inside my head?

Rabbit Hole

If this resonated, you might also enjoy:

The New Bottleneck explores what happens when building gets easy and the real challenge shifts to knowing what to build.
The Idea Is the Product argues that in an AI world, the idea itself carries more weight than ever.
Writing Grammar Before the Language Exists looks at why we rush to standardize patterns before we've finished discovering them.

Oh, Y., Chesebrough, C., Erickson, B., Zhang, F., & Kounios, J. (2020). "An insight-related neural reward signal." NeuroImage, 214, 116757. The study found that insight moments trigger a reward signal in the orbitofrontal cortex, a region the brain uses for reward learning and pleasurable experiences, giving "aha" moments a neurochemical signature similar to tangible rewards.

2X AI Coding Speed, Without the Slop

2026-04-16T06:58:00Z

You've started shipping faster with AI, and now each session threatens to turn you into your own full-time reviewer.

A good live sound engineer doesn't wait until the encore to learn the mix was muddy. They hear the room start to smear while the band is still playing, then they reach for the knob.

AI coding has the same problem.

You ask for speed. The model gives you output. Then the saved time disappears into checking everything it wrote.

I've noticed this fastest on small tools like Pricing Unit Picker or Barbell Position Calculator. In a larger codebase, smell matters even more because the blast radius is bigger. On a tiny tool, the review tax is just easier to see because there is nowhere for it to hide.

The caution comes from a sane place. Models are fast, confident, and fully capable of making local decisions that look tidy and age badly.

The standard advice is to review every line. For a tiny snippet, fine. For real product work, that advice quietly rebuilds the bottleneck you were trying to remove.

The Careful Advice That Recreates the Old Job

Once AI starts producing serious amounts of code, most people fall into two bad loops.

One loop is blind trust. You merge momentum and inherit cleanup later.

The other loop feels responsible. You read every line, verify every branch, and slowly turn yourself into a human checksum.

Both loops miss the upgrade.

The real promise was moving your attention up the stack, toward direction, tradeoffs, and early intervention.

That is why the productivity story around AI coding still feels slippery. In a 2025 METR study, experienced open-source developers working in repositories they already knew well took 19% longer when they were allowed to use AI tools.¹ That result does not mean AI slows everyone down. It does show how easily the overhead can move from typing into prompting, waiting, reviewing, and cleanup.

Reading every line sounds responsible because it protects you from obvious breakage. It also makes you personally absorb the full surface area of the model's output. Once the output gets large enough, your leverage collapses.

You become a human parser for machine enthusiasm.

Smell Shows Up Before Bugs Do

Good builders rarely catch the first sign of trouble at the level of syntax. They catch it earlier, at the level of direction.

A copy change grows teeth and asks for a new abstraction. A local fix reaches into seven files. A tiny feature suddenly needs a new dependency. The explanation sounds polished, but it slides right past your actual constraints.

That is execution smell.

I don't mean mysticism. I mean compressed pattern recognition.

The same smell has shown up for me every time I crossed domains. The medium changes. The first warning does not. It starts as drift, more side paths, more exceptions, more explanation than the job should need.

GitClear's 2025 report looked at 211 million changed lines from 2020 through 2024 and found more copy-pasted code alongside a drop in moved or refactored code.² That does not prove AI caused every bad change. It does match a familiar failure mode. Each individual function can look reasonable while the system gets fatter, patchier, and harder to reason about.

Picture a simple request: make the annual billing copy clearer on a pricing page.

The model comes back with a new constants file, a helper, an analytics event rename, a wrapper component, and a tidy comment about maintainability. Tests may still pass. The smell is that you just financed a future you never asked for.

This is why experienced builders often feel something off before they can fully explain it.

The smell comes first. The clean diagnosis arrives a minute later.

The Drift Check

What you need is a small framework for interrupting bad momentum early.

Call it the drift check. Run it while the AI is still working, not after the branch has already sprawled.

Scope drift. Did the change grow wider than the request? A button fix became a refactor. A one-file task became a mini migration. Growth always asks to be paid for later.
Abstraction drift. Did the model introduce a wrapper, helper, service, hook, or pattern your codebase did not need five minutes ago? AI loves symmetry. Your codebase has to live with consequences.
Seam drift. Is a local change now pulling in distant files, glue code, or extra dependencies? Most long pain enters through seams.
Story drift. Can the model explain, in plain language, why this approach fits your constraints and what tradeoff it chose? Once the explanation goes generic, judgment has already left the room.

This gives you places to interrupt without rereading the whole diff.

Ask for a plan before code. Cap diff size. Make the model name the invariant it is preserving. Ask what it decided not to change. Ask why a new dependency beats the primitives you already have. Ask for the whole task restated in one sentence before it touches anything.

These are not rituals. They keep smell close to execution.

And yet.

Once you get good at smelling drift, you can start interrupting for sport. Every wobble becomes a reason to step in. You feel discerning. The model turns from a genuine thinking partner into a nervous intern waiting for approval to breathe.

That is just micromanagement wearing a taste badge. The drift check only works if it stays small and consequential. Pressure points, not theater.

Review Pressure Points, Not Every Line

This does not mean skipping review.

It means reviewing like someone who understands where the danger actually lives.

GitHub's own guidance for AI-generated code starts with functional checks, then context and intent, then code quality, dependencies, and AI-specific pitfalls.³ That order matters because risk is unevenly distributed.

Some code deserves deep reading every time. Authentication. Billing. Permissions. Migrations. Concurrency. Deletion flows. Unfamiliar libraries. Anything with hard-to-reverse consequences.

If the counterargument in your head is, yes, but I still need to read every line on risky code, I agree. The point is not to stop being careful. The point is to stop spending the same level of care everywhere.

A lot of other code deserves strategic reading. File shape. Diff size. Tests. Error handling. Whether the new code matches surrounding style. Whether the model quietly created a second way to do something the codebase already knew how to do.

If I were sketching this on a whiteboard, I would still draw two loops.

In the first loop, AI writes, you read everything, you get tired, and the structural mistake still slips through because fatigue loves plausible code.

In the second loop, AI proposes, you catch drift early, you interrupt at pressure points, and you reserve deep reading for the places where consequences compound.

Only one of those loops preserves the point of using AI.

I care about this because my own temptation is not blind trust. It is over-control. When the model is productive, the easiest ego trap is feeling like the smartest person in the room because I can spot every wobble. Meanwhile the product ships slower.

Taste Moves Earlier in the Process

This shift matters because AI changes where taste shows up.

In the old workflow, taste often arrived after the fact. You wrote the code, stepped back, and judged whether it was elegant, coherent, and built for the right future.

With AI, taste has to arrive earlier.

While the shape is still soft. While the model can still be redirected. While you can still prevent a hundred lines of eager wrongness instead of cleaning them up afterward.

That changes who gets leverage. Typing speed matters less. API recall matters less. A live filter matters more. This is one place a broad background actually helps.

If you've spent years jumping between different kinds of work, you get suspicious of fixes that look clean in isolation. You've seen too many cases where the quick answer solved the immediate problem and made the overall system harder to hold in your head afterward.

That matters with AI because models are excellent at local improvements. The whole job is noticing when a local improvement is quietly making the codebase harder to reason about.

Prompt craft matters less than people want it to. Holding the product in your head matters more. So does understanding what kinds of complexity age badly, and noticing when AI is optimizing for completion instead of coherence.

That is why some builders get huge leverage from AI coding while others end up underwater in cleanup. The gap shows up in judgment timing.

Blind trust fails. Exhaustive reading fails more slowly and with better intentions. Live judgment scales further.

The builders who win here will not be the ones with infinite patience for reviewing machine output. They will be the ones who can hear the mix going muddy while the track is still playing.

That was the upgrade all along.

Rabbit Hole

If this line of thinking resonates, keep going with The Uber-Engineer Doesn't Write Code, on why AI increases the value of direction and system-level judgment, The One-Shot Illusion, on the quality tax that shows up when AI-built products ship on demo energy alone, and The Skill AI Can't Replace, on the part of the job that stays deeply human.

METR's July 10, 2025 study followed 16 experienced open-source developers working on 246 real tasks in repositories they already knew well. Participants expected AI to help, yet the measured result in that setting was a 19% slowdown. This is useful evidence about one real workflow, not a universal verdict on every developer or codebase.
GitClear's 2025 report analyzed 211 million changed lines from 2020 through 2024 and reported more duplicated code plus weaker moved or refactored signals over that period. This is observational, not a clean causal proof about AI, but it is a useful signal for the kind of structural drift many teams already feel.
GitHub's documentation on reviewing AI-generated code recommends starting with functional checks, then verifying context and intent, assessing code quality, scrutinizing dependencies, and looking for AI-specific pitfalls. The sequence supports the larger point here: review depth should follow risk, not habit.

Every Metric Is Green. The Customer Is Lost.

2026-04-13T04:53:00Z

Every metric across every team is green, and the customer still feels like nobody's listening.

A customer emails support about a billing question. While they're waiting for a reply, marketing sends them an upsell campaign. Sales follows up on a demo request from two weeks ago. Product pings them about a new feature survey. The NPS bot asks how they're feeling.

Five touchpoints in two days. All individually reasonable. All logged in their respective dashboards. All hitting their respective KPIs.

The customer just wanted to fix a $12 charge.

Everyone Sees a Different Customer

You've built a product and assembled teams around it. Support, marketing, sales, product, customer success. Each has their own tools, their own metrics, their own quarterly goals. Each is doing good work.

That's precisely the problem.

Support sees a ticket. Marketing sees a segment. Sales sees an opportunity. Product sees usage data. Customer success sees a health score. Five departments look at the same person and see five different things.

Each optimizes its piece perfectly. Support reduces response time. Marketing improves open rates. Sales hits quota. Product ships features based on usage patterns. Every dashboard shows progress.

The customer's experience? A series of messages from a company that clearly has no idea what they're dealing with right now.

Nobody failed. The entire architecture was designed around how you organized your teams, not around how the customer actually moves through your product. You've turned a brand relationship into a commodity interaction without changing a single line of copy.

You Don't Need Five Teams to Fragment Your Customer

If you're a solo founder reading this and thinking this doesn't apply to me yet, it already does.

You don't need departments to create fragmentation. You need automation.

I've watched this happen in my own projects. You wire up the welcome emails. You add the "haven't seen you in a while" nudge. You set up the upgrade prompt at a usage threshold. Each makes sense on its own. Each runs on its own clock. Nobody's in charge of how they interact.

Then someone signs up, hits a rough patch on day two, and gets a cheerful "here's what you can do next!" email while they're still stuck. Your automation doesn't know they're stuck. It only knows it's day two.

As a solo founder, you ARE the person who holds the full picture. You can see the stuck user in your logs, read their support email, and suppress the upsell manually. That's your superpower right now. The real question: what happens when you lose it?

Five Specialists, No Diagnosis

Medicine figured out a version of this problem.

When you feel a pain in your chest, you don't walk directly into a cardiologist's office. You go to your GP. The general practitioner who knows your history, your medications, your lifestyle, that thing with your back last year that turned out to be nothing.

The GP doesn't run the MRI or perform the surgery. But a good GP does something no specialist can: see the whole patient.

When you need a specialist, the GP refers you. When you need three specialists working on related problems, the GP coordinates. Research supports the intuition: in care models where GPs coordinate specialist involvement, patient retention tends to improve, particularly for chronic conditions.¹

The GP's core job is diagnosis. Understanding the full picture before anyone starts prescribing.

Most companies have no GP for their customers. Every department is a specialist. The customer walks in and gets triaged by whichever team happened to encounter them first. Nobody asks the diagnostic question: what is this person actually trying to accomplish right now?

The Question That Replaces Your Dashboard

What is this specific person trying to accomplish today, and are we helping or interrupting?

When you can answer that, everything else resolves.

Timing figures itself out. Reach out when the answer is "helping." Stay quiet when the answer is "interrupting."

Channel becomes obvious. Someone debugging an integration wants documentation or live help. Someone evaluating an upgrade wants a case study or a pricing page. The channel follows the job.

Content follows the job too. The customer who just hit a billing snag needs their $12 fixed. That feature announcement can wait.

The companies that get engagement right built the capacity to answer this one question in close to real time. Better automation and smarter decision layers help, but they're downstream of the real bottleneck: knowing what the customer needs.

Chewy, the pet retailer, shows what this looks like in practice. A customer calls to return unopened pet food after their dog dies. Chewy refunds the purchase, sends flowers and a handwritten condolence card, and quietly suppresses the automated reorder reminders. That response looks effortless from the outside. From the inside, it requires every department to share one piece of context: what just happened to this person.

Why a Customer Data Platform Won't Save You

The instinct is always to buy a tool. "We need integration. Unified customer view. Customer 360."

The average company now runs over 100 SaaS applications.² Larger firms average nearly 900 and integrate only 29% of them. So you buy a Customer Data Platform to stitch it all together.

The results? Industry surveys report dissatisfaction rates as high as 90%. Only 29% of customer data platform (CDP) owners are satisfied with segmentation. Personalization, the thing you actually bought it for, scores 22% satisfaction.³

A CDP gives the fragmentation a nicer interface. You now have a beautiful unified profile, and five teams are still looking at it through five different dashboards with five different definitions of what matters.

Data integration was never the bottleneck. Nobody was asking what the data means for this specific person right now. A unified profile without a diagnostic question is just a more expensive way to bother your customers in unison.

What a Customer GP Actually Looks Like

Think of it as a function. A perspective that sits across departments and asks one question repeatedly: do we know what this person is trying to do right now?

Some companies build this into the product itself. Slack is a clean example: when you're active on desktop, it suppresses mobile push notifications and email digests. The product observes your behavior and adjusts what the rest of the system does automatically.

Extend that logic to your whole customer relationship. If someone is actively building an integration, suppress marketing emails. If someone just opened a help article after a week of silence, route them to support before they ask.

Others make it a structural assignment. Amazon structures around what they call "single-threaded leaders": one person owns a single product or initiative end-to-end, with dedicated resources and the authority to coordinate across every department that touches it. Within that scope, the leader holds the full picture of how customers interact with their product, not just one team's slice.

Smaller companies achieve the same thing with a lean operations team whose sole mandate is to hold the unified picture and flag when departments are about to collide.

But.

Coordination tips into surveillance faster than you'd think. "We noticed you were browsing our pricing page while your support ticket was still open" might be insightful context for your team. Say it out loud to the customer and it sounds like you're watching them through a window.

The diagnostic question is what is this person trying to do? Not what is this person doing on every screen right now? The first earns trust. The second erodes it. The difference matters more as your data gets richer.

The mechanism varies. The question stays the same. Is anyone, anywhere in your company, responsible for knowing what this specific customer is trying to accomplish today?

If the answer is no, your metrics will keep looking fine. And your customers will keep feeling like they're talking to five strangers who happen to share a logo.

When the GP Becomes Another Specialist

Here's the trap nobody warns you about.

You create the Customer GP function. You hire someone, or build a team, or install a system to hold the unified view. It works. For a while.

Then the GP function starts developing its own metrics. Diagnostic accuracy rates. Cross-department coordination scores. "Customer context freshness" dashboards. Before long, you have a team optimizing their own numbers just like every other department. The thing you built to prevent silos becomes a silo.

The GP model works in medicine partly because the GP is a person with judgment, not a system with rules. The moment you try to systematize "see the whole customer" into a workflow with metrics attached, you risk building exactly what you were trying to escape.

The only real safeguard? The GP function has to stay close to actual customer conversations. Not reports about customers. Not dashboards summarizing customers. The actual humans, saying actual things, in actual context. The moment that distance grows, the diagnostic reflex dies.

The Diagnostic Reflex

The best GPs develop what you could call a diagnostic reflex. They don't jump to treatment. They don't run every test available. They listen, observe, form a picture, and then act.

Companies need the same reflex. Before optimizing any metric, before automating any sequence, before sending any message: what is this person's actual situation right now?

I spend my working life crossing between domains: code, design, marketing, logistics, retail, and more. Not because I planned it that way, but because that's how my brain works. And the one thing I've noticed across every project, every venture, every product: the moment you lose the ability to hold the whole picture of one person's experience, you start optimizing for your own convenience instead of theirs.

The metrics will look great. They always do when you're measuring what's easy to measure.

The customer will be gone before any dashboard tells you why.

Rabbit Hole

If you're rethinking how you read customer signals, Critical Demand Signals Nobody Talks About digs into the signals most founders overlook entirely. If your signups look healthy but conversions don't, Your Signups Are Lying to You explains why the numbers might be telling you the wrong story. And for a deeper look at how your product and landing page create different kinds of understanding, see Your Users Need Two Aha Moments.

A systematic review found that formal GP involvement in specialist care left most health outcomes unchanged, but improved functional outcomes and patient retention, particularly for chronic conditions. "Does primary medical practitioner involvement with a specialist team improve patient outcomes?" (British Journal of General Practice, 2002).
BetterCloud reports the average company uses 106 SaaS applications as of 2024. Zylo data shows larger firms average 897 applications with only 29% integration rate.
CDP dissatisfaction data from industry surveys cited by CMSWire and Celebrus. Satisfaction rates: segmentation 29%, personalization 22%. The 90% dissatisfaction figure comes from analyst reports referenced in these surveys, though the underlying methodology is not fully transparent.

Critical Demand Signals Nobody Talks About

2026-04-09T04:56:00Z

Everyone says "build for yourself." Here's the signal that actually proves someone else will pay.

You scratched your own itch. Built the thing you wished existed. Used it yourself for weeks, maybe months. It works. You're proud of it.

And now you're staring at a launch that nobody seems to care about.

The Data Point of One

"Build for yourself" is canonical startup advice. Paul Graham preaches it. DHH built Basecamp from it. Many successful founder stories seem to start with "I needed this, so I made it."

The advice is sound. It's also dangerously incomplete.

You needed this product. That's a fact about you. It tells you nothing about the market. A single data point describes your life, your workflow, your frustrations. The market hasn't spoken yet.

You've been shipping for weeks. You believe in what you built. Belief keeps you building. It won't tell you whether you should.

So where do you look?

Watch the Hands, Not the Mouth

Communities are full of signals. Most founders read the wrong ones. There's a hierarchy here, and it matters.

Wishes sit at the bottom. "Someone should build an app that does X." This means almost nothing. People wish for things constantly. Wishing costs zero effort, which is exactly what it's worth as a signal.

Complaints are one step up. "I'm so frustrated with X." Better, but dangerous. Complaints in communities often point you toward feature requests for products that already exist (going after the same market can work, but that's a different play). That person wants their current tool to suck less. You'd end up building someone else's feature request.

Workarounds are the gold. "I've been using [tool never meant for this] combined with [other tool] to kinda sorta do [thing]."

When someone describes a workaround, they've already crossed every threshold that matters. They identified the problem. Accepted it's solvable. Invested real time. And settled for a brittle, clunky solution because nothing better exists.

In chemistry, activation energy is the minimum energy needed to start a reaction. In human behavior, it's the gap between "this annoys me" and "I'm actually going to do something about it." Most problems never cross that threshold. People tolerate extraordinary amounts of friction.

When someone has jury-rigged a solution from three tools that were never designed to work together, you're looking at someone who already behaves like a customer. They've just been paying with time and frustration instead of money.

The Adjacent-Space Tell

Don't only look in your exact niche. Look sideways.

If you built a tool for photographers, check what videographers are doing. Event planners. Wedding coordinators. When people in adjacent spaces are hacking together the same kind of solution from completely different tools, the problem transcends your personal perspective. It's structural.

Wade Foster, before co-founding Zapier, was doing client work where people kept asking for integrations between apps that didn't talk to each other. Then he went to the support forums of Evernote, Salesforce, and Dropbox and found the same pattern: people describing specific workflows they'd duct-taped together with manual processes and custom scripts. No single community was asking for "Zapier." But dozens of communities were independently cobbling together the same kind of brittle solution.

Nathan Barry saw it too, before building ConvertKit. Professional bloggers were stringing Mailchimp together with WordPress plugins, third-party landing pages, and manual subscriber tagging to create email sequences Mailchimp was never designed to support. The tools weren't broken. They just weren't built for what creators needed. The bloggers had already proven the demand by frankensteining together their own version of the product that didn't exist yet.

In both cases, the founders didn't discover demand by asking people what they wanted. They discovered it by watching what people were already doing with the wrong tools.

But those stories reveal something else. The adjacent-space check doesn't just validate that demand exists. It tells you what people actually value about the solution.

A photographer jury-rigging an asset workflow cares about organization. A wedding coordinator cobbling together the same kind of system cares about speed under pressure. Same structural problem, different workaround shape, because each group filters the problem through what matters most to them.

I've shipped products in courier logistics, food delivery, children's book publishing, and software. In every case, people were already solving the problem with the wrong tools before I showed up. But the workarounds looked nothing alike. Courier clients' workarounds pointed at reliability. Food delivery workarounds pointed at speed. Bookstore workarounds pointed at discovery. The workaround's shape tells you what the product needs to solve first. Miss that, and you build a technically correct product that doesn't match what anyone was actually paying to fix.

Run the Test

Before you build (or before you panic about a quiet launch), run what I call the duct tape test. Look for three things:

Multiple people solving the same problem with different wrong tools. If everyone's using the same tool, you're looking at a feature request for that tool. If they're each reaching for different tools, the problem is real and unaddressed.
Solutions that work but barely. Functional enough to keep using. Fragile enough to curse at. People won't abandon something that's "fine." They will abandon something held together with spreadsheet formulas and a prayer.
Independent invention. They came up with these workarounds on their own. When multiple people independently hack together the same kind of solution without coordinating, you're seeing a genuine pattern.

All three present? You have something better than a hunch. You have evidence of urgent, unmet demand. These people already want what you're building. They just don't know you're building it yet.

What Workarounds Won't Tell You

Workaround shapes tell you what to prioritize. They don't tell you how much to build.

The duct tape test proves the problem. It doesn't prove your solution.

Someone stringing together three tools isn't asking you to replace all three. They might love two of them. What they hate is the glue, the manual step, the copy-paste between systems, the thing that breaks at 2 AM.

Build the complete replacement and you're fighting adoption friction against tools they already like. Build the bridge and you're solving the part that actually hurts.

This is the misread that keeps showing up in indie hacker communities. Someone spots a real workaround, gets excited, and builds a general replacement around it. Six months later they're competing with established tools instead of connecting them. The workaround showed them the pain. They just diagnosed the wrong organ.

Read the workaround closely. What part does the person curse at? What part do they actually seem comfortable with?

The seams tell you more than the surfaces.

Urgency Is the Filter

Real problems are common. Urgent problems are rare. And products survive on urgency.

The duct tape test filters for urgency automatically. Nobody jury-rigs a solution for a mild inconvenience. The very existence of a workaround proves the pain crossed the threshold where tolerance turned to action.

There's a harder case, though. Some workarounds are so embedded in how people work that nobody describes them as workarounds anymore.

Spreadsheets doing database jobs. Browser tabs pinned as dashboards. Manual processes that someone runs every Monday morning "because that's just how we do it."

The friction is invisible because it's been there longer than anyone's been paying attention. These are the demand signals that don't show up in community posts, because nobody thinks to complain about the air they breathe.

If you can see one of these, you're looking at demand so deep the market doesn't know it has it.

This won't help you if you're inventing a new category (nobody was jury-rigging an iPhone in 2006). But at the indie scale, you're discovering demand, not creating it. And workarounds, visible or buried, are the clearest proof that demand already exists.

The next time you think "I need this, so others probably do too," pause. Go find the duct tape. Look for the spreadsheets doing jobs they were never designed for, the browser tabs held open as makeshift dashboards, the twelve-step Zapier chains held together with hope.

If nobody's cobbling together a workaround, the problem might be real. But the urgency isn't there yet.

And urgency is everything.

Rabbit Hole

Your Signups Are Lying to You - what happens when you attract the right numbers but the wrong people
The Idea Is the Product Now - why what you choose to build matters more than how well you build it
Go Ahead, Build What Already Exists - when the market is crowded and you want in anyway

AI Is a Self-Esteem Test

2026-04-07T04:29:00Z

You've spent years becoming the person who does X. Now a machine can do X too.

I've switched domains enough times to recognize a particular feeling. Not because something forced me out, but because every time I chose to move on, I watched a skill I'd built over years become just one line on a longer list. The thing that used to define me stopped being the thing that defined me.

AI produces the same feeling, faster and for everyone at once. Why does watching it work make you feel the way it does?

(Find your exact situation with this free test. No sign-up needed.)

The Knot

You've built something over years. A craft, a skill, a way of solving problems that feels distinctly yours. You ship products, write code that holds up under pressure, turn vague ideas into things people pay for.

Then you watch an AI produce something in the same neighborhood. Close enough that a question surfaces:

If a machine can approximate what I do, what part of "me" is actually me?

It's easier to argue about benchmarks. Easier to debate which jobs are safe. Easier than sitting with the feeling.

Two Kinds of Confidence

When I shut down a business and started something completely different (which I've done more times than sounds reasonable), the transition always exposed the same fault line. Some of what I knew traveled with me. Most of the domain-specific stuff didn't.

The coding patterns from a food delivery platform don't map to a children's book publishing operation. The marketing intuitions from a coupon platform don't transfer cleanly to a mobile app startup. Each switch stripped away the domain confidence and left me face to face with whatever was underneath.

What was underneath, in the times it went well: a trust that I could figure things out. Not confidence in any particular skill, but in the process of learning, adapting, building.

Nathaniel Branden spent decades studying this.¹ He identified two components most people collapse into one. Self-efficacy: a fundamental trust in your ability to think and learn and handle what shows up. And self-respect: the conviction that your life matters, that you deserve to be here and be happy.

Together, these form self-esteem. But they grow from two things working in tandem.

A worldview: the belief that the world enables achievement (though never guarantees it), and that you're capable of navigating it.

And evidence: actually doing things, repeatedly, proving to yourself that you can. Branden called this living purposefully. The more you do, the deeper the foundation.

This is where domain-specific confidence fits. Being great at code or design or deal-making is genuinely part of who you are. You can't build self-esteem without doing something well in your own way. But domain confidence is one thread in a larger fabric, evidence that feeds the deeper foundation.

The trouble starts when people mistake a single thread for the whole cloth. "I'm a great developer" becomes the entire story instead of one chapter. And that narrower confidence only holds until something shows up that can replicate it.

The Mirror You Didn't Order

Before AI, the question was easy to avoid. Your skills felt unique because the competition was other humans, who are inconsistent, limited in bandwidth, working with the same 24 hours you have. Your particular combination of abilities and taste felt unreplicable.

AI changes the math. It's close enough to force the question. And your answer reveals your actual foundation.

If your confidence was anchored to the domain ("I'm valuable because I write great code"), the mirror cracks. You feel threatened. Defensive. You start arguments about why AI output is terrible.

If your confidence was anchored deeper ("I figure things out, I adapt, I keep learning"), the mirror mostly just shows you a tool. You pick it up.

But here's what neither camp talks about. Most people aren't cleanly in one category.

You can pick up the tool, use it well, ship faster than ever, and still feel a quiet erosion of something. That's not weakness. That's the signal working correctly.

It means some of your foundation was domain-anchored and some wasn't, and now you know which parts are which.

The Trap in the Prescription

The obvious advice is "widen your foundation." Build confidence that spans multiple domains. Don't let one skill carry all the weight.

I've lived that advice. Literally. Multiple businesses, multiple industries, multiple complete reinventions. Code, publishing, food delivery, marketing, mobile apps, micro-apps.

And I can tell you: breadth has its own trap.

It's possible to spread across domains as a way of avoiding going deep enough in any one of them to face real judgment. Starting five things feels productive. Finishing one thing and putting it in front of people who can reject it? That requires a different kind of confidence.

Breadth without depth is just a wider surface for the same shallow foundation. You end up with five threads and no cloth.

Your foundation has to include the willingness to go deep enough, even when going deep means discovering you're not as good as you thought.

Breadth gives you resilience. Depth gives you evidence. You need both. And the balance shifts every time you switch domains or pick up a new tool, AI included.

The Part Nobody Mentions

This effect is asymmetric.

People with fundamental self-esteem don't need AI to validate them. They already know who they are. AI is another material to work with, like a new programming language or a better camera.

But people whose entire sense of self lives inside one domain? AI just made that domain replicable. And the question they've been avoiding, whether their foundation extends beyond that single skill, is now impossible to dodge.

The people who feel most threatened by AI aren't the least skilled. They're the ones whose skills were carrying too much weight: doing the work and serving as the entire foundation of their self-worth.

This holds for specific abilities ("I'm a great designer"). And it holds at the most fundamental level: your sense of yourself as someone capable of living a full life, even though the world never guarantees any particular outcome.

The Audit

Three questions worth sitting with:

When AI produces something that resembles your best work, what's your first reaction? Curiosity or defensiveness?
When was the last time you did something genuinely difficult, where the outcome was uncertain and you had to figure it out as you went?
Are you drawn to your work because of the work itself, or because being "the person who does X" tells you who you are?

The honest answers aren't comfortable. They're also more valuable than any productivity hack AI will ever give you.

What the Mirror Shows

If watching AI do your thing creates a knot in your stomach, don't run from it. That reaction is information. Probably the most valuable information AI has produced for you.

It's telling you that your foundation needs work. Not just wider (breadth can be its own dodge). Deeper. The kind of foundation that doesn't crack when any single skill becomes replicable.

I'm not saying this from the outside. I've spent years building a life where my identity doesn't collapse when a single domain shifts. Some days that feels like wisdom. Other days it feels like I've just gotten good at starting over, which is its own kind of avoidance.

The honest version: I don't have this completely figured out yet. I just know what the question is.

The question AI is really asking: Is your foundation wider than any single thing you do?

Most people never had to answer that.

Now you might not have a choice.

Rabbit Hole

For a deeper look at why the goals you're chasing might not match what you actually want, read You Don't Want What You Think You Want.

Also, check Why the Most Consistent People Don't Need Discipline (Free tool included)

Nathaniel Branden, The Six Pillars of Self-Esteem (1994). Branden defined self-esteem as the disposition to experience oneself as competent to cope with the basic challenges of life (self-efficacy) and as worthy of happiness (self-respect). The six pillars, the practices that build and sustain self-esteem, are living consciously, self-acceptance, self-responsibility, self-assertiveness, living purposefully, and personal integrity.

Your Signups Are Lying to You

2026-04-02T04:38:00Z

A hundred signups and zero paying users. The answer is in a question you haven't asked yet.

You've been staring at this number for days. Already planning fixes: simplify the onboarding, add a tooltip to the pricing page, extend the free trial, throw in a feature walkthrough video.

All of this assumes those hundred people needed your product in the first place.

What if they didn't?

The Curiosity Gap

The average SaaS trial-to-paid conversion rate sits around 20%.¹ If you're at 3%, you have a conversion problem. If you're at zero, you have a completely different problem.

Three kinds of people sign up for products.

The first kind has a real problem. They've been duct-taping together spreadsheets and manual processes to handle something that bugs them weekly. They find your product and think finally.

The second kind has the problem, sort of. It annoys them sometimes. On a bad week, maybe they'd search for a solution. They sign up with real intent, poke around, nod approvingly, and never come back. The pain exists. It just isn't worth $15 a month to make it go away.

The third kind has no problem at all. They saw your landing page, thought "huh, interesting," and typed in their email with roughly the same conviction as bookmarking a link they'll never revisit.

All three look identical in your database. Same event, same timestamp, same row. But only the first was ever going to pay.

When zero out of a hundred convert, founders immediately assume the funnel is broken. What they rarely consider: the hundred were the wrong hundred.

The Trailer Problem

A landing page can be good at two very different jobs. Attract people who have the problem you solve, or sound interesting to people who don't.

The best landing pages describe a specific pain so precisely that someone experiencing it thinks they're talking about my situation. These pages often repel people without that problem. Good.

The worst, from a conversion standpoint, are brilliant at sounding interesting. They collect signups from curious browsers who have no wound to heal.

I call this the trailer problem. Think of a movie trailer that makes a quiet character study look like an action thriller. It packs the theater opening weekend. But the audience came for explosions. They leave disappointed, and no amount of better popcorn or comfier seats changes that. The movie was fine. The trailer just promised a different movie.

The trailer problem is when your packaging attracts an audience that your product was never going to satisfy. The product and the audience are both fine. They just don't belong in the same room.

Your landing page might be doing exactly this. Selling intrigue when it should be describing a specific pain.

I've watched this happen with my own tools. You build something, write a landing page that sounds compelling, and attract exactly the kind of person who appreciates a clever product description. Appreciates it, bookmarks it, and never thinks about it again. The landing page did its job. Just the wrong job.

But the trailer problem goes beyond landing pages.

It applies to content too. Blog posts, tweets, newsletters. A sharp essay about startup metrics might attract people who enjoy reading sharp essays about startup metrics. Whether those readers are actually indie hackers with problems to solve, or just people who like contrarian takes over morning coffee, is an open question.

I think about this with my own writing. An article that gets widely shared because the framing is clever isn't necessarily reaching the people who'd benefit from the tools I build. The content might be doing the same thing as the landing page: filling the room with an appreciative audience that was never going to convert into the community I'm actually trying to build.

The pattern repeats everywhere once you notice it. A photographer whose stunning portfolio attracts clients who want to hire someone with a completely different style. A restaurant that looks incredible on Instagram and fills seats with people who came for the aesthetic, not the food. The signal that looks like demand is actually just curiosity wearing a mask.

The One Question Worth Asking

When you talk to signups who didn't convert (and you should), the typical questions are: "What features would make you upgrade?" or "What didn't you like?"

Both assume the product was close. That some tweak would tip them over.

Try this instead: What were you trying to accomplish before you found us?

A clear, specific answer ("I was spending three hours a week manually reconciling two systems") means this person had a real problem. A vague answer ("just exploring," "checking it out") means this was a curiosity signup.

Both responses are useful data. They point to different diagnoses.

Clear answer, no conversion: your product didn't deliver on its promise. That's a product problem.

Vague answer, no conversion: you attracted the wrong people. That's a positioning problem.

One catch. People don't like admitting they signed up for something on a whim. Ask someone why they signed up and they'll often construct a reason after the fact. Oh, I was looking for a way to organize my client notes. Maybe they were. Or maybe they're being polite, and the real answer is they saw a tweet about it and figured they'd check it out someday.

The sharper signal isn't what they say they were doing. It's how specific the answer gets, and whether they can describe the workaround they were using before they found you. Someone with real pain can describe the duct tape in detail. Someone rationalizing will stay general.

Here's why zero out of a hundred almost always points to positioning: people with genuine pain have surprising tolerance for imperfect products. If your tool solved even part of their problem, a few would convert despite rough edges, confusing onboarding, missing features. Zero suggests the pain wasn't there to begin with.

Why Signups Feel Like Proof

This misdiagnosis persists because signups feel like validation. Every notification triggers a small hit of encouragement. Numbers rising. People interested. Must be on the right track.

But signing up is the lightest commitment someone can make online. It costs nothing and takes ten seconds. Comparing "I typed my email into a form" to "I believe this will solve a real problem in my life" is like comparing a bookmarked restaurant to a reservation for four. One is interest. The other is intent.

I recognize this because I'm on both sides of it. I sign up for things constantly. A new productivity tool, a design app, a course on something I'm curious about this week. Most of the time, I have no real problem to solve. I'm just interested. I'm the curiosity signup in someone else's database, and I know exactly how little that signup means.

The danger: building your roadmap on curiosity data. Optimizing onboarding for people who were never going to convert is like adjusting the focus on a camera pointed at the wrong subject. The image gets sharper. The subject is still wrong.

What the Zero Is Actually Telling You

Here's a rough test. Try to get a few of those hundred people on a call. (This is harder than it sounds, especially with curiosity signups, but even two or three conversations reveal a pattern.) Ask them the question.

If most can describe what they were struggling with before they found you, your product has a real audience. Maybe it needs work, or the pricing needs adjustment. Solvable problems.

If nobody can tell you what problem brought them there, the people you've attracted don't have the problem you built for. No amount of funnel optimization fixes that.

This diagnosis often means starting further back than you'd like. Instead of tweaking dashboards, you need to reconsider who the product is for and make sure your message reaches them specifically.

The good news, usually: repositioning is a smaller job than rebuilding. The product might be fine. The people finding it just aren't the ones who need it.

But.

Sometimes repositioning is how you discover the uncomfortable thing. You narrow your message, aim it at the people with real pain, and find out there aren't enough of them. Or that they already have a solution they're fine with. Or that the problem is real but not $15-a-month real.

I've been there. You build something, realize the audience is wrong, reposition to find the right one, and learn that the right audience is a room of twelve people. That's a different problem than a conversion problem. And it's one you can only discover by doing the hard work first: figuring out who actually needs this, then rewriting everything to speak directly to them.

Zero out of a hundred is a diagnostic result. Read it correctly and it tells you exactly where to look next. Sometimes that's a better landing page. Sometimes it's a harder conversation about who this is actually for, and whether enough of them exist.

Rabbit Hole

If you're rethinking how your product connects with the right people, Your Users Need Two Aha Moments explores why the conceptual aha on your landing page decides everything before someone even signs up. And if you're questioning the idea underneath your product, The Idea Is the Product Now looks at why what you choose to build matters more than how well you build it.

Multiple SaaS benchmarking studies (First Page Sage, Userpilot, ChartMogul) converge on 18-25% as the typical trial-to-paid conversion range, with opt-in trials (no credit card required) averaging around 18% and opt-out trials averaging closer to 49%.

You Don't Want What You Think You Want

2026-03-31T04:56:00Z

You've been building toward a specific outcome for months. What if the outcome was never the point?

You hit the milestone. The revenue number, the launch, the thing you said would change everything. And for a moment, it does. A flicker of satisfaction. Maybe an hour of genuine excitement.

Then a strange flatness. Like arriving at a destination and realizing you don't recognize the place.

What Every Want Has in Common

You've been shipping. Features, campaigns, outreach. You have a clear picture of what success looks like. But trace that picture to its root and you'll find something interesting.

Every desire you've ever had is a desire for an experience.

The desire for a profitable company is really the desire for the experience of security, creative autonomy, or recognition. The desire for a house is the desire for the experience of stability or belonging. Ten thousand followers? That's the desire for the experience of being heard.

This holds across every category. Tangible goods, achievements, relationships, creative work, freedom, legacy. Strip away the object, and there's always an experience underneath. The feeling of safety. The rush of mastery. The warmth of connection. Even wanting to "leave a legacy" is about the present experience of believing your life matters.

A philosopher once proposed a machine that could simulate any experience perfectly.¹ Plug in, and you'd feel everything you've ever wanted to feel. Most people refuse. His point: we must want something beyond how things feel. Maybe. But even the pull toward "realness" is something you feel. You can't want anything, even things beyond experience, without going through experience to get there.

In practice, every desire passes through experience. Even the ones that might point beyond it.

The Desires You Inherited

If every desire passes through experience, one question becomes unavoidable: whose experience are you chasing?

A founder reads about someone's $10M exit and feels a pull. What they're really feeling is desire for the experience they imagine that exit would bring. Freedom, validation, options. But that imagination was assembled from someone else's highlight reel. The experience they're chasing is a projection.

Rene Girard called this mimetic desire.² His argument: we rarely generate wants from scratch. We absorb them from the people around us, from culture, from social media, from family. The absorption is so gradual that borrowed desires become indistinguishable from genuine ones.

And the most dangerous borrowed desires don't look borrowed at all. They sound profound. "I want to make an impact." "I want financial freedom." "I want to build something meaningful." These can be deeply authentic. They can also be mantras you adopted because they sounded right, because they performed well in your social circle, because everyone you admire seems to want them too.

The Experience Audit

Here's a test I keep returning to.

Name the want. Be specific. "A successful SaaS product" is more honest than "success."
Trace it to the experience. What would this feel like, day to day, once you have it? Not what it "means" abstractly. What it feels like in your body at 2 PM on a Tuesday.
Check the source. Have you actually tasted this experience before, even briefly? Or is your entire picture constructed from podcasts, Twitter threads, and other people's stories?
Test the shortcut. If the desire is about the experience, can you get that experience another way? Sooner? Without the three-year detour?

Step 3 is where most borrowed desires collapse. You realize the experience you're chasing is a fantasy assembled from other people's narratives. Not a memory. Not something your body recognizes.

Step 4 is where it gets liberating. Sometimes the experience you actually want is available right now, through a completely different path.

A caveat: some untasted desires are genuine. The question isn't whether you've had the full experience, but whether your picture of it comes from your own intuition and small encounters, or wholesale from someone else's narrative.

The Freedom Trap

I see this pattern constantly among indie hackers. Someone says they want freedom. They build a product, optimize for passive income, grind for years. Then they get there, the business runs itself (as much as possible), and they feel... restless. Lost.

Because "freedom" was a word. The experience they actually wanted was creative engagement, the feeling of solving interesting problems every day. And they designed a life that optimized that away.

The desire was real. The translation was borrowed.

This happens with every abstract goal. "Impact" might mean the experience of watching someone's face light up when your tool solves their problem. Or it might mean the experience of seeing your name attached to something big. Different experiences and different life designs. But we collapse them into one word and assume we know what we mean.

Build Toward What You've Actually Tasted

If you're building a product, a company, a creative practice, you're investing thousands of hours. Those hours are being exchanged for an expected future experience.

Worth spending thirty minutes asking: is that experience one I've actually felt and wanted more of?

The founders who seem most alive aren't the ones hitting the biggest milestones. They're the ones whose daily work generates the experience they were after in the first place. They wanted the experience of building, and they're building. They wanted the experience of teaching, and they're writing. The destination and the journey produce the same feeling.

Every desire is a desire for an experience. Trace yours to the root. If the experience you find there is one you've tasted, felt in your bones, and wanted more of, want a bigger version of, go. Build toward it with everything you have.

If it's a picture assembled from someone else's story, pause. The gap between what you think you want and what you actually want is where most quiet suffering lives. Not dramatic failure. Just a persistent whisper: this should feel better than it does.

Robert Nozick's "Experience Machine" thought experiment, from Anarchy, State, and Utopia (1974). Nozick argued that most people would reject perfect simulated experiences, suggesting we value something beyond how things feel. The counter: even that preference for reality is itself accessed through experience.
Rene Girard's theory of mimetic desire, developed in Deceit, Desire, and the Novel (1961). Girard showed that desire is fundamentally imitative, that we learn what to want by watching others. Most of what feels like personal ambition is actually social contagion.

Rabbit Hole

If this made you question where your goals come from, you might enjoy these:

The "Hell Yes or No" Test Is Actually About Something Deeper explores a powerful diagnostic for separating genuine excitement from obligation.
Why the Most Consistent People Don't Need Discipline looks at what happens when your goals align with what you truly want.
Stop Fighting the Feed, Fix the Pull examines why distraction vanishes when your life generates its own pull.

Every Venture Is Either a Commodity or a Brand

2026-03-26T05:59:00Z

AI didn't create this split. It just burned away everything that let you ignore it.

Every few weeks, a new AI tool launches that replicates what some existing business does. Faster. Cheaper. Sometimes better. Watch the reactions carefully. Some founders panic. Others barely shrug.

The difference has nothing to do with how good their product is.

You've built something people pay for. A SaaS tool, a service, a content product. It works. Customers like it. Then someone ships an AI-powered version of your thing over a weekend. Or a well-funded team clones your core features in a single sprint.

The usual advice is to "add AI," "move faster," or "find your moat." All of which sounds reasonable and misses the point entirely.

The Oldest Split in Commerce

Every venture, since the first merchant set up a stall, has been one of two things: a commodity or a brand.

A commodity competes on price, speed, and features. A brand competes on trust, taste, and identity. No third category. The successful ones always knew which game they were playing.

For decades, though, the line was blurry. Building software, for example, was hard enough that the act of building itself created a temporary moat. If you could ship something that worked, that alone was differentiation. The effort required to replicate your product was your shield.

AI dissolved that shield.

Building is drastically cheaper now, and for anything straightforward, approaching free. Competitors can replicate your core features using AI-driven development in days. And suddenly, ventures that thought they were brands are discovering they were commodities all along. They just couldn't tell, because the difficulty of building masked the absence of anything deeper.

What Happened to Stock Photography

Photography has been part of my life for decades, so this parallel became obvious early.

Stock photography was a massive industry. Getty Images and Shutterstock built empires on it. Photographers made a living shooting generic business scenes, landscapes, food plates, team-at-desk compositions.

Then AI image generation arrived. Midjourney, DALL-E, and their successors could produce a "diverse team collaborating in a modern office" in seconds, for pennies. The market didn't just shrink. It collapsed in the middle. Shutterstock contributors went from earning hundreds a month to single digits.¹ Getty and Shutterstock were forced into a $3.7 billion merger in early 2025, scrambling to strip $150-200 million in overhead while trying to rebrand as "AI content marketplaces."²

Here's what most people miss: fine art photographers with distinctive styles? They're doing fine. Some are doing better than ever. Nobody hires a portrait photographer or visits a gallery for generic output. They go for a specific vision, a specific eye, a way of seeing the world that belongs to one person.

Stock photographers were commodities selling a product anyone could produce given enough tools. Art photographers were brands offering something only they could create. AI didn't invent that split. It just made pretending impossible.

And this pattern keeps repeating. Software, services, content, consulting.

The Dead Zone

Most ventures live in a dead zone between commodity and brand.

They have some brand elements: a founder's personality on social media, a community Slack channel, a distinctive color palette. All layered on top of a fundamentally commodity product.

This middle ground used to be viable. You could survive there for years, even thrive. AI is making it lethal.

The brand elements aren't strong enough to survive feature parity from AI-native competitors. The commodity elements aren't efficient enough to survive price competition from tools that cost a fraction of yours. Squeezed from both sides.

And the instinct to "just add more brand stuff" doesn't work. You can't bolt brand onto a commodity product like adding a feature. Brand comes from genuine conviction about how a problem should be solved, built over time, proven through consistency. It's structural. Either it's in the DNA or it isn't.

If you want the AI-specific version of why brand alone is not a moat, read The AI Moat You Can't Buy.

The Test

Remove your product's features, speed advantages, and pricing. What's left?

If the answer is "nothing," you're a commodity. That's fine. Walmart is a commodity business. So is most of cloud computing. Commodities can be enormously profitable. The strategy is clear: optimize relentlessly, scale hard, win on cost.

If something remains, a point of view, a specific audience that identifies with what you represent, a way of solving the problem that some people love and others genuinely don't get, you might have a brand. Different strategy: deepen the conviction, attract the right people, let the wrong ones leave.

Intellectual property can blur the line. Patents, trade secrets, proprietary processes. Coca-Cola has guarded its formula for over a century. And yet Pepsi routinely beats it in blind taste tests.³ The two colas are practically indistinguishable in the lab. Coca-Cola dominates the market anyway. That gap between the tongue and the wallet? Pure brand. The secret formula protects the commodity layer. The brand is what makes people reach for the red can.

IP slows down replication. Brand makes replication irrelevant.

Three questions to sharpen which side you're on:

If a competitor replicated every feature of your product tomorrow, what would your customers miss?
Can you describe your approach in a way that would make some people disagree?
Would your best customers recommend you even if a cheaper alternative existed?

Three "nothings" means commodity. Build for that. Something specific, something opinionated, something that would start an argument? You have the seed of a brand. Build for that instead.

If you want to pressure-test that honestly, use Where Do You Fall on the Premium–Commodity Spectrum? Free Tool.

Choose, or Get Chosen For

The dangerous move isn't being a commodity (though AI keeps thinning those ranks). The dangerous move is being a commodity that thinks it's a brand. You end up with the cost structure of a brand and the defensibility of a commodity. That's the dead zone. AI doesn't just expose it. It collapses it.

Every founder now faces this question, and it's worth answering honestly: are you building something people choose, or something people use until something cheaper shows up?

The answer shapes everything. Your pricing, your marketing, your hiring, your product roadmap.

Pick one. Go all the way.

Rabbit Hole:

Go Ahead, Build What Already Exists: A "saturated" market probably has room for your version. If you meet one condition.
The New Bottleneck: AI made building easy. Making anyone care is the new hard part.
The $5,000 Problem (Includes free tool)

Kaptur, "The Silent Collapse: Generative AI's Erosion of Photo Licensing Revenue." Shutterstock contributors reported dramatic revenue drops as AI-generated imagery flooded the market, with some seeing monthly earnings fall from hundreds of dollars to single digits.
Getty Images and Shutterstock announced a $3.7 billion merger in January 2025, aiming to cut $150-200 million in duplicate overhead over three years while repositioning as an AI content platform.
The "Pepsi Paradox": in blind taste tests, participants consistently prefer Pepsi or can't distinguish the two. When brands are visible, Coca-Cola wins overwhelmingly. fMRI studies show the Coca-Cola brand activates memory and emotion centers in ways Pepsi doesn't.

mvrckhckr

What Survives When Anyone Can Build Anything

The part people actually buy

Cheap construction changes the buyer's math

The Ownership Test

The mirror question

AI widens the gap between demos and responsibility

What buyers are really outsourcing

The winners will define smaller promises

Rabbit hole

Footnotes

Not All Uncertainty Deserves Respect

Grey Feels Important

Some Questions Are Just Early

Other Questions Are Low Leverage in Disguise

The Grey Test

When Overthinking Becomes a Hiding Place

Rank the Question Before You Answer It

Rabbit Hole

Footnotes:

Can AI Fix SaaS?

The Dirty Secret of Platform Growth

A Problem Older Than Software

Why SaaS Missed Its Container Moment

The Protocol Designer That Doesn't Need a Committee

The Brick Maker's Edge

The Trap Inside the Promise

The Conductor (Sometimes)

Two Forces Pushing Back

Rabbit Hole

A Good Product Manager Already Built It. And Found the Bugs.

Handoffs Existed for a Reason

Vibe Coding's Natural Winners Aren't Engineers

Squeezed From the Side

Four Things the Prototype Still Can't Touch

One Honest Question Worth Sitting With

Rabbit Hole

What AI Actually Searches When It Helps You Think

Knowledge You Can't Quite Reach

The Click That Lies

Two People, Same Tool, Different Universes

What Your Thinking Partner Can't Retrieve

What Changes

Rabbit Hole

Footnotes

Where Automation Stops and Real Growth Starts

The Bounded Game

The Unbounded Game

When Value-Based Pricing Sells Itself

The Part Nobody Talks About

The Discipline of Saying "Not Yet"

The Arithmetic of Ambition

Rabbit Hole

Footnotes

You Can't Afford Most Books

The Purchase That Replaces the Reading

What a Book Actually Costs

Tsundoku: A To-Do List Disguised as a Collection

Three Questions Worth More Than the Book

The Bet You're Actually Making

Rabbit Hole

Footnotes

No Circle Is Round and AI Isn't Deterministic. So What.

The standard you're demanding

Zeno never shipped

What engineers actually do

Engineering the threshold

Which jobs clear the threshold today

The real question

Rabbit Hole

The Death of "Pretty Good"

When "Pretty Good" Became Table Stakes

Medicine Already Ran This Experiment

The Two Edges AI Can't Reach

The Generalist vs Specialist Debate That Proves the Point

Both Ends Have a Trap

The Unstated Baseline

Pick Your End

AI Hallucinations Start at the Interface

The answer box teaches the wrong lesson