I think back to the checklist I built to cut down on delivery errors. Every time a project came in, you'd run it through three stages—requirements, behavioral consistency, and payment flow—a process only you used. It cut your working time in half and nearly eliminated rework requests. Then a colleague who occasionally sent work your way saw it and asked if he could use it too. You sent him the file without giving it much thought. Three months later, that checklist—with your name stripped out—was making the rounds on two different online communities.

It stung. But the note you wrote to yourself that night said something different from how you felt. Two things had become clear: that something built for internal use had people outside willing to pay for it, and that if you didn't design how it left your hands, someone else would set its price. How you decide when to release an internal asset—and in what form—is where today's conversation begins.

What It Actually Means to Use Something Twice

Using something twice means converting a cost-saving tool built for internal use into a component of a revenue-generating product. Externalization is the work of separating the transferable parts of an output that was tied to your own context and reshaping them into something tradeable. What happened to your checklist was the first half of that conversion. The second half was yours to design.

The day you built it, the checklist was a time-saving device. Its value had a ceiling: your hourly rate multiplied by hours saved. Your colleague's request was the first signal that the thing could carry a different name. When someone facing the same problem reaches out, the checklist belongs on an externalization candidate list. The moment a tool acquires a market, a metric, and a delivery mechanism, it becomes a component of a revenue product.

"Tradeable form" needs unpacking. The process has to run without depending on your folder structure, your private shorthand, or your clients' names. It needs to be a self-contained unit—one where buyers get the promised result without purchasing anything else. And the boundary has to be explicit: what's included in the product, and what requires a separate engagement. Your checklist failed on the first count. The step descriptions were laced with abbreviations only you understood, and people who downloaded the community version reportedly got about halfway through before giving up. What circulated out there was raw material, not a product. The distance between raw material and finished product is the actual labor of externalization.

Ideas Don't Wear Out

The reason this conversion is especially powerful for solo operators comes down to growth economics. Economist Paul Romer built his endogenous growth theory on the observation that ideas are non-rival goods—a finding that earned him the 2018 Nobel Prize in Economics. Bread: if I eat it, you can't. A checklist: a thousand people can use it simultaneously without diminishing mine. Because the marginal cost of replication approaches zero, the per-unit cost of a knowledge asset falls as usage rises. Revenue from custom project work is capped by your time. Revenue from a checklist is not. The compounding power of a solo business lives in that gap.

Non-rivalry also changes how you price things. When you sell time, pricing starts from the hours you put in. But when an asset costs almost nothing to replicate, the basis for pricing shifts from your production cost toward the value the buyer receives. If your checklist saves a buyer five hours a month, the pricing anchor isn't how long it took you to write it—it's those five hours. The implication of near-zero replication cost: you can grow volume without cutting price.

The most visible large-scale example of this path is Amazon. In 2003, an internal mandate required every team to expose its functionality only through defined APIs. The computing infrastructure Amazon had built to run its own e-commerce operation was restructured under that standard into something any team could access—and in 2006, it opened to the public as AWS. Infrastructure built to serve internal operations became a product with external pricing. One condition is worth noting: Amazon externalized only after its tools had proven themselves at scale inside the company. Externalizing something that hasn't been validated internally isn't using something twice—it's selling something you've never properly used once.

The underlying principle isn't new. For a long time, though, the high cost of building the first copy meant the benefits of non-rivalry accrued mainly to large software companies and platforms. Individuals who couldn't absorb that cost stayed in the business of selling time. Artificial intelligence has changed that calculus. Building the first copy of a checklist or a structured data set now takes a fraction of what it once did, which compresses the cycle time of build-once, deploy-twice. The principle is unchanged; the rotation speed has changed—and that shift has put the principle within reach of a single person.

The same economics carries a warning. In a freely entered market, the long-run profit of an undifferentiated product trends toward zero. Procedural assets are easy to copy, so any advantage from an externalized checklist has an expiration date. Plan for what happens after imitators arrive. The procedure document itself can be copied. The record of failures, buyer questions, and edge cases accumulated while building it cannot. The next version of an externalized product comes from that record, not the document. When revised editions include explanations of exactly where buyers got stuck, the copy and the original diverge at the level of source material. If your advantage is time-limited, start collecting material for the next edition the moment the first one goes on sale.

