Build, buy or extend: how to choose

Your current software got you here, but it's starting to slow you down. Orders fall through the cracks, your team maintains shadow spreadsheets alongside the 'official' system, and every new requirement means a workaround instead of a solution. The question isn't whether to act — it's which direction to go: build something custom, buy a ready-made product, or extend what you already have. This article gives you a clear, practical framework to make that call with confidence.

Why the wrong choice costs more than you think

Most software investment mistakes aren't made during implementation — they're made in the ten minutes before the vendor demo, when the decision was already half-made emotionally. A wholesale distributor commits to a new ERP because a competitor uses it. A professional services firm extends a legacy FileMaker system one more time because nobody wants the disruption of a switch. A manufacturer builds something custom because IT is confident they can. All three can be the right answer. All three can be a costly mistake. The difference is whether the decision was driven by the business problem or by habit, fear, or enthusiasm.

What does 'outgrown your software' actually mean?

Before choosing a path, be specific about what has broken down. Vague dissatisfaction leads to vague decisions. Here are the four real failure modes:

1. Capacity failure — The system can't handle the volume. A manufacturer running 200 production orders a week in a FileMaker solution that was built for 40 will experience slow screens, locking conflicts, and unreliable reporting. This is a performance and architecture problem.
2. Scope failure — The system was built for a narrower version of your business. A wholesale distributor who has since added a B2B webshop, a returns process, and three new product categories is now forcing those processes into a system that was never designed for them.
3. Integration failure — Your software has become an island. An order gets entered into the ERP, then re-typed by hand into Exact Online — every single order, every single day. The system works fine in isolation; the problem is the gap between systems.
4. Knowledge failure — The system works, but only two people understand it, one of whom is about to retire. This is a maintainability and documentation problem, not a functionality problem.

Identifying which failure mode (or combination) applies to you is the first real step. The right answer to a scope failure is different from the right answer to an integration failure.

The three paths explained honestly

Buy: when an off-the-shelf solution is the right call

Buying a standard product — whether that's a cloud ERP like Exact, AFAS, or NetSuite, a CRM like HubSpot or Salesforce, or a vertical solution for your industry — makes the most sense when your problem is standard. If your core processes look like everyone else's in your sector, you don't need custom software; you need good configuration and a clean migration.

When to seriously consider buying:

• Your processes match industry best practice closely (>80% fit without customisation)
• The software category is mature and competition keeps vendors honest
• You lack the internal capacity to maintain custom code long-term
• You need to be live quickly and your process can adapt to the tool

The honest gotcha: Off-the-shelf solutions look cheap at the start and get expensive at the edges. A professional services firm that buys a standard project management platform and then spends 18 months customising it to match their invoicing logic has, in practice, built a custom solution on top of a licence fee. The customisation cost doesn't disappear — it moves to consultancy and integration work.

Build: when a custom solution earns its cost

Building a custom solution — whether in FileMaker, a web application, or another platform — makes sense when your process is genuinely differentiated and that differentiation drives commercial value. A manufacturer with a proprietary configure-price-quote process that no standard CPQ tool can model accurately has a real justification to build. The software is, in effect, a product asset.

When building is justified:

• Your core process is a genuine competitive differentiator
• No standard product covers more than 60% of your requirements without heavy modification
• You have (or can hire) ongoing development capacity to maintain and evolve the system
• The cost of adapting your process to fit a standard tool is higher than the cost of building

The honest gotcha: Custom builds are routinely underscoped. A wholesale distributor who commissions a custom inventory and order management system often discovers mid-build that the scope was based on how the business worked two years ago, not how it works today. Every month of development is a month the business keeps changing. Budget for iteration, not just delivery.

Extend: when evolution beats revolution

Extending an existing system — adding modules, building API connectors to adjacent tools, modernising the data model, or improving the UI — is the most underrated option. It preserves institutional knowledge, avoids the disruption of a full migration, and can often be done incrementally without halting operations.

A professional services firm running a mature FileMaker-based project and billing system doesn't necessarily need to replace it. Adding an API connector to their accounting package (eliminating the manual re-entry), building a client-facing portal on top of the existing data, and refreshing the reporting layer might deliver 90% of the value of a full rebuild at 30% of the cost and risk.

When extending makes sense:

• The core data model is sound and the data is clean
• The main pain is at the edges (reporting, integrations, UI) rather than at the core
• The business can't absorb a full migration without significant operational disruption
• Key users have deep familiarity with the existing system — that knowledge has real value

The honest gotcha: Extending can become a trap when it's used to avoid a harder conversation. If the core architecture is broken — the data model is denormalized beyond repair, the logic is undocumented, the platform is end-of-life — then extending is expensive scaffolding on a crumbling wall. Be honest about whether you're extending a solid foundation or delaying an inevitable rebuild.

A practical decision framework

Use the questions below as a structured way to pressure-test your instinct before committing to a direction.

Step 1: Diagnose the actual failure mode

• Is the problem capacity, scope, integration, or maintainability? (See above.)
• Would fixing the specific failure point solve the problem, or is it symptomatic of something deeper?

Step 2: Audit the fit of available standard products

