There’s a moment every FileMaker developer knows. You’re three scripts deep into a sync routine, manually parsing JSON, juggling global fields to hold state, and wrestling with nested loops that made perfect sense at 2 PM but became unreadable by 5 PM. The logic works — barely — but you already dread what it’ll look like six months from now. You know nobody (including future-you) will want to touch it.
That feeling isn’t a skill issue. It’s an environment problem.
FileMaker Is Brilliant… At What It’s Brilliant At
Let’s get one thing straight: this isn’t a critique of FileMaker. It’s a genuinely great tool. It’s still one of the fastest ways for small teams to build real business solutions — excellent for rapid UI development and reliable data persistence. Decades of successful deployments prove it.
The problem isn’t FileMaker. The problem is forcing it to be something it was never designed for: a full-blown environment for complex business logic.
Scripts are linear and monolithic. Logic ends up scattered across triggers, calculations, custom functions, and parameters until no single place tells you what the system actually does. There’s no real package ecosystem, no proper testing pipeline, and debugging complex call stacks is painful. You can use a coding agent to help write the scripts faster — but they’re still the wrong tool for the job.
The Reflex
The solution lives in FileMaker, so naturally we build it in FileMaker. That’s the reflex. No one questions it.
You push harder: more scripts, cleverer JSON parsing, another layer of table occurrences, more globals holding temporary state. It ships. The client is happy. And twelve months later, when you (or whoever inherits it) opens the file, that familiar dread returns.
This reflex isn’t laziness — it’s loyalty to the platform. But loyalty shouldn’t mean ignoring what the platform simply isn’t great at.
The Inversion
Before writing the next script, ask yourself one question: Does this logic really have to live here?
In most integration work — sync routines, data transformations, API orchestration, geo queries, classification pipelines — the honest answer is usually **no**. That logic can live anywhere that can read from and write to FileMaker data.
Since FileMaker 19, the platform offers a clean, standards-compliant OData API that any external system can use. Your complex logic can now live in Node.js, Python, or any modern environment where coding agents thrive, where you have rich package ecosystems (npm, PyPI), real testing, version control, and maintainable code.
FileMaker stays focused on what it does best: a trusted data store and user-facing surface. The complexity moves to terrain where it’s far cheaper to manage.
This isn’t a workaround. For many scenarios, it should be your first instinct.
Three Times This Was the Right Call
PrestaShop Sync — Inversion by Structural Complexity
Syncing a FileMaker product catalog with a PrestaShop store sounds simple on paper. In practice, you’re dealing with nested variants, category hierarchies, stock updates, price rules, and bidirectional conflict resolution across two very different data models.
You can build it all in FileMaker scripts (and many have). The result is usually thousands of lines of scattered script steps, manual JSON parsing everywhere, and error handling added as an afterthought. It becomes nearly impossible for a coding agent — or another developer — to understand or extend.
The inverted version: Build the sync logic as a clean module on the PrestaShop side that talks to FileMaker via OData. FileMaker just triggers the process and stores the results. The code stays readable, testable, and something an AI coding assistant can actually help improve quickly.
Cadastral Geo Queries — Inversion by Capability Absence
A real estate solution needed users to draw a polygon on a map and find all properties inside it, filtered by multiple criteria.
Get Francesc Sans’s stories in your inbox
Join Medium for free to get updates from this writer.
FileMaker has no geometry support, no `ST_Within`, no spatial indexes — nothing. The capability simply doesn’t exist in the platform.
Solution: Use PostgreSQL with PostGIS for the spatial work, a WebViewer for the map, and a lightweight API to connect them. FileMaker stores the core data and search history. Each system does what it does best.
Sometimes the inversion isn’t optional — it’s required by the limits of the tool.
NACE/CNAE Activity Classifier — Inversion by UX Impossibility
Spanish businesses must classify their activity using the CNAE system (aligned with European NACE) — a five-level hierarchy that’s tricky to navigate unless you already know the top categories well.
The traditional FileMaker approach (cascading value lists, globals, complex relationships) works technically… but creates a bureaucratic interface that real users quickly grow to hate.
The inverted solution: A chatbot connected to the full official classification database. Users describe their business in plain language, and it returns the correct chain in seconds. The entire FileMaker scaffolding could be retired.
The cleanup on the FileMaker side was worth it on its own.
What the Other Answer Looks Like
To be fair, there’s a strong alternative. Wim Decorte and the Soliant Consulting team have done excellent work building a framework to make agentic coding work inside FileMaker — careful skills, deterministic XML tools, schema navigation tricks, etc.
It’s rigorous and thoughtful. But it’s also a sophisticated harness built to make a general-purpose system function inside a closed platform that wasn’t designed for it.
That harness is the right answer if you must stay inside FileMaker. The real question is whether you actually have to for integration and complex logic work. Often, the answer is no.
What You Actually Gain
Moving logic outside isn’t just about reducing friction. You land in a genuinely better place:
- Coding agents can freely read, trace, refactor, and test the code.
- Mature package ecosystems give you battle-tested solutions instead of building everything from scratch.
- Proper version control and clean handoffs to other developers.
- Your FileMaker solution becomes simpler, lighter, and far more maintainable.
OData provides a clean, stable, standards-compliant bridge in both directions.
When Not to Invert
This isn’t a universal rule.
If the logic is simple and the data lives in FileMaker, keep it there. Quick operations — like summarizing a note, basic classification, or parsing an address — are perfect for a fast API round-trip that updates a field.
Invert when the logic starts outgrowing the platform: when you’re building scaffolding to support scaffolding, when script counts keep climbing, and when maintainability drops off a cliff.
Closing Thought
FileMaker is where your data lives and where your users work.
It doesn’t have to be where every problem gets solved.
