A Quick Tip On How To Use FileMaker To Solve Industry Problems

Overview

Before you open FileMaker, draw the problem on paper first.

An order starts as a phone call. It becomes a note. The note becomes a line in a spreadsheet. The spreadsheet becomes an invoice. That is the whole path, and most of it happens before anyone touches a database.

Experienced developers map that path first. They are not being slow. They are checking they understand the business before they build anything for it.

A resource worth reading

If you want to build that habit, read “Database Design for Mere Mortals” by Michael Hernandez. It never mentions FileMaker. That is the point.

The book teaches you to find the real objects in a business before you think about tables or fields. An order is an object. A customer is an object. A payment is an object. You find these on paper, with a pen, away from any software.

What it gets right

• it makes you list every piece of information before you store any of it
• it forces you to ask who uses each piece of information, and why
• it shows you how one badly placed field creates years of cleanup later
• it treats the interview with the business as the real work, not a warm-up

Why this matters for FileMaker

FileMaker is fast. You can build a working layout in an afternoon. That speed is useful, but it also lets you skip the mapping step and still end up with something that runs.

Something that runs is not the same as something that fits. A system built on a guessed process will need rework the first week someone uses it for real.

FileMaker speeds up a process. It does not invent one for you. The order of steps, the people involved, and the handoffs between them all exist before you open the software. Your job is to find that order first, then build for it.

Do you draw the process on paper before you build, or do you build first and fix the process as you go?