Pick the Problem Before You Pick the Platform

There has never been a better time to buy business software, and never an easier time to buy the wrong one.

Open a browser and you can have a new CRM, inventory system, job scheduler, accounting package or full ERP running by lunchtime. There’s a subscription for every function a business could name, and several for functions nobody had thought to name yet. Nearly all of them have an API, which means nearly all of them can, in theory, talk to each other. And behind every major platform sits a partner network of implementers, consultants and add-on vendors ready to help you customise it into exactly what you need.

That’s not a criticism of what’s available: in many cases, the tools are good. But the abundance has quietly changed the way businesses approach the decision. The conversation used to centre on “what do we need?” It now tends to jump straight to “which one should we get?” And that single reversal is behind most of the expensive, frustrating system projects we see.

Why does the order matter more than it used to?

When software was scarce, requirements gathering happened almost by accident. You had two or three realistic options, each one forced you to think about fit, and the constraints did some of your thinking for you.

Now the constraints are gone. You can pick almost anything and make it mostly work. You can bolt on a middleware layer to connect what doesn’t connect. You can hire a certified partner to customise what doesn’t fit. You can add another subscription to cover the gap the first one left. Individually, each of these steps seems reasonable. Unfortunately, the sum of them is a business running on a patchwork nobody explicitly designed, held together by integrations nobody fully owns, with a monthly software bill that keeps creeping up. The ultimate business result: a team that has learnt to work around the systems rather than having a system that works for the business.

Software has evolved in the twenty-five years I’ve been doing this, but the thing that didn’t change is this: if you don’t know what the business actually needs before you choose, you’ll spend the next two years finding out the hard way. You’ll chase your tail, shift direction, add middleware, and customise heavily on a stack that was never the right one to begin with.

Here are three examples of businesses we’ve seen up close, which make my point better than my rhetoric can.

The multinational that bought the platform first

A large industrial supplier operating across several countries in the Asia-Pacific region decided it was time to consolidate. Each regional office had grown its own mix of systems over the years, and head office wanted one view of stock, orders and margin across the whole group. A commendable goal for a business that had grown above and beyond expectations.

The decision was made at board level to standardise on a well-known enterprise platform, and a global implementation partner was engaged. The platform was chosen by head office, after a successful vendor pitch by the global leader, before anyone had documented how the regions actually operated. The assumption was that the software would impose the process.

It didn’t. Two regions sold through a slightly modified distributor agreement, a hitch long forgotten by head office, and needed consignment stock handling the platform didn’t do natively. Another region was far more project-heavy, where a “sale” could span eighteen months and dozens of part deliveries. Local tax and compliance differed everywhere. Consequently, each gap had to be closed with customisation, then more customisation, then a middleware layer to reconcile what the customisations had broken between regions. Eighteen months in, the group had spent several times the original budget, and the “single view” still needed a custom dashboard (dare I say it, ultimately a “spreadsheet”) to finish it.

When the programme was paused and restarted, the first thing that happened was the thing that should have happened first: a proper requirements exercise across every region, led by the business rather than the vendor. It turned out the regions had more in common than anyone had assumed, and the genuine differences were few and well defined. With that map in hand, the platform decision was revisited. Ultimately, the solution became the last decision, and (spoiler alert) it wasn’t the well-known enterprise platform. The total cost of ownership was far more attractive, too.

The franchise group that let each department choose

A state-wide franchise group with a few dozen locations had grown quickly, and the head office team had grown with it. Finance chose an accounting platform. Operations chose a scheduling and rostering tool. Marketing chose a CRM and email platform. Franchise support chose a ticketing system. Each was a sensible choice for its own department. Each had a good API.

The trouble was that a franchisee didn’t experience four departments. They experienced one head office, and the four systems didn’t agree on basic facts. A location’s trading hours lived in three places. Franchisee contact details were updated in one system and not the others. Royalties were calculated from sales data that had to be exported, cleaned and re-imported every month. Head office hired someone whose job was essentially to be the integration.

