How to divide a system into maintainable modules

You built a FileMaker solution three years ago to handle order intake. Then someone added invoicing to it. Then inventory. Then a portal for your resellers. Now every change — even a small one, like adding a discount field — takes a developer half a day, because they first have to figure out what else in that giant file might break.

This is what happens when a system grows without being divided into modules. Everything touches everything, so nothing can be changed safely, tested in isolation, or handed to a new developer without weeks of onboarding. This article walks through how to actually split a system into modules that stay maintainable — not in theory, but in the way it plays out in a real FileMaker, ERP, or custom-built business application.

What does it actually mean to "modularize" a system?

A module is a self-contained piece of functionality with a clear job, a defined interface, and as few hidden dependencies on the rest of the system as possible. Think of it like a shipping container: what's inside can be anything, but the outside connectors are standardized, so any crane, ship, or truck can move it without knowing what's packed inside.

In business software terms, that means:

• Orders, Invoicing, Inventory, and CRM are separate concerns, even if they share data.
• Each module owns its own tables/data, business logic, and screens.
• Modules talk to each other through defined interfaces (a script call, an API, a shared value list) — not by directly reaching into each other's internals.

The opposite of this is what most aging systems look like: one giant file where the invoicing script reads directly from six tables that also belong to inventory, CRM, and reporting, and nobody remembers why.

Why does a monolithic system become unmaintainable over time?

It's rarely one bad decision — it's hundreds of small, reasonable-at-the-time ones. A developer needs the customer's discount tier while building the invoicing screen, so they just query the CRM table directly instead of asking for it through a proper interface. Six months later, someone changes the discount tier field in CRM, and invoicing quietly breaks in a way nobody notices until a customer complains about a wrong invoice.

Multiply that pattern by a few years and a few developers, and you get:

• Fear of change — nobody wants to touch a script because they don't know what else calls it.
• Slow onboarding — a new developer needs weeks just to understand what's connected to what.
• Regression bugs — fixing one thing breaks something unrelated, because "unrelated" things were never actually separated.
• No safe place to test — you can't test the new inventory feature without also risking the invoicing module, because they share the same file, tables, and scripts.

This is exactly the maintainability problem described in our article on how to keep business software maintainable as it grows — modularization is one of the core techniques for solving it, not a nice-to-have.

How do you decide where the module boundaries should go?

This is the part most teams get wrong — they split by technical layer (all screens together, all scripts together) instead of by business capability. The boundaries that actually hold up over time follow the business, not the code.

Ask these questions for each candidate boundary:

1. Does it map to a real business process? Order intake, warehouse picking, invoicing, and customer support are each things a specific person or team owns. That's a strong signal for a module boundary.
2. Does it change for its own reasons? If your finance team changes invoicing rules independently of how the warehouse changes picking rules, those should be separate modules — even if they share a customer record.
3. Could you replace it without touching the rest? If you swapped your invoicing module for a different tool tomorrow, would the rest of the system still work? If yes, it's already well-bounded. If everything would break, it isn't a module — it's a tangle.
4. Who needs to see it? A reseller portal and an internal warehouse dashboard have completely different audiences and security needs. That alone is a reason to separate them.

A concrete example: in a distribution company we worked with, "Orders" and "Shipping" looked like one process from the outside, but shipping had its own carrier integrations, label printing, and exception handling that changed constantly for reasons that had nothing to do with how orders were placed. Splitting them let the shipping logic evolve — new carrier APIs, new label formats — without ever touching the order-entry screens.

What does a well-designed module interface actually look like?

The interface is the contract: what a module accepts as input, and what it promises to return — regardless of what happens inside it. In a FileMaker system, this typically means:

• Script parameters and results instead of scripts that reach into other modules' tables directly.
• A defined set of "public" tables or views that other modules are allowed to read, versus internal tables that stay private to the module.
• APIs for anything crossing outside FileMaker — e.g., a REST endpoint that lets your webshop or Exact Online talk to the ERP without needing to understand its internal schema.

A good test: if you can describe what a module does in one sentence without mentioning field names or table structure — "Invoicing takes an order and produces a PDF invoice and a bookkeeping entry" — you probably have a clean interface. If the description requires explaining internal table relationships, the boundary is leaking.

[[IMAGE:left|boxes labeled Orders, Invoicing, Inventory connected by labeled arrows, not tangled lines]]

