builders have different pain

Ask a hairdresser what's painful about running her salon and she'll tell you, in detail, quickly. The booking system double-books. Emails are annoying and time-consuming. She has hated these things for years, she can verbalise them, and she will hand you the list. Accelerators teach founders to ask about pain because, on this class of users, the question works.

I've spent the last month asking designers the same question.

"What's the most painful part of this process for you?"

"It's not painful. It was and then I made a thing for it."

They weren't saying this 6 months ago. They're starting to sound like builders. The pain question assumes a buyer who can't build. Builders don't experience pain the way hairdressers do.

non-builders have first-order pain

For the hairdresser, pain accumulates. They don't spend all day thinking about SaaS products and building them, don't feel like 'tech people' and are anxious about technology, so problems pile up and are suffered.

The demand researchers have a clean model for this: you switch when the push of your situation plus the pull of a new solution beat the anxiety of the new thing plus the habit of the old one.¹ Years of queued pain make the push enormous. He can articulate it clearly because it's hurting him directly. It's a first-order pain.

builders have second-order pain

A builder drains the queue. Anything that hurts enough is a source of things to build, so they fix them. Building is fun: you make the jig, you feel clever, and the original pain dies.

Building stops being fun when other people appear, or when the build is complicated and messy. Maintenance, bug reports, feature requests, permissions, deployments all appear when the jig becomes something the business uses, not just the builder. These aren't experienced as the original pain, they're experienced as an unpaid, un-budgeted job. The pain converted from a problem you could complain about into an unpaid job you gave yourself. They don't call it 'pain', they call it 'work'. It's a second-order pain.