The group’s instinct was to buy a fifth system to sit over the other four. Before that happened, they stepped back and looked at the business as a single operating unit rather than four departments with four tools. The exercise wasn’t complicated. It was a matter of mapping what a franchisee needed from head office, end to end, and what head office needed to know about each location, end to end. That map showed that two of the four systems were doing half a job each, and that the real core of the business was a single record of each franchise location and everything attached to it.

Only then did the technology conversation begin. The answer was not a fifth system. It was a consolidation down to two, with a modest amount of purpose-built integration in between, and a single source of truth for location data that every other tool read from. The person hired to be the integration moved into a role that actually added value. This is the result we should seek from any new system: measurable, immediate and impactful gains in the business’s productivity and profitability.

The local business that nearly customised itself into a corner

A family-owned trade supply business in a regional centre ran on a combination of an ageing point-of-sale system, a separate accounting package, and a great deal of the owner’s memory. They had a loyal trade customer base, a growing online enquiry stream, and a stock problem: they never quite knew what was in the warehouse until someone walked out to check.

A vendor demonstrated an inventory and e-commerce platform that looked perfect. The owner signed up, and the vendor’s recommended implementation partner set about customising it. The first customisation was for trade pricing, which the platform handled differently from how the business quoted. The second was for the way stock was received, because deliveries arrived in units the platform couldn’t represent without a workaround. The third was a connector to the accounting package. Each one cost more than the subscription itself, and each one made the next platform upgrade harder.

Six months in, the owner was paying for a system that did most things adequately and nothing the way the business actually worked. What turned it around was a short, honest conversation about what the business needed to do every day: quote trade customers quickly and consistently, know what was in the warehouse, take online orders without retyping them, and stop double-handling invoices. Four requirements. None of them exotic.

Against that list, the chosen platform was the wrong shape. A simpler, more conventional stock and order system met all four requirements almost out of the box, with a standard accounting integration that needed no custom work at all. The migration was quicker than the customisation had been. The owner’s comment afterwards was that he’d spent six months paying people to bend a tool when he should have spent six days describing the job.

What do the three have in common?

The budgets differed by orders of magnitude. The complexity differed just as much. However, the core lesson was identical.

In every case the solution was chosen early and the requirements were discovered late, usually by paying for them. In every case the gap between what the software assumed and what the business did was closed with customisation, middleware or another subscription, and every one of those patches added cost and fragility. And in every case, once the business was described properly as a whole, the right solution was easy to identify and, notably, different from the one originally chosen.

That last point is the one worth underlining. The requirements didn’t just make the implementation smoother. They changed the answer.

How do you get the order right?

None of this requires a huge programme of work. It requires doing a modest amount of work in the right sequence, and it requires looking hardest at the part of the business most software demos skip over.

Start with the whole business, not the ends of it

Almost every system demo follows the same arc: a lead comes in, it becomes an order, the order ships, an invoice goes out, the dashboard lights up. It’s a satisfying story and it’s true for almost nobody.

For most businesses of any substance, the sale and the invoice are the easy ends. The real business happens in the middle. A transport operator doesn’t just take a booking and send a bill; it allocates vehicles and drivers, manages subcontractors, handles fatigue and chain-of-responsibility obligations, deals with a load that didn’t fit and a consignee who wasn’t there, and captures proof of delivery that finance can actually use. A pharmaceutical distributor lives in batch numbers, expiry dates, cold-chain logs, regulatory reporting and the ability to recall a specific lot from a specific pallet on a specific day. A manufacturer sits on bills of materials, work orders, quality checks and the difference between what was planned and what the floor actually did.

None of that is a sale and none of it is a delivery. It’s the operational middle layer, and it’s where the business earns its margin or loses it. It’s also where the generic platform is weakest and where the customisation bill comes from. So start the requirements work there: how does a job, a shipment, a batch or a consignment actually move through the business, step by step, hand to hand, and what has to be true at each step for the next one to happen?

Identify the real pain points, not the loudest ones

