When building it yourself is the slower option

There is a default assumption in enterprise software that building in-house is the safe option and outsourcing is the risk you take when you have run out of capacity. It is a reasonable instinct, and it is usually wrong in one specific situation: when the thing you are building is genuinely urgent and genuinely outside the shape of what your teams already do. In that situation the in-house route quietly costs you the one thing you cannot buy back, which is time, and it does so in a way that never shows up as a line item.

That was roughly the position around Takealot's Personal Shopper programme. The programme was working - a network of local shoppers placing orders for their communities, more than 14,000 of them and growing - but it was running on spreadsheets and informal channels, and the gap between what the operation had become and what the infrastructure could carry was widening every month. The technology was not the hard part. The hard part was that every quarter spent standing up a team to do it was a quarter the network kept growing without it.

What buying a team actually means

When a company like Takealot goes looking for delivery capacity, what is usually on offer is a supplier: a set of hands that need a spec, a scope document to argue over, and a project manager on your side whose job is to translate between them and you. That model is not dishonest, but it puts the coordination cost on the buyer, and coordination cost is exactly what an urgent project cannot afford.

The alternative is to buy a team rather than an app - a group that already contains strategy, experience, technology and data, that has worked together before, and that can be pointed at a problem without a specification because it is capable of writing one. We embedded inside Takealot's product function rather than working alongside it at arm's length: inside their architecture and their governance, sitting with their product owners and technical leads and their security and compliance people, and running the delivery to our cadence, which they took the lead from. The value of that is not warmth. It is that decisions get made in the room where the context lives, which is the only place they get made quickly.

The purchase was never an app. It was a team that arrives whole, and can be held to your standards from the first week.

Fixed cost is a strategic instrument, not a procurement detail

The commercial shape mattered as much as the technical one. The work was costed to scope and delivered on a fixed budget and a fixed timeline, with the delivery risk carried on our side, which meant Takealot knew what they were getting, what it would cost and how long it would take before a line of code was written.

I think that is worth dwelling on, because fixed cost is usually discussed as a procurement preference and it is really a strategic one. Risk does not disappear when you keep a build in-house; it just sits with the party least able to price it, which is the party that has never built this particular thing before. Moving it to the team that has is not a discount you are extracting, it is a reallocation to whoever can actually carry it, and the speed you get back is the return on that decision. A partner who will not carry the risk is telling you something useful about their confidence, and it is worth listening to.

It also changes the conversation during delivery. When the budget is fixed and the risk is ours, nobody is incentivised to discover scope, and the weekly discussion becomes about whether we are building the right thing rather than about how many hours it took. That is a better conversation, and it is one of the reasons the strategy and the build could run as a single overlapping stream rather than queuing as phases.

The part most people skip

The piece of this model that gets least attention is what happens after launch, and it is the part I would defend hardest. The platform went from a standing start to live in six months, and from pilot it moved straight into full operations without a handover, because the team that built it is the team that runs it. Today it carries more than 40,000 transactions a month across that same growing network.

A handover is where most of the value of an embedded team leaks away. Every decision that was obvious to the people who made it becomes a question for the people who inherit it, and the product context that took six months to accumulate gets compressed into documentation that nobody reads at the moment they need it. Skipping the handover is not a support arrangement, it is a delivery-model decision, and it is the reason build-into-run costs less than build-then-transfer even when the monthly number looks higher.

Where this goes next

Enterprise South Africa has historically treated product outsourcing as a risk to be managed rather than a capability to be bought, and I understand why, because most of the market has earned that reputation honestly. What changes the calculation is not a better sales pitch, it is a different model: fixed cost, carried risk, an embedded full team, and build into run. Put those four together and an outside team can be held to inside standards, and can move faster precisely because it arrives whole.

We do not think Takealot will be the last company to test that proposition, and we would rather the argument was settled in production than in a proposal. The next piece in this series goes under the bonnet on how it actually held up, with Luke on what it takes to build to another company's engineering standard.