Some builds start and die instead: the graveyard of half-finished scripts, each one marking a problem that was real enough to begin and not worth finishing for a variety of reasons (often because it was more complicated than it initially seemed for it to solve the builder's problem).

A huge band of pain produces no completed builds, because the effort of fixing exceeds what any single moment is worth. The demand literature calls this non-consumption.² Interestingly, this does not always indicate a non-willingness to pay. It only indicates the effort involved in solving it is higher than value of solving it, which is only a problem if the effort involved in solving it is low.

No interview about first-order pains will reveal a second-order pain, they're not experienced the same way.

forty years of jigs

Builders have behaved this way since before Excel. A research field exists on ordinary people making software for themselves, and its recurring finding is that almost nobody who can build, builds. The canonical essay describes "an abyss to cross between using an app and modifying it": you leave the tool you know and set up camp in a programmer's world before your problem comes into view.³ One study counted ~55 million Americans doing real modelling work in spreadsheets against ~3 million professional programmers.⁴ Millions can; few cross. Of those who could, most decline. The researchers who watched office builders up close concluded they were "not simply under-skilled programmers who need assistance." They were domain specialists who stop building the moment their interest runs out.⁵

Self-service went mass once, in spreadsheets. Users never had to cross the abyss, because formulas map onto the task and you build from inside the tool you already live in. Small businesses ran entire operations on sheets built by people who never learned a loop. As an aside, in the biggest public corpus of real business spreadsheets (Enron's because subpoenas 😀) about half contain no formulas at all.⁶ Most artifacts are todo lists. The living jig is rare.

The same study found self-service isn't actually solo. Hand-rolled tools have an ecology: regular users, a "local developer" (the domain insider who's a bit more technical and builds for everyone nearby), and a programmer for the hard parts. The canonical case is a manager named Ray, who built his own spreadsheet models but commissioned the data-entry macros from a programmer in customer support. Macros weren't beyond him; he'd taken the advanced course. He had, in the paper's words, "reached the limits of his interest in programming advanced spreadsheet features himself."⁵

In 2007 a Hacker News commenter told Dropbox's founder the product was pointless, since any Linux user could rig the same thing themselves.⁷ True, and it predicted nothing. Dropbox's buyers were the people who could have built it. Their descendants today skip building their own monitoring and skip buying it too; they self-host open source someone else wrote. Vendor-only shops are 10–17% of orgs in that category, and the self-managed majority runs Prometheus.⁸ The menu has three options, build, assemble, buy, and capable people assemble.

a profession crosses at once

Designers answered the pain question fine until the start of this year. Their medium (Figma) had no build surface, so their pain queued like anyone's. They complained about handoff, about version chaos, about the prototype that took a week to put together in Loveable because it didn't look like their app, and the complaints stacked up where someone could go collect them. Discovery on designers worked like discovery on hairdressers, neither were builders.

Then AI coding recreated the spreadsheet condition inside their profession. The abyss only lifts when you can build from inside a medium you already live in, with primitives that match your task. Prompting matches a designer's task: describe intent in words, judge the result by eye. That is the job. A designer now ships a working prototype by talking to Claude in their own language, without setting up camp in a programmer's world. The end-user-programming crowd called this in advance: the bottleneck was always turning rough intent into formal code, and language models attack that exact step.⁹

So a whole profession is crossing from non-builder to builder at once, the way spreadsheet users crossed in 1985, and unevenly, the way the record predicts. My calls contain all three strata: laggards still queueing complaints who are increasingly rare, experimenters halfway across, and finished local developers building for their whole team.¹⁰

The shrugs in my calls are what mid-crossing sounds like. The pain question doesn't surface anything anymore.

where building stops

Builders stop building when their interest runs out, not when the business problem is solved. The builder gets pulled in by the slice of the problem that looks fun, consumes it, feels clever, and stops. The business problem is still standing; their problem is solved. Ray built the model and commissioned the macros. The designer builds the prototype pipeline and abandons the version history. Everyone builds the demo when they can. Nobody builds the boring bits that allow a product to be used by more than 1 person.

The leftover list barely varies: hosting, persistence, permissions, multiplayer, support, compliance, security. The end-user-programming people call it the glue. Charity Majors has the most honest sales pitch I've read: yes, you can kludge together an open-source version of most of what we sell, here are my notes, godspeed. The product is for people who don't want to be on call for it.¹¹ She knows her users aren't buying Honeycomb because they literally have no telemetry and are flying blind and on fire. They generally arrive already with some sort of solution.

Worth calling out, Klarna went viral in 2024 for "replacing Salesforce and Workday with AI." Klarna replaced Workday with Deel, which is SaaS. It replaced Salesforce with a blend of vendors and in-house data plumbing. By March the CEO was clarifying "so no, we did not replace SaaS with an LLM" and calling the episode embarrassing.¹²

the boring point is the purchase point

Sort every build by two questions. Is it fun, or boring? Is it my problem, or someone else's? The four answers are not equal, and only one of them has an invoice attached.

The moment a second person touches the jig, the work changes. Now there are accounts. Now there are permissions. The beginning of boring. Now there's a bug report from someone who isn't you, and it reads "the box isn't working," and you get to reply "what box" and there's a strange expectation you fix it. That's a job. Solving your own problem pays out in dopamine and sick demos. Solving Kevin's problem pays out in Kevin, who asks for stupid shit, and you are not going to maintain his feature requests out of hours on your own dime and time.

For builders, the individual's relief is the free tier, and money attaches when the thing spreads past them.¹³ Look at where the paywalls sit in developer-adjacent tools: seats, admin, audit, SSO, at markups that spawned an entire website of grievances.¹⁴ The fence goes around the boring quadrant. The fun quadrant is competing with their hand-rolled thing, so it's free.

Something special happens with builders. You need to leave them able to change the thing, because they likely are arriving with a hand-rolled workaround they can change. Removing that is a regression. Spreadsheet-replacement products spent decades dying against sheets their users could reshape the same afternoon. These users pay for tools that kept them in control.¹⁵ Builders will surrender maintenance without a fight. They will not surrender modifiability, and open source owns this population for that reason.

ask about the jigs

The discovery method follows from the rest: don't ask about the pain they have now, ask about the pain they've solved for themselves and pain they solve for others.

What have you built for yourself? What was happening the week you made it? Who else uses it, and who fixes it when it breaks while you're on leave? What do people keep asking you to add? What have you refused to add, and why? Does the business give you time to maintain it, or does it live in your evenings? What did you start building and abandon?

A hand-rolled tool is a problem its builder had, spent time on, and likely never finished solving for the business, just for themselves. The business runs on it, no one maintains it, and its builder needs no convincing about its value. When someone tells you they've hand-rolled something, don't step over it to keep hunting for "pain." You are standing on the pain and holding the solution. It's not just real, it's spec'd out, the thing they need is the thing they built with the boring bits done.

Designers' complaints are about to go quiet and their repos are about to fill up. The pain will be sitting in a repo with a flurry of activity at the start and almost none today, maintained out of hours, by someone who stopped having fun the first weekend they built it.