• List your 10 most critical process requirements.
• Score each standard product candidate: how many of the 10 does it cover without customisation?
• If the best candidate scores below 7/10, buying is likely to become an expensive hybrid anyway.

Step 3: Assess your maintenance capacity

• Do you have (or can you afford) ongoing development resource to maintain a custom or extended solution?
• If the answer is no, a well-configured standard product with strong vendor support is often more sustainable than a bespoke system that nobody can maintain after the builder leaves.

Step 4: Calculate total cost of ownership — not just licence cost

• For buy: include implementation, configuration, customisation, annual licence, and migration cost.
• For build: include development, testing, documentation, training, and ongoing maintenance.
• For extend: include discovery, development of new modules/connectors, regression testing, and the opportunity cost of keeping the old platform.

Step 5: Stress-test for the 3-year horizon

• Will the solution still fit your business if revenue doubles? If you add a new sales channel? If key staff turn over?
• The cheapest solution today is not always the cheapest solution in 36 months.

Real-world scenarios

Manufacturing — FileMaker ERP extended with API integration A mid-sized manufacturer had a FileMaker-based production planning system that worked well internally but was completely disconnected from their suppliers. Purchase orders were emailed as PDFs, confirmations were re-entered manually, and delivery delays weren't visible until they hit the shop floor. The right answer wasn't to replace the ERP — it was to build an API layer connecting FileMaker to the suppliers' order portals, with automated status updates flowing back into the production schedule. The core system stayed intact; the integration failure was fixed directly.

Wholesale — legacy system replaced with a configured standard ERP A wholesale distributor had outgrown a custom order management system built in the early 2010s. The data model couldn't support the product variant logic they now needed, the reporting was hardcoded and couldn't be changed without developer time, and the original developer was no longer available. The failure was at the core architecture level, not the edges. A configured standard ERP (with custom API connectors to their 3PL and webshop) was the right answer here — not because standard is always better, but because the foundation wasn't worth extending.

Professional services — custom FileMaker solution retained and modernised A consultancy firm had a FileMaker solution managing projects, time tracking, and invoicing. They were being pushed by their CFO to move to a standard platform. The audit showed their invoicing logic — with complex milestone rules, retainer management, and multi-currency billing — couldn't be replicated in any standard tool without significant compromise. The right answer was to keep the FileMaker core, modernise the UI, add a FileMaker Data API connector to their accounting software, and build a management dashboard in a modern reporting layer. No migration, no disruption, no loss of competitive logic.

Checklist: before you commit to a path

• Have you named the specific failure mode (capacity, scope, integration, maintainability)?
• Have you scored at least two standard product candidates against your real requirements?
• Have you mapped the total cost of ownership over 3 years for each path — not just the upfront cost?
• Have you audited the quality of your existing data and data model?
• Have you assessed your internal maintenance capacity honestly?
• Have you involved the people who use the system daily — not just management?
• Have you identified what would need to be true for your first-choice answer to be wrong?

Frequently asked questions

Can we mix approaches — buy one part and build another? Yes, and it's often the right answer. Many mature businesses run a standard accounting or HR platform alongside a custom operational system. The key is defining clear API boundaries between the two so that data flows reliably without manual re-entry. The danger is integration debt: every connection point between systems needs to be maintained.

How do we know if our FileMaker system is worth extending? Audit the data model first. If the core tables and relationships are logically structured and the data is reasonably clean, the foundation is probably sound. If the database has hundreds of tables with no clear logic, scripts that haven't been touched in a decade, and data quality problems throughout, the cost of extending may exceed the cost of rebuilding.

We've been told to 'move to the cloud' — does that change the build/buy/extend decision? Cloud deployment is an infrastructure question, not a software strategy question. A custom FileMaker solution can be hosted in the cloud. A standard ERP can be run on-premise (increasingly rare, but still possible). Don't let infrastructure preference drive the software decision — answer the software question first, then the hosting question.

What's the biggest mistake companies make in this decision? Underscoping the extend option. Most companies evaluate 'buy' thoroughly (demos, trials, RFPs) but evaluate 'extend' informally (a quick chat with the developer). The extend path deserves the same rigour: a proper technical audit, a realistic scope, and a total cost of ownership calculation.

How long should this decision process take? For a business-critical system, a proper evaluation — including requirement mapping, vendor assessment, technical audit of the existing system, and TCO modelling — should take four to eight weeks. Rushing this decision to save a month often costs six months of rework later.

When the answer isn't obvious

In practice, the hardest cases are hybrids: a system that's partially salvageable, a standard product that almost fits, or an organisation that lacks the internal clarity to commit to any direction. In those cases, the most valuable first step is usually a structured discovery process — a technical audit of the existing system combined with a requirements workshop — before any build, buy, or extend decision is made. Spending four weeks on discovery is almost always cheaper than spending twelve months going in the wrong direction.

At Loggix, this is exactly the kind of decision we help businesses work through — whether that means building a tailored FileMaker or web application from scratch, extending an existing system through API integrations or new modules, or simply doing the honest diagnostic work to figure out which path actually fits before any money is committed to implementation.