Every platform purchase has a gap between signing and working, and nobody plans for what happens inside it.
Buy versus build is a question about time
The argument gets framed as a permanent choice. Buy for speed and support, build for control and fit. Both cases are reasonable.
What the framing misses is time. A purchased platform does not start working the day the contract is signed. It gets configured, integrated, tested, and adopted, and that takes months.
During those months the business still needs the thing done. Nobody puts that period in the business case.
Enterprise software arrives configured for nothing
Because the product is general and your business is not. Enterprise software is built to serve many companies, which means it arrives capable of a great deal and configured for nothing.
Add integration with what you already run, data mapping between formats never designed to meet, testing against real volumes, and training for people who did not ask for a new tool. Months disappear into those four things.
None of that means the purchase was wrong. It means the purchase was the beginning of a project rather than the end of one.
DataSlide
We were in the middle of the second transformation, moving off a declining database onto a new platform. Part of the plan was enterprise middleware that would move data between the old systems and the new ones.
The middleware was not ready. The migration was.
So a programmer on my team built a set of programs that slid data from one system to another. Extract it, convert it, load it somewhere else. He named it himself.
It worked. It moved the data while the purchased platform was still being brought up, and the migration kept moving because of it.
Building the interim version anyway
The objection is obvious. You are building the thing you just paid somebody else to provide.
Three things make it worth doing anyway. The interim version only has to handle your cases rather than every company’s, so it is far smaller than the product. It can be built by people who already understand your data. And it can be thrown away without regret, because it was never meant to last.
That last condition is what separates a good interim solution from a problem. Build it knowing it dies, keep it small, and do not let it grow features.
The failure mode is the interim tool quietly becoming permanent because it works and nobody wants to finish the migration. Set a date for retiring it when you build it.
Marble floors and a nine-figure exit
The middleware company we bought from had a headquarters within walking distance. Beautiful building, obviously overbuilt, marble floors. Built to impress buyers.
They wanted to sell the company, and they did. A major technology firm acquired them for around three hundred and eighty-seven million dollars in 2005.
My boss loved that company. The building did its job.
None of that made it a bad purchase. The product was real and the acquisition proved somebody else agreed. What the building told us was about the vendor’s ambitions, and a buyer should know which signals are about the product and which are about the sale.
One question, in writing
When will this platform be doing real work for us, and what are we doing between now and then?
A vendor who has implemented for companies your size will answer specifically. They will describe the phases, name what typically slips, and tell you what other customers did in the meantime. A vendor who answers with a fast onboarding timeline and no discussion of the gap has told you something too.
Then plan the gap deliberately. Keep the old system running longer, which costs money and buys certainty. Build something small and temporary, which costs engineering time and requires the discipline to kill it. Or accept the business does without, which is sometimes fine and should be a decision rather than a surprise.
Any of those beats discovering in month four that nobody thought about it.
The purchased platform had marble floors and a nine-figure exit. The interim tool had a programmer and a deadline. Both were part of the same successful migration, and only one appears in any account of how these projects work.
The full article is on my site: https://thewritingking.com/buy-versus-build-in-the-gap/. It runs longer, carries the diagrams, and answers the questions readers ask most.
These are AI-made summaries of longer articles on my site, written with AI assistance from my own interviews and my own career. Nothing goes out that I have not read and approved.