The Unit Economics of Engineering

Engineering cost is not the cost of the sprint. It's the cost of the decision, compounded over the life of the system.

Most founders think about engineering cost the wrong way. They think about it as a line item — the cost of the developer, the cost of the sprint, the cost of the feature. That's the visible cost.

The invisible cost is the cost of the decision. The cost of the architecture that was chosen. The cost of the technical debt that was accumulated. The cost of the system that can't be changed without risk.

The three costs of engineering

Engineering cost has three components.

Build cost. The cost of writing the code, testing it, and deploying it. This is the cost most founders think about.

Maintenance cost. The cost of keeping the system running, fixing bugs, and adapting it to changing requirements. This is typically 2-4x the build cost over the life of the system.

Change cost. The cost of adding new features, changing existing ones, and adapting to new requirements. This is the cost that varies most dramatically based on the quality of the initial engineering.

A well-engineered system has low change cost. A poorly-engineered system has high change cost. The difference compounds over time.

The leverage calculation

The leverage calculation for engineering quality is: how much does a dollar spent on quality now save in change cost later?

For a system that will be changed frequently over three years, the answer is typically 3-5x. A dollar spent on a good data model in month one saves three to five dollars in rework over the following three years.

For a system that will be changed rarely, the leverage is lower. A landing page that will be replaced in six months doesn't need the same engineering quality as a billing system that will run for five years.

The skill is knowing which is which. That requires understanding both the engineering and the business.

The MVP trap

The MVP trap is building the minimum viable product with the minimum viable engineering, then discovering that the minimum viable engineering is the maximum viable engineering — because the cost of changing it is too high.

The MVP should be minimal in scope, not in quality. The features should be few. The engineering of those features should be good.

A small, well-engineered system is cheaper to grow than a large, poorly-engineered one. The scope can expand. The architecture can't easily be replaced.

The honest conversation

The honest conversation about engineering cost is: what are we building, how long will it run, and how often will it change?

Those questions determine the right level of engineering investment. Not the sprint velocity, not the number of features, not the time to demo.

At NextGen, we have that conversation at the start of every engagement. The economics of the build are part of the engineering decision, not separate from it.