Build it, own it, license it

There’s a new line on a lot of company card statements: what the AI coding tools cost this month. Sometimes it’s a few seats. Sometimes it’s a bill for tokens, the units these models charge by, and it moves from month to month with how much code got written.

Sooner or later someone asks what it bought. It’s the old question about software, build or buy, asked about a new kind of spending. For most small businesses the answer used to be easy: buy. Building meant hiring engineers for months, so you rented what someone else had built, one subscription at a time, and paid for it every month for as long as you used it.

This year the large accounting firms wrote down how AI spending on software should be booked, and they agree on the shape of it. When a company builds software for its own use, the cost of building it can be recorded as an asset and spread over the years the software is used, instead of counted as an expense the month it’s paid. AI tokens can be part of that cost, but Deloitte is plain that a token charge doesn’t qualify just because it can be measured. It has to be directly tied to building a specific piece of software.

So a general AI subscription the whole team uses for everything is an expense, and so are tokens spent keeping existing software running. PwC draws the same line: tools dedicated to building something specific may count; tools for general use usually don’t. In practice that means tracking which project every token went to, and what kind of work it was.

The rule about when that starts is changing too. Under a new standard, ASU 2025-06, a company starts recording the asset once it has committed to the project and it’s probable the software will be finished and used. It’s required for years beginning after December 15, 2027, and companies may adopt it sooner.

Taxes run on separate rules. Since the tax law signed July 4, 2025, US companies can deduct domestic software development in the year they spend it, or choose to spread it over at least five years (PwC, Crowe). The books and the tax return can treat the same spending differently. Your accountant decides both.

Think of it as housing. A subscription is rent: the same payment every month, nothing to show for it when you stop, and the landlord decides when the price goes up and what the rooms look like. Software you build is a house you own. It costs more up front, it needs looking after, and it’s yours.

Recording it as an asset and spreading the cost over its useful life is the accountant’s way of saying the same thing. A house is worth owning only for as long as it stands, and so is software. That’s the part that decides whether token spending was an investment or just a bigger bill.

AI can write a great deal of code quickly. Code nobody on the team understands, with no tests and no record of why it does what it does, is a house built without a foundation. It stands for a while. Then the first real change breaks something nobody can find, and it’s rebuilt. On paper that spending was an asset. In fact it was rent, paid up front.

What makes software last hasn’t changed because a model typed it. Write the test before the code, so what “working” means is settled before anyone argues about it. Write down what each change is meant to do, and what would prove it wrong, before building it; we give away a kit for that. Build a small piece, show it working, and only then build the next one, which is how we run our own work.

If the spending only becomes an asset when the code lasts, then who holds the budget matters more than how big it is. A seat for everyone produces a lot of code. A budget in the hands of the engineers who know what good code looks like produces software that stands up: tested, readable by the next person, and built for one project you can name.

That’s also what the accounting asks for. Spending tied to one piece of software, tracked by project and by the kind of work, is the spending that can be counted as an asset. Spread across everyone for everything, it can’t, and it shouldn’t be.

So measure the budget by what lasts, not by how much code came out. How much of what was built this quarter is still running a year later, unchanged except on purpose? That number is the useful life, and it’s the one worth watching.

Once you own a house that stands, you can rent out a room. Software you built well can be licensed to other businesses in your trade, and they pay you for it, the way you used to pay someone else.

We’ve done this once. We built a set of tools for Sara Paula Hoffman, a visual artist: her catalog, her prices, the questions waiting on her, the shows she might enter. She called it her digital studio. Now we offer the Digital Studio to other artists together. Paula co-owns it, and every artist who licenses it pays her a fee.

That’s the change worth noticing. The smallest people in an industry, an artist, a landscaper, a shop of three, have always been the ones who rent. When building costs less, they can build what fits the way they actually work, own it, and get a share of what it earns when others in their trade want the same thing.

If AI-written code turns out not to last no matter who directs it, the asset argument falls apart, and renting stays the better deal. If auditors read the new guidance more narrowly than the firms that wrote it, less of the spending will count. If subscriptions keep getting cheaper faster than building does, buying wins again on price alone.

And licensing is a business, not a side effect: someone has to support the people who license it. One licensed product, built with one artist, isn’t proof that it scales. It’s the first test, and we’ll report how it goes.

Build what lasts, keep it, and when it’s good enough, let others pay to use it.