How do you modularize an existing system without a risky, all-at-once rewrite?

You almost never get to modularize a system from scratch — you have a live, working system that the business depends on today. The realistic path is incremental:

1. Map what exists first. List the modules you can already see informally (Orders, CRM, Invoicing, Reporting) and note where they currently cross wires — direct table references, shared scripts, hardcoded field names from another area.
2. Pick the module causing the most pain. Usually it's the one changed most often or the one every new feature seems to touch. That's where modularizing pays off fastest.
3. Wrap before you cut. Before physically separating tables or files, introduce an interface layer — a script that acts as the "official" way to get customer discount data, for example — and route all other modules through it, even while the underlying data still lives in the same place.
4. Migrate call by call. Replace direct references with calls to the new interface one at a time, testing as you go. This is slower than a big rewrite but far less likely to take down a system your business runs on.
5. Only then separate the data, if it makes sense — sometimes moving a module into its own file or its own set of tables, once nothing depends on its internals anymore.

This mirrors how good API-first integrations work: you don't ask every connected system to understand your database schema, you give them one stable endpoint and let your internals change freely behind it.

Does adding AI to your system change how you should modularize it?

Yes — and this is worth planning for now, not after the fact. Tools like Claris AI (Klai) inside FileMaker let you add AI-assisted features — summarizing a customer's history, drafting a response, flagging anomalies in orders — directly into your workflow. But an AI feature is exactly the kind of thing that should sit in its own module: it calls out to an external model, it has its own cost and latency profile, and its logic will change fast as the underlying AI capabilities improve.

If your AI logic is scattered directly into your Orders and CRM scripts, every model change or prompt tweak becomes a system-wide edit. If it lives behind a clear interface — "give me a summary for this customer ID" — you can swap models, adjust prompts, or add new AI capabilities without touching the modules that use it.

What about the interface layer itself — does that need attention too?

Often yes. As systems grow, the forms and portals users interact with become their own maintenance burden, especially when they need to work well on mobile, in a browser, or need a more modern look than a decade-old layout allows. This is a module in its own right. Tools like FMBetterForms let you build modern, responsive interfaces on top of FileMaker without rewriting your backend logic — which is a good example of the same modularity principle applied to the UI layer: the interface changes independently of the business logic underneath it.

What's a practical checklist before you start splitting a system into modules?

• Can you name each module in one sentence, without referencing table or field names?
• Does each module have a clear owner (a person or team) in the business?
• Do modules talk to each other through scripts/APIs, not direct table access?
• Could you replace one module's internals without breaking the others?
• Are AI features and integrations isolated behind their own interface, not scattered through business logic?
• Is there a written (even informal) map of which modules exist and how they connect?
• Have you started with the module causing the most current pain, rather than the easiest one?

FAQ: common questions about modularizing business systems

Does modularizing mean splitting into separate files? Not necessarily. In FileMaker, modules can live in the same file as long as the internal interfaces (scripts, layouts, table access) are respected. Separate files add deployment and syncing overhead, so only split files when there's a real reason — different security needs, different release schedules, or a genuine need to reuse a module elsewhere.

How many modules is too many? If you need a diagram to remember what a module does, it's probably fine. If you need a diagram to remember how many modules exist, you've probably over-split. Aim for boundaries that match real business processes, not artificially small pieces.

Can small businesses skip this and just keep one big system? For a very small, stable system with one developer and no growth plans, strict modularity is over-engineering. The moment you add a second developer, a second business process, or plan to integrate with another system (a webshop, an accounting package, an AI tool), modularity starts paying for itself quickly.

What's the biggest mistake teams make when modularizing? Splitting by technical layer (all reports together, all data entry screens together) instead of by business capability. That produces modules that still change together constantly, which defeats the purpose.

Dividing a system into modules isn't a one-time project — it's an ongoing discipline that pays off every time you add a feature, connect a new system, or bring in a new developer. If your FileMaker system, ERP, or custom application has grown into something that's hard to change safely, Loggix can help map out where the real module boundaries should be, build the API interfaces and integrations that let those modules talk to each other cleanly, and — where it fits — add AI tools or modern interfaces without disturbing the logic underneath. Sometimes that means a hands-on consultancy session to draw the map before any code changes at all.