One more distinction matters here. If what you're externalizing is a general procedure—knowledge others could reproduce given time—release it to market. The going rate for that kind of work will likely be compressed by general-purpose tools within a few years. If the revenue is going to fall anyway, converting it to a product before someone else does is the better move. Conversely, specific assets—client data, proprietary relationships, accumulated transaction history—can't be copied, so keep them inside and use them as raw material for the next product. This maps directly onto the distinction labor economist Gary Becker drew between general and specific human capital. In the checklist example: the build verification procedure was general; the client-by-client operational data was specific. Because the two could be separated cleanly, externalization wasn't just an option—it was the right call.

Three Things to Check Today

Whether the productivity tool in your hands right now is a candidate for market release comes down to three things you can write out.

First, lay out the internal tools and procedures you built last quarter and mark whether anyone outside your immediate work has ever reached out about any of them. A direct request puts something at the top of the list. No request, but visible demand on communities or in search results, puts it second. No signal at all: keep it internal, add it to a running candidate list, and wait. You already recovered the cost of building it through your own work, so the cost of listing it is just that one line.

Second, take your top candidate and write out which parts are general procedure and which are specific assets. What remains after you strip away your folder structure, your shorthand, and your client names is general procedure. What collapses without those things is a specific asset. If the two separate cleanly, refine the general procedure and release it; keep the specific asset inside. If they don't separate cleanly, that's a hold. This one step is what prevents you from handing over the source material for your own competitive advantage in a moment of revenue enthusiasm.

Third, set a loss ceiling on the refinement work before you start. Turning a procedure you know by instinct into something a stranger can follow takes longer than it looks. You have to write down assumptions that live only in your head, watch unfamiliar users get stuck, and revise the documentation accordingly. For those months, the revenue contribution from this asset is zero and your available time for core work shrinks. Set a concrete limit before you begin—say, eight hours a week for three months—and that number, not your mood mid-project, decides whether to continue or cut it. The time to draw the line is before you start. A limit drawn in the middle is already under the influence of sunk-cost thinking.

From Productivity to Profitability

Most people hit the same fear before they externalize. If I sell the checklist, clients will use it to build things themselves and stop hiring me. But consider: you entered the market with AI tools already cutting into someone else's workflow. Your advantages will erode the same way. The routine work most vulnerable to displacement is already shrinking; the externalized product is what fills that space with revenue that isn't tied to your hours.

The line between productivity and profitability sits here. Using a tool to save your own time is productivity. Taking the output of that tool and generating revenue from it independent of your time—that's profitability. AI has collapsed the cost of making things; it has simultaneously raised the value of the judgment that determines what to release, what to protect, and when.

This series draws from a single manuscript that applies standard frameworks from accounting, economics, management, and investment to the problems of a one-person business—without keeping those disciplines in separate silos. If you now have the blueprint for externalization, what remains is the terrain it sits on. The next installment looks at how Korean structural conditions—business registration formats, tax classification, platform payment schedules, and a shrinking population—fix certain variables and open certain opportunities on that same blueprint. If you've decided to sell what you've made, the next piece is your first step onto that ground.

Appendix: Key Concepts

- Non-rivalry of Ideas and Endogenous Growth Theory — Framework established by economist Paul Romer (JPE 1990): ideas are non-rival goods—one person using them does not diminish their availability to others, allowing simultaneous use by many. Because the marginal cost of replication approaches zero, a knowledge asset's per-unit cost falls as usage increases, making it a compounding asset for solo operators. 2018 Nobel Prize in Economics. 

- General vs. Specific Human Capital — A distinction drawn by labor economist Gary Becker: general competencies with market value anywhere, versus specific competencies that derive value only within a particular relationship. In externalization strategy, this provides the basis for separating general procedures (release to market) from specific assets (keep inside). 

- Internalizing Capabilities into External Services (The AWS Pattern) — Amazon's 2006 launch of AWS, built on computing infrastructure originally developed to run its own e-commerce operations. The key condition—that Amazon externalized only after its tools had proven themselves at internal scale—applies equally to solo operators.