Pedro said that many businesses doing six or seven figures can be better off with custom software when it is built by good developers using the right tools.
One reply asked:
“Then why don’t the most profitable companies in the world do it?”
I had to read that twice. Large, profitable companies build software for themselves all the time. They are fairly public about it.
JPMorganChase reported $57 billion in net income in 2025. It has described an internal platform its developers use to build and release software, as well as a proprietary AI platform it built for employees. Those are its own systems, developed for its own work. JPMorganChase’s annual report, developer platform article, and LLM Suite article are available if anyone wants to check.
A bank seems like an especially strange example to use for the idea that compliance makes custom software impossible.
Walmart has also written about a transaction system built by its own technology team for its stores. More recently, its leadership described its approach in an earnings call: “sometimes we build our own tech, and sometimes we partner.” There is the answer, from Walmart’s own account of the system and its earnings-call transcript.
I did not need to investigate an obscure rumour to find either example. These companies explain their technology decisions in public.
Big companies buy software as well
Walmart isn’t hand-building an operating system before opening another supermarket. Its technology chief says the company works with partners on things like warehouse automation while building technology it wants to control. Walmart explained that approach in a 2025 interview. Pedro was talking about making those choices for smaller businesses, on a much smaller budget.
JPMorganChase’s developer platform uses established components too. Its engineers put those components together into a system that suits the bank.
A business might buy its payroll software, use a specialist payment provider and build the system that handles a workflow peculiar to its own team. The custom part does not have to be the whole stack.
What about companies that prefer a proven solution?
Another reply described a pattern the commenter had seen: businesses above five million in revenue tend to prefer established products, especially when requirements such as single sign-on, certifications and security testing come up.
I can believe that some businesses they have worked with made that choice. A ready-made product can be quicker to approve and easier to buy when it already meets the company’s requirements. Sometimes it is also the best fit for the work.
I would still want to know what “proven” means for the particular business. Proven at keeping the vendor’s service running? Proven at meeting a security requirement? Proven at handling the workflow the customer needs without six spreadsheets and a weekly ritual of copying information between systems?
Those are different things. A business can grow and find that its existing software handles more of its work badly, even while its purchasing process becomes stricter.
The five-million figure also arrived without a currency or any explanation of why that number changes the answer. I am happy to hear about a pattern someone has seen. I am less willing to use it as the line where a business must stop considering custom software.
Single sign-on and security testing are real requirements. A custom option would have to meet them, and the cost of doing that belongs in the decision. They do not tell us, on their own, which product the business should buy.
A smaller business should make a smaller decision
JPMorganChase having its own developer platform does not mean a six-person company needs one. Walmart’s engineering budget is not a shopping list for Pedro’s clients.
But the examples do answer the question that was asked. Successful companies have not abandoned custom software. They build it where they think it serves the business, and they buy or partner where that makes more sense.
For a smaller business, the decision may concern one awkward process: how enquiries become projects, how jobs are scheduled, or how information moves between the team and its customers. A standard product might handle it well. If it does, great. If every available product forces the team to work around the software, a focused custom build deserves consideration.
Then come the questions that actually cost time to answer. What needs to be built? What existing services will it use? Who can access the information? What needs testing? Who will support it after launch? What will each option cost over the years the business expects to use it?
A revenue number cannot answer those questions. Neither can a list of companies much larger than the one making the decision.
“Why don’t the most profitable companies do it?” sounded like a devastating question. It turns out they do. Walmart even explained, in one sentence, that it builds some technology and partners for the rest.
Someone should probably tell the people using Walmart-sized companies as an argument against custom software.