Research once, harvest three ways.

That is the integration gap. Adopting AI now means paying $20 to $30 a month for a chat subscription, which almost anyone can do. Integrating it means changing how the work actually moves through the company, which almost no one has done. The JPMorgan researchers put it plainly: differentiation "may depend less on whether a firm adopts AI and more on how effectively it integrates AI into operations."

The gap is widest for the smallest firms, and not for the reason you would guess. Employer firms adopted AI at nearly twice the rate of solo operators (26.1 versus 15.3 percent by December 2025), and the report ties the difference to capacity rather than money: a sole proprietor "managing all business functions themselves" lacks the bandwidth and the time to integrate a new tool, regardless of what it costs. The bottleneck is not the price of AI. It is the hours it takes to wire AI into a working business.

This piece is about an operating model that attacks that bottleneck from the inside, and the discipline that makes the model pay for itself. Rarefied Earth runs both on its own pipeline. Neither is sold or packaged for anyone yet; the firm is the only company running it, which is the point.

Build it for yourself first.

The first rule is dogfood-and-productize: build the tool for your own company, run it until it earns its keep, and only then consider packaging it for someone else. The company is always its own first customer.

The pattern has a long pedigree. Slack started as the internal communication tool of a game studio whose game failed. Basecamp started as the internal project tracker of a small design shop. Mailchimp grew out of a side feature of an agency. In each case the team built the thing because they needed it, used it for years, and discovered a product only after the internal version had been beaten into shape by daily use. Dogfooding, running your own product in your own operations, is now standard practice at companies like Cloudflare for exactly this reason: the people who feel the bugs are the people who can fix them.

There is an honest counterweight, and it belongs in any sober version of this argument. Most internal tools do not become products. The discussion threads on this are full of engineers who shipped an internal tool, assumed the market wanted it, and learned that their workflow was theirs alone. The model only works if you treat "this stays internal forever" as a normal, common outcome rather than a failure. The internal tool was worth building because it improved your own operation. Whether it ever becomes a product is a separate question with a higher bar.

So the model has a built-in resting state. A tool you build for yourself starts as internal-only and stays there by default. It graduates toward being a product only when the same need shows up a third time, in your own work or a client's. Until then it is overhead you have already paid for, not a product you are obligated to sell.

The harvest: research once, use it three ways.

The second rule is what makes the dogfood model affordable for a one-person or small operation: when you do the research for a piece of work, harvest that single effort more than once.

The idea is borrowed from a content-strategy pattern that public broadcasters formalized years ago, Create Once Publish Everywhere: write one structured source, then render it to the web, the app, the newsletter, and the partner feed without rewriting it each time. The same principle generalizes past content. A serious unit of work, the kind where you spend real hours reading the landscape, comparing tools, and deciding how something should function, produces three different things if you let it:

• An article. The reasoning you did is the article. The comparison you ran, the dead ends you hit, the decision you reached. Written down once, it becomes public evidence that you understand the problem, which is the cheapest marketing an operating company has.
• An internal tool. The decision you reached gets implemented as a script, a checklist, or a workflow your own company runs. This is the dogfood artifact from the first rule.
• A reusable module. If the tool survives contact with your own operation and the same need appears elsewhere, it becomes a packaged version someone else could install.

The research is the expensive part. The three harvests share it. You are not writing an article and separately building a tool and separately designing a product; you are doing the work once and pointing it in three directions.

The trap in this model is drift. You write the article, ship a thin version of the tool, sketch the product, and then the three fall out of sync. The article describes a version of the tool that no longer exists. The product sketch promises something the internal tool never actually did. The fix is mechanical: keep one short record per unit of work that links all three harvests and their current state, so a stale article or an over-promised product is visible at a glance. A spreadsheet row does the job. The record is the thing that keeps honesty enforced when the work moves fast.

What an operator can do with this on Monday.

You do not need any special software to run this. The discipline is the product.

• Pick one real piece of work you already have to do this week. Not a hypothetical; a decision you are already paying for, like choosing a tool or designing a process.
• Do the research once, and write down the reasoning as you go. The notes you take to make the decision are 80 percent of an article. Capture the options you rejected and why; that is the part readers cannot get from a vendor.
• Implement the decision as something your own company runs, even if it is a one-page checklist. Use it for a month before you believe it.
• Keep a one-line record per unit of work: what you researched, where the writeup lives, what you built, and whether it is internal-only or has shown up enough times to be worth packaging. Review it monthly and kill the rows that drifted.
• Default everything to internal-only. Promote toward a product only on the third sighting of the same need. Resist the urge to sell version one.

For a firm in a knowledge-intensive trade, where AI adoption is already high (professional services were at 30.3 percent by the end of 2025), the harvest discipline is a way to turn the integration work you are forced to do anyway into public proof and reusable assets. For a firm in a slower-adopting trade like construction (8.9 percent), it is a way to integrate AI without hiring a team to do it: build small, run it yourself, write down what worked.

What this does not promise.

The numbers above are real and dated; the AI-adoption figures are from a single institutional study published in April 2026, and adoption curves move. The revenue figures floating around the productized-services world (one operator reporting roughly $400K a year on a $750-a-month subscription, for example) are self-reported anecdotes, not benchmarks, and are quoted here as anecdotes only.

The model itself has costs the cheerful version hides. The dogfood period is unpaid; you carry the tool on your own books before it returns anything, and most tools never return more than the internal time they save. Writing down your reasoning honestly takes longer than not writing it down. And the discipline only holds if you actually run the monthly review and let internal-only stay internal. Skipped, the model degrades into a pile of half-built tools and stale drafts that contradict each other.

What it does promise is leverage on hours you are already spending. The integration work is not optional; the firms that pull ahead are the ones integrating, not the ones adopting. If you have to do that work anyway, do it once and let it pay out more than once.

Sources and further reading.

Related work.

This is the operating-model companion to the firm's broader argument about why agents stall without an operating layer underneath them. The field guide on why most company AI projects stall makes the case for the substrate itself, and the guide to the second brain a business runs on covers the knowledge layer the harvest record lives in.