My firm has partially transitioned through this curve. We went went from "fully externally supplied" systems, to an architecture that combines "externally supplied" (core functionality) with "low code" about 6 years ago. I would argue (as a financial manager) that that lead to a more flexible and more affordable architecture. A funny mixed bag problem arose though: the curve of business demands grew harder than that of IT-delivery. So IT delivered more value, but business keeps demanding a faster pace. If I project this line to the future AI will most certainly harm our external suppliers. We keep getting better at DIY development and "low code" will transition towards "no code". Not really "no code" of course, but DIY IT developed tooling.
The age of the business developer has re-arrived.
For the first time in my career, I can point to multi million euro external suppliers, tell my environment "that's basicly an API + authentication from X to Z, let's develop that ourselves" and get a response of "When" instead of "No". B2B SaaS is toast in my perspective, as are boutique firms delivering solutions + consulting. I can create a million euro team easily (that's like five developer years), if they deliver a successful insourcing. And now I feel like writing MBA-slop, but's it's all about growing your IT maturity. All insourced code is future maintenance expenditure. You need to balance that to the benefits.
> All insourced code is future maintenance expenditure. You need to balance that to the benefits.
I love this perspective. I feel like the pendulum has swung too far back to "it's easy to build, it'll be easy to support". But to be fair, it was probably too far the other way a few years ago: "it was easy to buy, it'll be easy to have them support it".
Other than trial and error, how do you think about pricing out maintenance costs for insourced code vs purchased functionality?