The short version.

Your FileMaker file is where the data lives. Your staff keeps using FileMaker exactly as they do today. The web app is an addition — a separate URL, a separate front end — that reads from and writes to the same FileMaker data over the Claris-provided Data API. You get a modern experience for the users who need it without pulling your team out of the tool they already know.

This pattern is boring in the good way. It has been production-viable since Claris shipped the Data API, and by 2026 the surrounding tooling — FastAPI on the Python side, HTMX or a small React app on the front — makes it faster to build than it has ever been.

A concrete example: the fleet manager.

A rental company runs forty vehicles across a metro area. Drivers pick up vehicles at the depot in the morning and return them at night. Every trip requires logging mileage, fuel level, and any damage — historically on paper, then re-typed into FileMaker by an office admin at end of day. Two things were breaking: paper forms got lost, and the delay between damage happening and it being recorded meant billing customers for it was messy.

What we built. A small mobile web app the drivers open on their phones. Login by phone number and a short code. One tap opens the truck they are assigned to. They log mileage, snap a photo of any damage, tap a fuel-level slider, submit. The submission hits a FastAPI service running on the shop's Mac. The service authenticates to FileMaker Server through the Data API, writes the record into the existing Trips table, and stores the damage photo in a container field. The office admin sees the trip in FileMaker within seconds — same layouts, same reports, same everything they already know.

Nothing changes for the staff who work in FileMaker. Everything changes for the drivers who used to fight with paper.

The web app is about 300 lines of Python and a small mobile-optimized HTML template. The FileMaker side needed one new script (accepting the record insert) and no layout changes. Total build time: under three weeks including the driver training UI and the damage-photo review screen for the office admin.

What connects the two.

The default path is the FileMaker Data API — a REST endpoint that FileMaker Server exposes. It handles authentication, record CRUD, script execution, and container-field uploads. For SMB workloads (dozens of writes a minute, a few hundred authenticated sessions, straightforward record fetches) this is exactly the tool. The API has been stable through several FileMaker Server versions and Claris has continued improving it.

For higher-volume or complex-query cases, two other paths exist. OData — Claris added it in more recent versions — is useful when the consuming tool (Power BI, some ERPs) speaks OData natively. And when a workload genuinely outgrows what the Data API is designed for — very high query rates, dashboards refreshing every few seconds, integrations that need sub-second reads — a synced SQL layer is the right answer. A small process reads changes from FileMaker on a schedule and replicates them into Postgres or SQLite, giving the web app fast reads without ever hitting FileMaker Server directly. Writes still flow back to FileMaker so it remains the system of record.

Most projects do not need the synced layer. It is worth mentioning because a competent proposal should tell you it exists and when it makes sense — not because it will be on the estimate.

What this pattern is genuinely good at.

  • Customer portals. Give your customers a login that shows their orders, invoices, or open service tickets — pulling live from FileMaker without them ever seeing FileMaker.
  • Mobile field access. Drivers, inspectors, technicians, delivery crews. FileMaker Go works for some of these; a lightweight web app works for the rest, especially when the phone belongs to the person and installing FileMaker Go is friction.
  • Payment forms. Stripe or similar. The web page handles PCI concerns; FileMaker never sees a card number; the payment result writes back to your existing invoice records.
  • Public-facing forms. Loss-and-damage reports, event registrations, contact requests. The submission lands in FileMaker as a normal record.
  • Dashboards for non-FileMaker users. Owners, executives, contract partners who need a look at the data but do not need or want a FileMaker license or a FileMaker layout.

What this pattern is not.

It is not a migration. Your business logic still lives in FileMaker. Your staff workflow does not change. The web app is an extension of the system, not a replacement for it. If the business ever does decide to migrate, this same web app becomes the starting point of the new front end — but that decision stays yours, on your timeline.

The prototype-first offer.

Not every FileMaker system is shaped the same way. Some have twenty years of scripts and layouts that a web front end needs to understand. Some have data volumes or concurrent-user patterns that push toward the synced SQL layer sooner than you would expect. Some have licensing that constrains the options.

When the project has any of these uncertainties, I build a working prototype against your actual FileMaker data before you commit to the full project. Small scope, fixed price, one week, ends in a working demo you can test with. If it works, we scope the full build from there. If it does not, you have concrete information about why — and you have not spent the full-project budget to learn it.

If a proposal sounds too clean for a 15-year-old FileMaker system, that is worth being suspicious about.

What to do next.

The free triage call is the right way to start. You describe what you want the web app to do, how many users, what data it touches. I tell you which of the three connection patterns fits, roughly what the build costs, and whether the prototype-first step is warranted. Thirty minutes, no pitch, and you leave with enough information to decide.