FIFTEEN YEARS AGO, I COULD SEE THE LINE
Fifteen years ago, I could often see the line more clearly.
A large catalog. Complex filters. Heavy traffic. Difficult integrations.
At some point, the conversation became relatively simple. A CMS would take us this far. Beyond that, we built.
I have much more experience making these decisions today than I did fifteen years ago.
And I am less comfortable making them quickly.
Not because I understand software less. Because the software on both sides of the decision changed. The platforms became stronger. The CMS ecosystems became more capable. Integrations became easier. Custom software became faster to build. And now AI is pushing the economics of development again.
The old question was simple: should we build or buy?
I am no longer sure that is the right question.
The question I ask more often now is: what do we need to decide today, and what can reality decide for us later?
I USED TO SEE THE LINE
I remember when Shopify was a much simpler product. I remember when many CMS platforms had obvious limits.
You could look at a business with a large product catalog, complicated filtering, unusual integrations, growing traffic, and a long list of operational requirements and say: we are going to outgrow this.
Sometimes you could almost see the moment coming. The platform was not bad. The business was simply becoming a different problem.
Today, that line is harder to see.
Modern commerce platforms are no longer the simple tools I remember. They have become ecosystems. Shopify alone now supports a much broader B2B and extensibility layer than the product many of us remember from years ago. Its current platform spans B2B functionality, custom storefront options, APIs, checkout extensibility, and a growing ecosystem around the core commerce engine.
The same thing happened across software.
A business can now launch with a SaaS product, connect several services, configure workflows, add integrations, and solve problems that once would have sent us directly into custom development.
For a new or relatively small business, the answer can be obvious. Do not build what you can already buy and test tomorrow. Launch. See whether the business works. See how customers behave. See what your team actually needs.
There is no prize for owning 80,000 lines of code before your first hundred customers arrive.
But something else changed too.
Building became more accessible. Modern frameworks, cloud infrastructure, APIs, distributed development teams and now AI-assisted development have all moved parts of the economics of custom software.
A 2026 research paper studying exactly this problem names the tension directly: the availability of third-party solutions and the feasibility of custom development have both increased at the same time.
That is not a contradiction. It is the whole difficulty.
THE $500 SUBSCRIPTION IS RARELY A $500 SYSTEM
I have seen this happen many times.
A company starts with one subscription. The price looks reasonable. $500 a month. Maybe $800. Maybe $1,000. Compared with custom software, the decision looks almost stupidly simple.
Then the business needs something else. Another service. Then an integration. Then a connector because the first two systems do not quite speak to each other. Then a module. Then a higher plan because API access or another required function lives in a different tier. Then another tool for a department whose process does not fit the first system.
One subscription attracts another.
The $500 decision was never a $500 system.
This is not an argument against SaaS. Software subscriptions solve enormous problems. They let companies access years of product development, infrastructure and operational experience without building those capabilities themselves.
But subscription stacks accumulate. And sometimes they accumulate quietly.
The 2026 SaaS Management Index from Zylo reports that average SaaS spending in its dataset rose 8% year over year while average application counts were essentially flat. It also reports an average 36% of licenses sitting unused when measured against recommended utilization levels. The data comes from a SaaS management vendor and should be read in that context, but the pattern is familiar to anyone who has looked closely at a mature software stack.
The problem is not always that companies buy bad software. Sometimes they buy software for a business they imagine they are becoming.
We will need this at the end of the year. The sales team will use this. We are planning to enter another market.
Later, this process will become much more complicated. So the company adds the tool. Or upgrades the plan. Or connects the service.
The future does not arrive.
The subscription does. Every month.
Software stacks accumulate assumptions. Some become real requirements. Some do not. The invoice does not know the difference.
SOMETIMES SAAS IS RESEARCH
This is where I think companies make the build versus buy decision too permanent, too early.
Sometimes a client comes to us with a clear request. They need a CRM. A commerce platform. A configurator. An internal business system. They have the budget for custom development. They may even arrive already convinced that custom software is the more serious solution.
But there is a problem.
The business may not understand its future process well enough yet. The owner has one idea. Marketing has another. Sales needs something else. Operations has already found three exceptions nobody discussed in the first meeting. An external marketing team arrives. A specialist responsible for another channel joins the discussion.
Everyone is describing a future system. And everyone may be right about the problem they can currently see.
This is normal. I like this part of projects. A living business is not clean. Different people push on the system from different sides because they experience different parts of reality.
The mistake is not having that chaos. The mistake is turning every current opinion into permanent infrastructure.
Sometimes the best decision is to take an existing SaaS product and launch. Not because we believe the company should use it forever. Because the company needs to learn.
Let real customers enter the process. Let real orders move through the system. Let the team find the workarounds. Let people ignore the feature everyone insisted was critical. Let the exceptions appear.
Six months later, the conversation is different.
We are no longer asking how you imagine this process working. We can ask how it actually worked.
That is a much more expensive question to answer with custom code.
Sometimes SaaS is not the alternative to custom software. Sometimes SaaS is the research phase before custom software.
And sometimes the research gives you an answer you did not expect. The platform works. The cost is acceptable. The integrations are stable. The team adapts. The business does not need custom software.
Good. Stay there.
The goal was never to find an excuse to build. The goal was to find the right infrastructure for the business.
MAYBE YOU JUST CAN'T BUILD IT
I once argued with a client about a feature he wanted us to build.
He had the budget. He was ready to pay. I kept asking whether the business actually needed the feature. At some point, he became frustrated.
Maybe you simply can't build it. Or you don't have the resources. Your competitors can do this. You can't. Should I go to them?
I would love to say I remained completely rational.
I did not. It got to me.
Okay, I said. We will build it.
But I asked for one thing.
Six months from now, we come back and check how important this feature actually was.
The work cost around $18,000. We built it.
Six months later, we met to discuss a new set of tasks. I had not forgotten the argument. So I asked: can we look at that feature?
We looked.
Nobody had used it. Not less than expected. Not enough to justify the cost. Nobody.
The feature worked. The client had been ready to pay. We had been capable of building it. The money had been available.
And we still should not have built it.
I do not tell this story because I was right. I was not certain. I had doubts. There is a difference.
And I certainly did not enjoy discovering that a client had spent around $18,000 on something nobody used.
But that experience changed the way I approach custom development.
Today, when a client tells me a feature is important, I often ask a different question.
When do you actually need it?
Probably toward the end of the year.
Then maybe we do not build it today. We launch what the business understands now. We watch. We learn. If the feature becomes a real requirement, we build it then.
We still work with that client today.
I SOMETIMES EXPLAIN SOFTWARE WITH A HOUSE
I have worked with both digital and physical architecture. Because of that, I sometimes explain software decisions to clients by talking about buildings.
Software feels flexible. A field in a database does not look expensive. One more user role does not look structural. One more status. One more integration. One more exception. It is code. We can change code.
A building makes the same mistake much easier to see.
Years ago, we worked on a large private residence for a very ambitious client. He wanted an elevator in the house. He also wanted a swimming pool on a terrace.
A pool on a terrace is not a decorative idea. Water is heavy. The load changes. The engineering changes. The structure has to be designed for the future you are describing.
So the terrace was reinforced. The structural work related to the planned loads added roughly $100,000. The house was also prepared around the idea of an elevator.
The pool was never built. Neither was the elevator.
The future disappeared. The infrastructure built for it remained.
I have watched imagined requirements become code. I have also watched them become concrete. The mistake is surprisingly similar.
Software is easier to change than concrete. The invoice is not.
You can remove a feature that cost $18,000. You can delete code. You can disable an integration. You can simplify a workflow. The money does not come back.
A database field feels cheaper than reinforced concrete. But enough assumptions eventually become structural. They affect the data model. The interfaces. The tests. The integrations. The people who maintain the system.
At some point, you are maintaining a building for a swimming pool that was never built.
Every assumption enters the architecture as if the future had already happened.
That is why I am careful with future requirements. Not because companies should stop planning. Not because ambitious owners should become less ambitious. I like ambitious projects.
But there is a difference between leaving a reasonable path open and making today's infrastructure pay the full price for tomorrow's imagination.
EVEN WHEN WE BUILD CUSTOM, WE START SIMPLE
Custom development does not mean building everything.
This sounds obvious. In practice, it is surprisingly difficult.
Once a company decides to invest in custom software, the project changes psychologically. People begin opening drawers. There is a list from last year. Someone has a spreadsheet. Marketing remembers a feature they discussed six months ago. Sales has seven exceptions. The owner is already thinking about the next market.
And because we are building custom software anyway, every idea starts to sound cheaper.
We are already here. Let's add it now. It will be more difficult later. We will definitely need it.
Maybe.
But every feature we build creates a maintenance obligation.
Everything you build starts aging the day you finish it.
A feature is not free after development is complete. It has to continue working while the business changes around it.
So one of the simplest questions I ask is: do you really need this feature?
Yes. Absolutely. We are planning to implement it.
When?
Probably toward the end of the year.
Okay. Then perhaps we do not need it now. Let's launch this part first. Let's test the process. Let's see how people use the system. Let's find out whether the requirement survives contact with the business.
If it does, we build it.
Do not custom-build a future assumption if you can wait for it to become a current requirement.
This is not about building a bad first version quickly. I am not interested in shipping garbage and calling it an MVP.
It is about building the part of the system the business already understands. Then letting reality design the next layer with us.
THE RIGHT DECISION CAN CHANGE
We are currently working on a new version of a product for a business we have known for more than five years.
The original product was built on an open source CMS. At the time, that was the right decision. The business did not need a large custom platform simply because we were capable of building one.
The CMS gave us a foundation. We developed it. Extended it. Connected what needed to be connected. The business operated.
Then the business grew. The catalog became more complicated. The filtering logic became more demanding. Integrations accumulated. The product itself became a different system.
So we looked at the decision again. This time, custom development made more sense.
Not because custom software had secretly been the right answer five years earlier. The previous decision was right. The business changed. And when the business changed, the equation changed with it.
This is the part I think many companies miss.
A software decision becomes part of the company's history. We use this CRM. We are on this platform. We built our own system. We chose this architecture five years ago.
The sentence slowly changes from a decision into a fact. Nobody asks the original question anymore.
But the business that answered that question may no longer exist. Its volume changed. Its team changed. Its customers changed. Its processes changed. Its software vendors changed. The economics of development changed. The capabilities of the platforms changed.
Why should the answer remain permanent?
The same researchers reach a similar conclusion from a more formal direction. Their framework maps build versus buy decisions across four dimensions: strategy, application characteristics, cost and budget, and risk, and treats the decision itself as something that can shift as those dimensions shift.
They built a model for that.
I reached the same place by watching businesses grow out of decisions that had once been completely reasonable.
BUY, CONFIGURE, EXTEND, BUILD
I do not think about this as two doors anymore.
BUY
Use an existing product. Launch quickly. Pay for access. Let someone else carry much of the platform burden.
CONFIGURE
The product already solves the problem. Your job is to make it reflect the business without pretending every preference requires code.
EXTEND
The core system works. A specific part of the business needs more. Integrate. Add a layer. Build around the edge where it makes sense.
BUILD
The business understands the process. The system matters for years, not months. The economics justify ownership and maintenance. The requirements are specific enough that forcing the company into someone else's model creates a real operational problem.
And even then, start simple.
This spectrum is increasingly visible in current build versus buy discussions as well. Recent frameworks describe the choice less as a binary and more as build, buy, or extend an existing platform.
But we would add one more thing.
These are not four levels of maturity. Build is not the final boss of software. A company using SaaS is not less sophisticated than a company with a custom platform.
Sometimes the most intelligent architecture decision is to pay for a product and never think about that part of the business again. Sometimes it is to own the system. Sometimes it is to rent first, learn, and reconsider later.
The architecture should serve the business. The business should not perform sophistication for the architecture.
RECALCULATE
If a client asks us today: Shopify, SaaS, open source CMS or custom software?
We cannot answer from the question. Even with an unlimited budget, we cannot honestly say: custom.
We need to understand the business.
What does it do today? What is actually complicated? Which processes are real and which are planned? What does the company expect to be doing in five years? How much is the current software stack really costing after subscriptions, modules, connectors and integrations?
What happens if the vendor changes pricing? What happens if the custom development team disappears? Can the company maintain what it wants to own? Does the business need this function now? When will it actually use it?
And perhaps most importantly: does the company know enough about this process yet to make the decision permanent?
The economics are moving on both sides. SaaS portfolios are not necessarily growing by application count, but costs continue to rise in current industry data. At the same time, AI assisted development is forcing researchers and companies to reconsider parts of the historical economics of building software, although current research also warns that the idea of AI simply making SaaS obsolete is overstated.
That is why we think many companies should revisit the question.
Not because SaaS is bad. Not because custom software is suddenly cheap. Not because AI changed everything overnight.
Because the variables moved.
And your business probably moved too.
The software decision you made five years ago may have been completely right. That does not make it right today.
The feature you are certain you will need in December may become critical. Or nobody may ever use it.
The platform you rent may become the foundation of the company for the next decade. Or it may teach you exactly what your own system needs to become.
The question is not whether we can build it. Increasingly, we can.
The question is not whether software already exists that can do it. Increasingly, it does.
The harder question is whether the business knows enough yet to make the decision permanent.
And if it does not, maybe the most expensive thing you can build today is the future you only imagine you need.
- Share
-
-
-
-
