Blog
Technical notes on FileMaker development
This blog is about FileMaker architecture. It is written for FileMaker developers.
It is an attempt to derive, from architectural constraints, a coherent model for building systems that remain predictable, understandable, and maintainable over time.
The ideas discussed here are not new to the FileMaker community. No claim is made that they originated with me. They reflect the work of many contributors to our shared body of knowledge as FileMaker developers. They are presented here through the perspective of the architectural model developed throughout this series.
The ideas explored here are grounded in production systems. The series develops and formalizes an architecture that continues to evolve through real-world use.
Thoughtful discussion strengthens ideas. Questions, constructive criticism, and different perspectives are always welcome.
— Karim Hanafi
June 24, 2026
Maintainable FileMaker Systems · Article 10 of 18
Execution Model: Roles
A request envelope carries an address. Something must read it. The gap between the envelope and the method is not empty — it has a defined shape.
June 15, 2026
Maintainable FileMaker Systems · Article 9 of 18
Contracts: The Communication Surface
A method without a contract is a unit of behaviour with no surface. The architecture has defined the method. It has not yet defined how the method communicates.
June 9, 2026
Maintainable FileMaker Systems · Article 8 of 18
Methods: The Contract Unit
The structure has no remaining place to hide behaviour. What is left is not a design choice. It is the only thing that was never excluded.
June 6, 2026
Maintainable FileMaker Systems · Article 7 of 18
Graph, Naming, and Schema as Controlled Surfaces
Article 6 allowed UI reads. Article 7 constrains what those reads can mean. Three observable surfaces — graph, naming, schema — are brought under the same enforcement discipline.
April 26, 2026
Maintainable FileMaker Systems · Article 6 of 18
Building the Skeleton
The physical structure is known. This article instantiates it. Three types of files, each with a role and constraints that follow from that role.
April 16, 2026
Maintainable FileMaker Systems · Article 5 of 18
One File Is Not an Architecture
No architectural constraint can be enforced inside a shared execution space. The file boundary is the only structural primitive that changes that. This article proves why.
April 12, 2026
Maintainable FileMaker Systems · Article 4 of 18
The Structure the Constraints Require
Constraints don't only exclude behaviours. They require a structure. That structure can be described. It cannot yet be guaranteed.
April 7, 2026
Maintainable FileMaker Systems · Article 3 of 18
How FileMaker Solutions Collapse Under Their Own Logic
The failures aren't random. Each one is a predictable consequence of a violated constraint. Once you see the mechanism, you can't unsee it.
April 3, 2026
Maintainable FileMaker Systems · Article 2 of 18
What Decades of Software Engineering Can Teach a FileMaker Developer
The failures that kill FileMaker systems aren't FileMaker problems. They're system problems — and software engineering solved them a long time ago.
March 26, 2026
Maintainable FileMaker Systems · Article 1 of 18
Building with FileMaker — Beyond "It Works"
The limits of FileMaker's native model — why a system can work and still be fragile.