Evaluating the buy vs build decision in the age of AI

Most enterprise software decisions still follow a rule of thumb from about ten years ago: buy unless you really have no other option. It was good advice at the time. Building meant a long project, a dedicated team, and a system you had to maintain for the next decade. A license moved that risk to a vendor, and most companies accepted the trade that came with it: working the way the vendor works.

That rule deserves a second look today, because the cost of building has dropped significantly over the last few years, and with it the case for accepting someone else's version of your process. We've seen this play out for one of our customers, argenx, and share our learnings below.

AI-assisted engineering has significantly reduced the effort for the repetitive parts of a build: scaffolding, CRUD layers, integrations, test coverage, migrations, and documentation. Work that used to take weeks now takes days.

In our own projects, this shifted the bottleneck. Implementation used to be the slow part. Now most of the time goes into definition: understanding the domain, modelling it correctly, and agreeing on what done means before development starts. A vague requirement used to cost a week of rework. Today it costs a week of fast development in the wrong direction, which is worse, because the output looks finished.

Building still isn't free. But with a large share of the implementation effort out of the estimate, the comparison with a five-year license contract looks different than the last time you made it.

argenx had been evaluating a license-based platform with clear requirements and a credible vendor. But the process it had to support is specific to how argenx operates, and much of that specificity ended up scoped out as customisation or separate cost items. That made a custom build worth serious consideration. The financial comparison was done properly, build cost against full license cost over the same period, and building came out ahead.

What has mattered even more during the decision making process is fit and control. The platform uses argenx's terminology, screens follow the order in which the work happens, and the exceptions and integrations that make the process theirs are part of the system rather than bolted on around it. The roadmap is theirs too, so changes are a matter of deciding what to build next rather than waiting on a vendor's priorities. The result is a system that encodes how argenx runs a core part of its business, owned rather than rented, with no dependency on a vendor's pricing, direction or future.

Often. The rule is simple: if the process is generic, license it. Nobody should build their own CRM, ERP or payroll system. Those requirements are the same across thousands of companies, the products have been refined for years, and you get the certifications, audits and regulatory updates included. Building becomes interesting when the process is specific to how you work, as it was at argenx.

Building used to feel risky because it was framed as one big commitment. It doesn't have to be. Pick the smallest slice that is useful on its own, bring it to production with real users and the integrations it depends on, and expand from there with useful additions. Within weeks you know whether it fits the way people work, while changing course is still cheap.

If you're weighing one of these decisions, we're happy to run the comparison with you, including the version where the answer is to buy.