Most businesses that ask me whether they should build custom software should not build custom software. They should use Shopify, or HubSpot, or whatever off-the-shelf platform fits their category, and spend the money on something else.
I say this as someone whose actual work is building custom software. It’s still true.
Off-the-Shelf Is the Right Default
A platform like Shopify represents thousands of engineering years you don’t have to pay for. Payments, tax, hosting, security patches, checkout that converts, an app ecosystem for the common cases – all of it maintained by someone else, forever, for a monthly fee that’s a rounding error compared to a development budget.
When you build custom, you own all of that. Not just the first version – the maintenance, the security updates, the edge cases you didn’t think of, the thing that breaks at the worst possible time. Custom software is not a purchase. It’s a commitment.
So the honest default is: start off-the-shelf. If a platform can run your business, let it. The businesses that jump to custom too early usually end up with something more expensive and more fragile than the thing they were trying to escape, and they still have to hire someone to keep it alive.
The question is not ‘is custom better.’ Custom is not better. The question is whether the platform is standing between you and the way your business actually works – and whether that’s costing you real money.
The Signal That Actually Matters
There’s one signal that separates ‘you’re using the platform wrong’ from ‘you’ve outgrown the platform’: the platform blocks your business logic, not your styling.
Wanting a different colour scheme is not outgrowing the platform. Wanting a slightly different checkout layout is not outgrowing the platform. Those are configuration problems, and a platform that can’t handle them is rare.
You’ve outgrown the platform when the thing it can’t do is the thing your business is actually built on. When the way you make money doesn’t fit the shape the platform expects – and no amount of apps, plugins, or paid tiers closes the gap.
Here’s what that looks like in practice.
When the Platform Blocks the Business
A Finnish manufacturer I worked with, Pikkuna, sells made-to-order vinyl curtains and PVC products. Not fixed SKUs – products where the customer chooses dimensions, material, and mounting options, and the price recalculates from those choices in real time.
Shopify was ruled out early, and not because anyone disliked it. It could not handle the product configurators the business was built on. A store that sells ‘product A for €40’ is exactly what off-the-shelf platforms are designed for. A store that sells ‘your dimensions, your material, priced live as you choose’ is not a styling problem. It’s the core of the business, and it fell outside what the platform could do.
That alone might have been survivable. The second problem was not. Every order was being processed by hand: confirm the payment, create the deal in the CRM, log the accounting entry, book the shipment, generate a PDF invoice, email it to the customer. Thirty minutes of manual work, spread across four separate tools, repeated for every single order.
At a dozen orders a week, a person can do that. The business was about to expand across Europe – 32 countries, a different VAT rate for every market. The manual flow that worked locally would not survive that. It wasn’t a cost you could absorb; it was a wall.
So we built custom. The manual order flow became a single automated pipeline: payment confirmed, and the CRM, accounting, shipping, invoice, and customer email all happen without anyone touching them. Thirty minutes became under two. The configurators the platform couldn’t do became the front door of the store.
There’s a part the ‘custom is a last resort’ framing gets wrong, though. Once you’re on the right side of that line, custom stops being a compromise you settle for and becomes a lever. Pikkuna’s store runs exactly the way the business runs – not the way a platform assumed it should. The configurator Shopify couldn’t model is the thing customers come for. The order pipeline nobody touches is a cost that stays flat while volume climbs. A competitor running the same business off-the-shelf is capped at whatever that platform allows; Pikkuna isn’t. That’s not damage control – it’s an edge you can only get by building the software around the business instead of bending the business around the software.
That’s the shape of a real ‘build custom’ decision. Not ‘we wanted more control.’ Specific business logic – real configurators, per-market VAT, an order flow spanning four tools – that the platform structurally could not do, on a scale where doing it by hand would have broken the business.
slug="e-commerce"
text="I build custom e-commerce and business platforms for companies that have hit a real wall with off-the-shelf – configurators, multi-market VAT, automated order flows across CRM, accounting and shipping. If you’re not there yet, I’ll tell you that too."
/>
The Signals, Made Concrete
You don’t need a Pikkuna-scale expansion to justify custom. You need at least one of these to be true, and true about your core business, not your wishlist:
- The platform can’t model what you sell. Configurable products, real-time custom pricing, quotes instead of fixed prices, bundles the app store can’t express. If the way you price and package is fundamentally not ‘product × quantity,’ you’re fighting the platform.
- Your business logic spans tools it can’t cross. The moment an order touches your CRM, your accounting system, your shipping provider, and your invoicing – and the platform expects each of those to be a separate manual step – you’re paying people to be the integration. Automating a flow like that is often where custom pays for itself first.
- Compliance is a first-class part of the sale. Per-market VAT, VIES validation for B2B buyers, reverse-charge invoicing, region-specific payment methods. On the pi-pi.ee B2B platform, a German buyer expects their VAT number validated against the EU registry and the correct reverse-charge notation on the invoice – automatically. Platforms treat that as an edge case. For some businesses it’s the whole transaction.
- You’re paying enterprise pricing to work around the platform. Shopify Plus and its equivalents can do a lot, at enterprise pricing that runs from roughly €25,000 a year well into six figures at scale – plus bespoke development for everything they still can’t do natively. When the platform tier is expensive and you’re still building around it, the ‘cheaper’ option stopped being cheaper.
- The workaround has become the process. A spreadsheet three people edit at once. A manual copy-paste step nobody’s allowed to skip. A ‘temporary’ fix from two years ago that’s now load-bearing. If nobody actually owns the glue holding your systems together, that’s a risk, not a system.
If none of these describe you, you probably don’t need custom software. That’s not a disappointing answer. It’s a saved budget.
The Honest Version of This Decision
There’s a version of this conversation where a developer tells you that yes, you absolutely need custom software, and quotes you for it. Of course they do – that’s what they sell.
The version I try to have is different. Sometimes the right answer is ‘keep using Shopify, you’re not using half of what you already pay for.’ Sometimes it’s ‘you need one integration, not a rebuild.’ And sometimes it’s ‘the platform genuinely can’t do the thing your business runs on, and every month you spend working around it is money and risk you’re absorbing quietly.’
Telling those three situations apart is the actual job. It’s closer to what an IT partner does than what a developer does – asking what your business actually needs before anyone quotes a build. A build that solves a configuration problem is worse than the configuration you started with. A platform that can’t run your business is a ceiling you’ll keep hitting until you deal with it.
Custom software development is worth it exactly when the platform is the thing in your way – and not one day before.
If you’re weighing a platform against a custom build and you’re not sure which side of that line you’re on, let’s figure that out before you commit to either.
