The Expensive Part Got Cheap

What the old systems really did well

Ask the people who use a well-built FileMaker system what they like about it, and they rarely mention the database. They talk about the screen that shows exactly what they need and nothing they don't. The one button that replaced twelve steps. The report that used to take an afternoon.

That was the real value: the process. Less clicking, less remembering, less thinking per task. The database, the logins and the sharing were the plumbing underneath: necessary, but not why anyone loved it.

That difference matters, because the plumbing and the process have gone in very different directions.

What does it actually cost to build software?

Mostly, it isn't the tools. It's the hours, and they go to two things.

The first is figuring out what to build. Someone has to learn how the work really gets done: who does what, in what order, with which exceptions, and what the business needs at the end of it. In the trade it's called requirements gathering, or business analysis. It takes patient conversations and careful listening, and it's easy to get wrong.

The second is building it. Software is a long list of precise instructions, and someone has to write every one of them, test them, and fix them when they break.

Both have always been expensive. Both are where the value hides.

Two ways to build

Traditional development means writing those instructions by hand in a general-purpose language like Python, Java or C++. These are open, standard tools: they cost little or nothing, they run almost anywhere, and nobody owns them. The catch was time. You started much closer to scratch, so you needed a skilled developer and a lot of hours.

Low code platforms like FileMaker took a different route. The common pieces came prebuilt: screens, buttons, reports, a database, logins. Instead of writing everything, a developer (or someone with a willingness to learn) put those pieces together. For small organizations that was a real breakthrough. Projects that would have taken months by hand took weeks.

Either way, the code got paid for: in developer hours, or in a license for the code the platform wrote behind the scenes. Before AI, it was a pick-your-poison choice.

The trade-off

Those prebuilt pieces aren't free. Low code platforms are usually licensed per user and renewed every year, so the bill grows with the team. And the system only runs where the platform runs, so the license follows it for as long as you use it.

For years, that was a fair trade indeed. Hand-written code cost more in hours than the license cost in fees. For some organizations it still is. When a team uses much of what the platform offers, or a process fits it especially well, a low code platform like FileMaker still earns its keep.

For many others, the math has been drifting for a while. A platform license covers everything the platform can do, not just the part a team uses. Over the past ten to fifteen years, platforms have kept adding features and ways to connect, while the share many small teams actually use has stayed about the same. A team that needs a few screens, a handful of reports and a shared database still licenses the whole toolbox.

That gap was easy to live with when the alternative was months of hand-written code. In the age of AI, it's much harder to ignore.

What changed

AI can now write much of the code. The slow, expensive part of traditional development, turning an idea into working instructions, has become fast and affordable. People still decide what to build, check that it works, and make sure it fits how the team actually works. AI does the typing.

That flips the old math. Open, standard tools were always inexpensive to use. Now they're inexpensive to build with, too. The prebuilt pieces that justified the license aren't the shortcut they used to be.

It changes something else, too. Most organizations have a list of improvements everyone agreed would help but nobody could justify building. When building and adjusting get this much cheaper, that list is worth pulling back out.

That's the second expensive part. For an organization with a working system, the first one is already behind them.

"Aren't we just trading one technology for another?"

Fair question, and in a way, yes. That's how technology moves. When did you last enter data on a punch card? When did you last drive the horse and buggy to the store? Nobody misses them. Something better came along and became ordinary.

Is now the right time?

There's no perfect time for any change, and paradigm shifts don't arrive with a date on them. Each one has been easier to see in hindsight than in the moment. Moving early carries some risk. So does waiting for certainty. It isn't an exact science.

Some shifts are big enough that the question changes from "if" to "how." AI is one of them. The tools are here, they're improving quickly, and the cost of building software has already changed. That ship has sailed. What's left to decide is how carefully each organization makes the move, and that's where a working system, a parallel run and a step-by-step plan make the difference.

A working system is a head start

Decades of software projects point to one lesson: big, all-at-once replacements are where things go wrong. Switch everything over on one weekend, and every surprise shows up on Monday morning.

Replacing a system that already works is a different situation, because the first expensive part is already done. Years of daily use have settled what the system needs to do: the screens, the steps, the exceptions, the reports the business depends on. That's requirements gathering the team has already paid for, written down in the most reliable form there is, a system people actually use. It carries forward.

The working system is also a built-in benchmark. The new one can run alongside it on the same real work, and the results can be compared side by side. When the two disagree, it's worth a closer look. Sometimes the new system missed something. Sometimes the old one had a quirk nobody noticed. And sometimes it's a light bulb moment: a step the team has done by hand for years that the new system can simply take care of.

The move happens in stages. One piece at a time, the team starts working in the new system while the old one keeps running. If something isn't right, the old system is still there to lean on while the new one gets adjusted. When a piece holds up, the next one follows. The old system retires only when the team is confident, not on a deadline.

That's one of the real advantages of replacing a known good system: we already know what right looks like.

"If we own it, who keeps it running?"

It's a fair worry, and it's the best argument for staying put. The answer is to build something ordinary on purpose: standard tools, simple hosting, plain documentation of what each piece does and why. A system like that doesn't depend on one person or one vendor. Any capable developer, or the same AI tools that helped build it, can pick it up later.

What doesn't change

Security, backups and several people working at once still matter for real business data. The difference is that they're now ordinary, affordable parts of modern hosting. So the investment can go where the value always was: a process that works for the team.

What the off-ramp looks like

1. Talk it through. What does the current system do? What does the team rely on most? What's been sitting on the someday list?
2. Map what's really there. Every screen, script and report, and which ones the team actually uses. The list is often shorter than anyone expected.
3. Build the first piece. Something useful and self-contained, built on open, standard tools with AI doing the heavy lifting.
4. Run it side by side. The new piece works alongside the old system on real work until the results match, or until the new way is clearly better.
5. Move over in stages. One piece at a time, at the team's pace.
6. Retire the old system and hand over the keys. Plain documentation, simple hosting, and a system the team owns.