Blog

Technical notes on FileMaker development

This is where I think out loud about how I build — structure, architecture, naming discipline, long-term maintainability. The decisions that determine whether a system holds up over time.

There’s no shortage of excellent technical content in the FileMaker community — tutorials, deep dives, technique breakdowns. That’s not the focus here.

Some posts will go into implementation details or specific techniques — but always as a consequence of those principles.

Written with FileMaker developers in mind.

I’ve been building FileMaker systems since 2003. That’s long enough to have developed strong opinions — and long enough to keep refining them. Take what’s useful, adapt it, or discard it.

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. Five files, each with a role, each with 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.