The last capability enterprises still rent: their software

Vertical integration means bringing a capability inside the business: doing yourself what you used to buy from someone else. It is one of the oldest moves in industry, and most large operating companies have made it many times. There is one capability almost none of them have brought inside, and it is the one that every other capability now runs on.

This article is for the people who make build or buy decisions: owners, operations heads and CIOs.

Why capabilities come inside

No enterprise integrates for its own sake. Running your own fleet is harder than hiring a transporter. Running your own maintenance crew is harder than signing a service contract. A capability comes inside when depending on someone else for it starts to cost more than the trouble of running it.

The pattern repeats across industries, in roughly the same order.

• Suppliers. A manufacturer that cannot get consistent raw material starts making it, or buys directly from growers and producers in place of going through intermediaries.
• Distribution. A company that depends on a distributor’s attention sets up its own depots and its own sales force, so that it decides which product gets pushed and which customer gets served first.
• Logistics. A business whose promise to customers depends on delivery takes on vehicles, or at least its own dispatch and scheduling, because a late truck is its problem whoever owns the truck.
• Finance. Credit to customers, advances to suppliers and treasury move in house once they become a tool of the business and not just a service to it.
• Maintenance. A plant that loses a shift waiting for a contractor builds its own maintenance team and its own spares store.

In each case the outside arrangement was more convenient, and often cheaper on paper. The capability still came inside, for three reasons that are worth naming because they come up again later.

Control. You decide what is done and in what order. Your priorities are not one entry in somebody else’s queue.

Speed. When something has to change, it changes when you say, not when the contract next allows.

Continuity. The knowledge of how the work is done stays with people who are still there next year.

Control mattered more than convenience. That one sentence explains most integration decisions ever made.

The one that stayed outside

Now look at what runs all of those capabilities day to day: the software. Purchasing, stock, production, dispatch, approvals and reporting each sit in a system, and in most enterprises every one of those systems is bought or rented. Packaged software is licensed. Subscriptions are paid monthly. Where something was built specially, it was usually built and held by a vendor, who also holds the people who understand it.

So an enterprise that owns its supply, its fleet and its maintenance still asks an outside party for permission, in effect, to change how a goods receipt works. The request goes into a change queue. It is scoped, estimated and scheduled. Sometimes the answer is that the product does not do that, and the operation bends to fit the software, or a spreadsheet appears beside it.

This is the same dependence that drove every other integration decision. It was tolerated in software for one reason.

Why that was rational

Building enterprise software was slow and expensive in a way that building a depot was not.

A serious operational system needed a large team for a long time. Analysts wrote requirement documents. Architects designed foundations: who can log in, who can see what, how approvals move, how records are stored, how reports are produced. Developers built those foundations before a single screen that the operation cared about existed. Testers followed. A year was an ordinary duration, and an army an ordinary size.

Then came the second cost. The team that built the system understood it, and that team belonged to the vendor. When the engagement ended, the understanding left with them. What remained was a system the enterprise could use and could not change.

Against that, renting was the sensible choice. A packaged product arrived already built. It covered the processes every business has in common, and for those it covered them well. For the part of the operation that was particular to the business, there were workarounds. The price of ownership was a year and an army, and almost nobody’s operation justified it.

It is worth being clear that this was a judgement about cost, not about principle. Nobody argued that it was better for an outside party to control how the plant’s records work. It was simply too expensive to do anything else.

What changed

Two things changed the cost, and they are separate.

The foundations no longer need to be written each time. Every operational system needs the same base: users, roles and permissions, approval chains, a record of what happened, reporting. In a traditional build this base took months before anything specific to the business appeared. A framework that already contains it lets the work start at the point where the operation becomes specific.

Writing code got much faster. AI now writes a large share of routine code quickly, provided it is given a precise description of what to build and works inside firm rules. This does not remove the need for people. It moves them. The scarce work is now understanding the operation: its steps, its units, its exceptions, and who decides what.

Put together, the arithmetic is different. If the base exists and the code is quick, the duration of a build is set by how long it takes to understand the operation properly. That is a matter of weeks on site, not quarters in a development centre.

There is a fair caution here. Faster code does not help a team that has misunderstood the floor. A system built quickly from a wrong description is wrong sooner. The gain is only real where the time saved is spent on the description.

What owning should mean

“Own your software” can mean several things, some of them unhelpful. A useful definition comes straight from the three reasons enterprises integrate anything.

Control: what gets built, and when, is your decision. Not a vendor roadmap, not a change request queue, not whatever the contract happens to cover. The test is simple. Name the next three changes you want to the system. If you can order them yourself and expect them in that order, you have control.

Speed: the system changes when the process does. A new deduction rule, a new checkpoint, a new customer who wants goods packed differently. In an owned system, the change is a short piece of work by people who already know the operation. If each change begins with a scoping call and an estimate, the system is rented, whatever the contract says.

Continuity: the knowledge stays. This is the one most often missed. Owning the code is of little use if nobody on your side can say what it does. What has to stay is a written description of the operation as the system understands it: the things it tracks, the events that happen to them, the exceptions and how each is handled. With that, a new engineer, a new vendor or your own team can carry on. Without it, you own a building with no drawings.

A worked example makes the difference concrete. Take a plant that buys fuel from farmers and aggregators, where each vehicle passes gate entry, quality, gross weight, unloading, tare and exit. Suppose management decides that loads from a new kind of supplier need a second quality check. In a rented system this is a change request, and the likely answer is a remarks field. In an owned one, the checkpoint is added to the description of a trip, the system follows, and every earlier trip remains on record exactly as it happened.

What owning should not mean

Integration has a failure mode, and software has its own version of it. An enterprise that decides to own its software can end up owning far too much.

It should not mean writing your own plumbing. Login, permissions, approval routing, record keeping and reporting work the same way in every company. Nobody competes on them. Building them yourself is like a manufacturer making its own bolts: possible, and a waste.

It should not mean replacing what packaged software does well. Accounts, payroll and tax are the same everywhere and are well served by products. Keep renting them. A companion piece, build, buy or rent, capability by capability, goes through how to sort one kind of system from the other.

It should not mean a large internal software department. A small number of people who understand both the operation and the system is the aim, and they can still direct outside help.

A reasonable summary: own the description of your operation and the right to change the system that runs it. Do not insist on owning the parts that are identical everywhere.

Five questions for your next software decision

Before signing for any operational system, bought, rented or built, ask these.

1. Who decides what is changed next, and in what order?
2. How long does a small change to a process take, from the decision to the floor?
3. If the vendor’s team is replaced, where is the knowledge of how our operation works written down?
4. Which parts of this system are the same for every customer, and which parts are ours alone?
5. Could our own people build the next system on the same foundation, if we wanted them to?

There are no universally right answers. A payroll product can fail all five and still be the correct choice. For the systems that carry how you actually run, the answers show whether the capability is inside the business or outside it.

Where Phlo fits

Phlo is the framework Jetbro builds on, and it was made for this decision. The foundations are already written, AI compresses the development timeline, and people spend their time on the floor understanding the operation and its exceptions. The offer has two stages. In the first, Phlo Enterprise Systems, Jetbro builds the first system with you, and that build is where your operation gets written down. In the second, Phlo Framework, the framework becomes available to you: your own engineers can build the next system on it, or Jetbro carries on. Both stay open.

Enterprises brought everything else inside when control was worth the trouble. For software, the trouble used to be a year and an army. It is worth checking whether that is still the figure you are deciding against.