It’s reasonable—if you’re about to hire a software development firm to build you something—to want a sense of how big the price tag will be. But beware: there’s a dangerous assumption hidden in your perfectly reasonable curiosity.

Software development works differently than buying physical assets.

It’s hardly unreasonable to ask how much a car costs, or a house. Even if you “custom order” a house or a car, the price tag is usually still pretty straightforward.

With software, sure, you’ll eventually have a software asset, and it might even be worthwhile to keep track of how much it cost to acquire it. However, if you’re thinking of it as an asset to buy, you’re overlooking something crucial.

Consider all of the decades of trial-and-error in the automotive industry that preceded standards like what the pedals of a car should do, and what order they should be in.

Or the centuries of precedent for the typical layout of a house where the kitchen is near the back and generally on the ground floor.

When we buy a house or a car, these fundamental and crucial decisions (and the value they provide) are already made for us. We don’t incur the expense of figuring these things out ourselves because so many have gone before us.

There’s so much precedent with these kinds of physical assets that we can even assume the price is accurate even before construction begins.

This isn’t so in software.

The process of software development encompasses not just the “building” of software according to some specification, but also the process of creating and refining that specification. Even in so-called “custom building” a car or a house, we don’t need to expend the design effort or trial-and-error to arrive at specifications for where the pedals go, or how wall studs should be spaced, what voltage the electrical system should use, and so on.

However, in software, these key decisions can’t simply be copied: they must be uncovered. Yes, we can make assumptions about which decisions will work best, but we won’t know they’re the right decisions, often, until after the software is built.

Therefore, the only appropriate method of working is iterative. We should build a little bit of software according to a small, limited set of specifications, evaluate that software’s effectiveness, use the insight we gain to adjust the specifications, and repeat. This way, as we uncover key details, we can refine our approach according to that new information—a microcosm of the decades and centuries of refinements mentioned above.

This, however, doesn’t really help us arrive at a final price tag, does it?

Instead of seeing software as an asset to buy, try viewing software development as a service to retain. In accounting terms, this makes software development an operating expense (“OpEx”), not a capital expenditure (“CapEx”). You’re not buying an asset, you’re paying for a service.

How much you pay for that service depends on how quickly you’d like to turn newly-uncovered information into software that provides value in some way. Larger or smaller spend controls how big of a team works on transforming new insights into additional value in your software every month.

What’s more is that well-run software development delivers value often; sometimes, even multiple times per day. This means frequent opportunity to course-correct based on the inflow of new information before investing too much in the wrong direction. And so, frequent delivery of small increments of software, OpEx style, is less risky and reaches return on investment much faster than CapEx.