Think back to the checklist you once built to cut down on delivery mistakes. It was a three-step filter — requirements, behavioral consistency, payment flow — that only you used whenever a new job came in. That single procedure cut your working time in half and all but eliminated rework requests. Then a colleague you split jobs with saw the checklist and asked to use it too, and you sent the file over without thinking twice. Three months later, that same checklist — with your name stripped off — was circulating on two different online communities.
It stung, but the note you jotted down that night was cooler than the feeling. Something you'd built purely for your own use turned out to have people willing to pay for it — and if you don't design how it leaves your hands, someone else decides what it's worth. Deciding when and in what shape to release something you built for internal use is where today's story begins.
What It Means to Build Once, Use Twice
Building once and using it twice means taking a time-saving tool you made for internal use and externalizing it — repurposing it as a component of a revenue-generating product. Externalizing means extracting the part of your output that isn't tied to your specific context, the part other people could use, and reshaping it into something tradeable. What happened to your checklist was only the first half of that transition. The second half was yours to design.
The day you built it, the checklist was purely a time-saving tool for yourself, and its value had a ceiling: your hourly rate multiplied by the hours it saved. Your colleague's request was the first sign it could wear a different label. Once someone else facing the same problem reaches out for it, a checklist needs to be re-filed as a candidate for externalization — and the moment it's attached to a tool, a market, and a way of measuring results, it becomes a component of a revenue product.
"Tradeable shape" is worth unpacking. First, the procedure has to run without depending on your particular folder structure, your verbal habits, or your clients' names. It needs to be a complete unit that delivers the promised result without the buyer having to purchase anything else, with a clear line drawn between what's included in the product and what counts as a separate, billable request. Your checklist failed the very first condition. Shorthand only you understood was scattered throughout the step-by-step instructions, and people who got the version circulating in the community said they gave up about halfway through. What was circulating out there was raw ore, not a finished product — and the distance between ore and product is exactly the amount of work externalization takes.
Ideas Don't Wear Out
Growth economics explains why this transition is especially powerful for solo businesses. Economist Paul Romer built endogenous growth theory on the observation that ideas are non-rival goods, work for which he won the 2018 Nobel Prize in Economic Sciences. If you eat a loaf of bread, no one else can — but a thousand people can use your checklist at once and your own copy never wears out. Because the marginal cost of copying is close to zero, a knowledge asset you build once gets cheaper per use the more it's used. Revenue from contract builds has a ceiling proportional to your hours; revenue from selling the checklist is decoupled from your hours entirely. That decoupling is where a solo business's compounding comes from.
Non-rivalry also changes how you price the thing. Pricing for time-based work starts from the hours put in, but for an asset that never wears out, selling one more copy costs almost nothing — so the basis for pricing shifts from cost to the value the buyer receives. If one copy of the checklist saves a buyer five hours a month, the price should be anchored to those five hours, not to the hours you spent building it. The implication of near-zero copying cost is that you can scale volume without cutting price.
The best-known public example of this path, at the largest possible scale, is Amazon. In 2003, the company issued an internal mandate that every team exchange functionality only through defined service interfaces. On top of that mandate, the computing infrastructure Amazon had built to run its own e-commerce operation was reorganized into something any team — or eventually anyone outside the company — could use, and in 2006 it opened to external customers under the name AWS. Servers and storage built for internal use became a product people paid for from the outside. Note the timing: even Amazon didn't take the internal tool external until it had been proven out in its own operations. Externalizing something that hasn't been validated internally isn't building once and using it twice — it's selling something you've never properly used even once.
The principle itself is old. But because the cost of producing the first copy was high, the benefits of non-rival goods long belonged to big software companies and platform businesses. Individuals who couldn't absorb that first-copy cost stayed stuck selling their time. This is exactly where AI changed things. The time it takes to produce one checklist, one cleaned-up dataset, has dropped to a fraction of what it was, which shortens the whole build-once-use-twice cycle. The principle hasn't changed, but the turnover speed has — and that difference is what put this principle into the hands of a single person.
But the same economics comes with a warning. In a market with free entry, a product that survives on differentiation alone sees its long-run profit converge to zero. Procedural assets are easy to copy, so the edge an externalized checklist gives you is on a timer. That's why it pays to sketch out, in advance, how you'll respond once imitators show up. Someone can copy the procedure document itself, but they can't easily copy the record of failure cases and buyer questions that accumulated while you built it. The next edition of an externalized product comes from that record, not from the document. Once a revised checklist carries annotations on the exact points where real buyers actually got stuck, it's made of different material than a copycat's clone from the start. If the edge is temporary anyway, the fix is simple: while the first edition is selling, start scheduling the collection of material for the next one.
One more distinction matters here. If what you're externalizing is general knowledge — the kind anyone else could produce given enough time — putting it on the market is the right call. That line of work's value is likely to be eroded by generic tools within a few years anyway. If the revenue is going to erode regardless, you're better off converting it into a product before someone else does the eroding for you. Conversely, special assets that can't be copied — data accumulated per client, the relationships behind specific deals — should stay in-house as material for the next product. This maps directly onto the line labor economist Gary Becker drew between general and specific training. In your case, the build-checklist procedure was general; the client-specific operational data was specific. Because you could separate the two — sell the procedure, keep the data — externalizing wasn't just permissible. It was the decision you had to make.
Three Things to Check Today
Whether the time-saving tool sitting in your hands right now is a candidate for external sale becomes clear once you write down just three things.
First, list every internal tool and procedure you built last quarter, and mark whether anyone facing the same problem has ever reached out for each one. Items where someone directly asked are your top-priority candidates. If no one's asked but you can find traces of people searching for that problem in communities or search engines, that's second priority. If there's no trace at all, leave it as an internal tool for now and just note it on a candidate list until a demand signal shows up. You've already recouped the effort of building it through your core work, so the cost of jotting it down is just that one line.
Second, pick one top-priority candidate and split it, in writing, into general procedure and special asset. Whatever survives after you strip out your folder structure, your shorthand, and your clients' names is the general procedure; whatever collapses when you strip those out is the special asset. If the two split cleanly, polish and release only the general procedure and keep the special asset in-house. If a candidate won't split cleanly, that fact alone is grounds to hold it back. This one step is what stops revenue hunger from handing over the entire raw material of your advantage.
Third, set a loss cap on the polishing work before you start. Refining a procedure you know by heart into something a stranger can use takes longer than you'd expect. You have to write down assumptions that only ever lived in your head, watch first-time users hit walls, and rewrite the instructions accordingly. For those first month or two, revenue contribution is zero and only your core-work hours shrink. If you write down beforehand, say, up to eight hours a week for three months, then when the stretch drags on, that line — not your mood — decides whether you keep going or cut it loose. The cap has to be set before you start polishing. A line drawn in the middle of the slog is already under the influence of how you feel.
From Productivity to Profitability
Almost everyone runs into the same fear before externalizing something: if I sell the checklist, won't customers just build it themselves and stop hiring me? But you yourself entered the existing market carrying AI tools, and you entered by eating into someone else's contract work. Just as you got in by cutting into other people's business, your own edge will get cut into the same way. The routine work vulnerable to that erosion is shrinking regardless of what you do, and the new revenue externalization creates fills the time that erosion frees up.
This is where the line between productivity and profitability falls. If you stop at using a tool quickly to save your own time, that's productivity. If you put what that tool produced to work one more time and generate revenue decoupled from your hours, that's profitability. AI has collapsed the cost of building things — but it has, if anything, raised the value of the judgment call over what to release and what to protect.
This series draws on a single manuscript that reassembles standard theory from accounting, economics, management, and investing — without regard for disciplinary boundaries — into a set of problems facing solo businesses. Once you're holding the blueprint for externalization, what's left is the ground that blueprint sits on. The next installment looks at how conditions specific to Korea — business registration types and tax categories, platform payout cycles, a shrinking population — fix certain variables and open certain opportunities on top of that same blueprint. If you've decided to sell what you've built, the next piece is your first step onto that ground.
Concept Notes
- The Non-Rivalry of Ideas and Endogenous Growth Theory — A framework built by economist Paul Romer (Journal of Political Economy, 1990), which holds that ideas are non-rival goods: one person's use doesn't wear them out, so many people can use them at once. This near-zero marginal cost of copying is what turns a knowledge asset built once into a compounding asset for a solo business — one whose per-unit cost falls the more it's used. Awarded the 2018 Nobel Prize in Economic Sciences.
- General and Specific Training in Human Capital — A distinction drawn by labor economist Gary Becker between general competencies, which are valued anywhere, and specific competencies, which have value only within a particular relationship. In designing externalization, this is the basis for separating out general procedures to sell on the market while keeping specific assets in-house.
- Turning Internal Capability into an External Service (the AWS Pattern) — The case of Amazon opening the computing infrastructure it had built for its own operations to external customers as a product in 2006. The timing condition — that Amazon externalized the internal tool only after it had been proven out internally — applies just as directly to a solo business.
