Contract development has a structural ceiling

“So in the end, isn’t this just converting labor costs into revenue?”

If you run a contract development business, you’ve probably felt this unease at least once.

On the surface, it’s a well-designed mechanism. The client has a budget, you have people who can build, requirements get aligned, and the work gets delivered. It’s fair trade, essentially, and both sides tend to walk away satisfied.

But after running the business for a while, a feeling creeps in: even though the income statement looks fine, nothing is “accumulating” in the company. That’s the real substance of the unease I opened with.

Contract development isn’t my main business, but putting together what I’ve seen from companies I’m involved with and conversations with other executives around me, this unease seems fairly widely shared. This piece is an attempt to lay it out as a structure. I’m not saying to quit contract development. I want to look at where the contract development firms that survive for a long time have holed up, and why that’s the position that survives.

Whether it’s hardware or software, the structure looks about the same as far as I can tell, so I won’t distinguish between them here.

Contract work is actually a four-story building

We say “contract development” as one phrase, but the content forms a continuous spectrum. Roughly, it breaks into four floors.

1. Selling person-hours: pricing by person-months. Requirements are left to the client; you build exactly as instructed
2. Selling deliverables: the shape of the deliverable is fixed, but requirements are gathered fresh each time
3. Template + customization: an existing in-house library, slightly modified to fit the client’s request
4. Licensing / SaaS: licensing out your own product or service

The higher you climb, the more reusable assets pile up. The lower you stay, the more you rebuild from zero every time.

There are also companies that “live off IP alone,” but that’s a different genre of strategy entirely, so I won’t place it on this ladder. More precisely, they start out somewhere the contract-work spectrum never reaches.

Here’s the key point: the contract development companies that survive for a long time have almost all holed up on the third floor, “template + customization.” On the surface it looks like new development, but in reality it’s recombination of internal libraries, differential implementation on past projects.

Conversely, contract firms that stay on the first or second floor structurally cannot scale. The reason is bluntly simple.

Three reasons life on floors 1–2 is painful

① Gross margin is capped by the unit cost of labor

Revenue tops out at “person-month rate × headcount × duration.” If you want to double profit, the only way is to double headcount.

Frankly, this is fatal as a business. A company where profit is directly tied to headcount growth suddenly finds itself checkmated by rising labor costs or hiring shortages.

② Management alone absorbs the swings in workload

When a project stops, only the labor costs remain. Revenue behaves like a variable cost while headcount behaves like a fixed cost — the worst possible combination.

And it’s precisely during the busy periods that your best engineers say “I’d like to work somewhere a bit calmer” and leave. Anyone with experience here knows the feeling.

③ Intellectual assets don’t accumulate

If you’re implementing different requirements differently every time, the reusable library never fattens up. Even after ten years, the cumulative effect is small.

Looking at the numbers, this is oddly cruel: it’s not rare for a company, ten years in, to find that all that’s left is “people and cash.” A capital-intensive business keeps its factory. A manufacturer keeps its molds and drawings. Contract development, if you’re not careful, leaves nothing behind at all.

In other words, the lack of profitability isn’t an accident. It’s designed not to be profitable.

The trap where it disguises itself as “a blessing” from management’s viewpoint

Here’s where it gets complicated, and this is actually where the difficulty in saying “quit contract development” lies.

From the vantage point of an executive overseeing multiple businesses, contract development surprisingly looks like the “model student.” A product business is huge if it hits and a loss if it misses; new development is a multi-year investment; R&D has hard-to-see returns. Amid all this, contract development gets placed in the stable slot of the portfolio as “a business that generates roughly some amount in gross profit every year.”

The explanation “we can afford to invest in new business because we have contract work” gets repeated in various places, and in some years it’s factually correct. That’s exactly why it’s hard to stop.

But the “stable-looking gross profit” from contract work is, in essence, not stable at all.

That’s because projects depend on the pipeline. If three big projects happen to overlap this year, gross profit looks fine on the surface. If those three end next year and no new ones are lined up, it’s zero. Only the fixed costs remain. In many cases, what looked like “roughly every year” was really just the waves happening to average out by coincidence.

There’s another factor too: gross margin swings wildly project by project. A template + customization project where 80% is reusable might have 40% gross margin. A full-scratch project with weekly requirement changes, a so-called disaster project, might have 5% gross margin, or even run at a loss. Even with the same “$1 million in contract revenue,” the amount that actually stays with the company can differ by a factor of 10 depending on the mix.

Even so, management tends to be shown a prior-year figure like “contract work runs at 30% gross margin.” That’s the magic of averaging.

And here’s where it turns cruel.

In good years, contract development earns a certain amount of credit within the company. The margin looks predictable, and it appears to be generating room to invest in new business.

But in a lean year, whether due to the economy, the market’s budget cycle, or anything else, the moment that happens, the evaluation axis flips. The drop in margin, lost bids, losses on disaster projects: all these questions get pointed at it at once.

A business that was called “a blessing” just recently suddenly turns into something held accountable.

This swing is probably another structural problem of the contract development business. Product businesses and R&D are positioned as “investments” from the start, so a bad year doesn’t easily flip the evaluation. Contract work, on the other hand, is built in as a “stable revenue source,” so the moment it underperforms, that immediately triggers a shift in evaluation.