Every business has a few things that cost time, money or goodwill every single day. They’re usually well known to the people doing the work and often invisible in the boardroom. In an operations-heavy business they tend to hide in the handoffs: the moment a job passes from the planner to the driver, from the warehouse to the dispatcher, from the quality team back to production. That’s where paper appears, where the same data gets keyed twice, and where the phone rings because the system doesn’t know what the person on the dock already knows.

Write the pain points down, rank them, and be honest about which ones the business would pay to fix. The trade supplier’s stock problem was the real pain; the e-commerce platform was bought to solve an imagined one. The same thing happens at much larger scale when a business buys a beautiful customer portal while the depot still runs on a whiteboard.

Don’t let departments choose in isolation

The franchise group is the clearest example, but the pattern is sharper still when there’s a complex operational core. Finance chooses the system that makes month-end easy. Sales chooses the one with the best pipeline view. Operations, which does most of the actual work, inherits whatever the other two picked and is told to integrate with it. The result is an operations team living in exports and spreadsheets because the “system of record” was never designed around the thing the business actually does.

Systems serve the whole organisation, and data flows across departmental lines whether the software does or not. In an operations-led business, that usually means the operational flow should be the spine of the design and the commercial and financial systems should hang off it, not the other way round. Treat the business as one unit, not a set of disparate limbs, and make decisions at that level.

Never underestimate scoping

Once the business is understood and the pain points are ranked, scoping is where that understanding becomes a defined, costed set of requirements: what must be true for the project to succeed, what’s nice to have, what’s out. For a business with a complex middle, scoping is also where you find out which of your operational rules are genuinely unusual and which just feel that way. Most businesses overestimate how unique they are; a few underestimate it badly, and those are the ones that end up with a platform that needs re-engineering to do the basics. We’ve written about why a short scoping phase lowers the total cost of a project rather than adding to it, and the same logic applies with even more force to business systems, where the cost of a wrong choice is paid monthly for years.

Keep your options open: be wary of lock-in

A gentle word on something that rarely comes up in a vendor demo. Most of the serious platforms now have their own application frameworks, their own scripting languages, their own app stores and their own certified partners. Build inside that ecosystem and things get done quickly, which is the point. The cost is that every piece of logic you write there, every workflow, every custom screen, belongs to that platform’s way of doing things and moves nowhere else.

This matters most for anything customer-facing or anything that’s genuinely yours: a client portal, a driver app, a booking tool, a product your customers see as your product. The temptation is to build it on the platform’s proprietary framework because the data’s already there and the partner is already engaged. But, in my experience, that’s the decision requiring pause. Open source technologies and open standards are more mature and more accessible than they’ve ever been, and a customer-facing application built on conventional, widely used tools can sit alongside a commercial platform, read from it through the API, and still be entirely yours if the platform relationship ever changes. Some vendor dependence is unavoidable and perfectly sensible. Dependence you didn’t notice you were taking on is the kind that costs you later. We’ve written more about how to tell a safe platform dependency from an expensive one, and it’s worth a read before committing anything important to somebody else’s framework.

Make the solution one of the last decisions

This is the discipline the whole article comes down to. Platform, vendor, stack, partner, build versus buy, proprietary versus open: all of those are important decisions, and all of them are answered far more easily once the requirements exist. Choose early and you are committing to a set of assumptions you haven’t tested. Choose late and the choice tends to make itself. In all three businesses above, the right solution was obvious within days of the requirements being written, after months or years of being obscured by the wrong one.

The question isn’t “which system?” It’s “what does this business need to do, and what’s getting in the way?” Answer that, and the system question becomes a much shorter one.

What this means for you

If you’re looking at a new business system, an ERP, or simply wondering why the half-dozen subscriptions you already pay for don’t add up to something that works, the most valuable thing you can do is resist the demo for a few weeks and describe the business first. Properly, as a whole, starting with the operational middle that the demos skip, with the people who live in it every day.

That’s where we like to start. Not with a platform recommendation, but with the questions that make the recommendation obvious.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who has spent 25+ years helping businesses work out what they actually need before anyone writes a cheque. He’s seen more than one system chosen in an afternoon and untangled over a couple of years. Reach out to Simon if you’d like a clearer picture of your requirements before the vendors start calling.