Expectations were high, so the miss hurts. It’s a prospect-theory kind of thing.

There’s no complete fix for this dilemma, but there is an operational trick: build contract work’s gross margin into the management plan only at a conservative level (something like the lowest of the past five years). Treat anything above that as a “bonus.” This alone substantially lowers the risk of being scapegoated.

So where do you make a place for yourself?

With all that in mind, let’s reframe the question. It’s not a binary choice between “quit contract work” or “keep it.”

Where in the four-story building should you hole up so that accumulation actually works, and you’re less likely to be scapegoated? That’s the better question to ask.

As far as I can observe, contract firms that survive long term share several common traits.

First, accumulate library and design assets in a specific domain. Not general-purpose contract work, but domain specialization. Medical, financial, manufacturing, embedded, whatever it is. The in-house assets in that domain fatten up and fill 80% of any new project. The remaining 20% gets implemented fresh each time. This is the core of template + customization.

Second, build products you actually use yourselves. Tools built to improve your own operations end up also striking a chord with clients’ operations. In areas where dogfooding works well, the resulting products clearly outcompete anything built to spec for an outside client. This is the gradient zone of “half product, half contract work.”

Third, maintain price through quality assurance and relationship capital. Sell the same implementation as your competitors, but for more. The reason: credibility built up from a track record of past projects, and the capacity to respond when something goes wrong. Cost leadership is, in principle, impossible in contract development, so this is the only place differentiation can happen.

Conversely, a portfolio of projects where none of this accumulates, new every time, from scratch every time, a different domain every time, is structurally miserable. The more you do it, the less asset builds up, and only the swings in workload bounce back onto management.

Using the third floor as a “waystation,” not a “terminus”

Reading this far might sound like I’m saying “hole up on the third floor,” but actually the third floor can function both as a terminus and as a waystation. There’s a real path where you accumulate assets on the template + customization floor and use that as a foundation to climb to the fourth floor, “licensing / SaaS.”

For example, I know someone in Saudi Arabia running a company in a domain close to Switch Science. We met in Italy, and he deliberately narrowed his focus to the domain of “cameras” and kept taking on contract work within it. He paid no attention to general miscellaneous projects and concentrated on camera-related hardware, image processing, and embedded systems.

A few years later, camera-related libraries, circuit designs, and image-processing know-how had piled up thick inside his company. I heard from him directly that he used those assets to launch his own product, and used that product to successfully raise funding.

He had deliberately designed the route: get by on contract work while accumulating assets, then use the accumulated assets to climb to the floor above. The initial decision to narrow the contract-work domain directly determined the later competitive advantage of his own product.

Another example: a company I advise, hacomono, has followed a similar structure. It originally started as a web contract development company, but while working across multiple clients’ projects, it spotted something that companies in a certain industry commonly wanted. It threw its own SaaS at that need, it hit, and the company has gone on to raise tens of millions of dollars cumulatively. It’s still pre-IPO, so it’s too early to draw conclusions, but as a structure, it converted the “market feel” gained from contract work into SaaS, and it landed cleanly.

What both share is that they positioned contract work not as “contract work for the sake of staying in contract work forever,” but as “a period of asset accumulation for climbing to the floor above.” Holing up on the third floor is one strategy; using the third floor as a springboard to climb is another. Companies that can take the latter path are, in many cases, ones that narrowed their domain from the start.

Conversely, a contract firm that takes on anything without narrowing its domain can climb to the third floor, but the path from there to the floor above is hard to see. General-purpose libraries accumulate, but the deep feel for a specific domain never does.

The joy of being an engineer and the rationality of management are different things

This, I think, is probably the most important thing I want to say.

From an engineer’s perspective, contract work is fun. You touch different technology on every project, you see all sorts of industries, and your technical skill gets sharpened under the hard constraint of deadlines. This joy is real.

I myself lean strongly toward an engineer’s temperament, so there’s no doubt I prefer touching different technology on every different project.

But if you mistake this joy for “managerial rationality,” the longer you keep it up, the more painful it gets.

The joy of being an engineer doesn’t guarantee the joy of being an executive. These are different things. What’s enjoyable as an executive is, probably, watching something “accumulate” in the company.

The unease I opened with, the sense that “isn’t this just converting labor costs into revenue?”, is probably just another way of expressing this feeling that nothing is accumulating.

The good that’s actually reachable

I obviously don’t have the power to change the structure of the whole industry. But within the companies I’m involved with,

• lowering the ratio of selling person-hours and raising the ratio of template + customization
• narrowing the domains taken on and accumulating domain-specialized in-house assets
• once assets have fattened up, seriously considering a move up to the floor above (your own product / SaaS)
• building contract work’s gross margin into the management plan only at a conservative level

these are all things that can be implemented as management decisions. I’m not saying to switch to SaaS all at once. This is an operational matter of moving your position on the spectrum up even half a step.

A handful of management decisions, accumulated over a few years, will slowly change a company’s structure. Probably that’s the kind of time frame it takes for contract development to distance itself from being a business that merely “converts labor costs into revenue.”

This piece was drafted and directed by Kuzuryu, and written up by AI.

Originally published in Japanese at https://clazytech.com/2026/05/1606/. Translated with LLM assistance and reviewed before publication.