Every FileMaker developer I know has two lists. There is the ticket queue, and then there is the other one: the things that have been there for years, the ones you will get to one day. The data model that grew into a shape nobody would choose on purpose. The integration that works fine, as long as the right person is in the office.

 

 

Ask why one of them is still there and the answer is almost never "I never found the time". It is six other things. The scope is unclear and nobody has mapped the dependencies. The process is too critical to stop for a day. There is no uninterrupted time, because urgent work always wins. It crosses FileMaker, web, APIs, hardware and process all at once. And it still works, well enough.

What those six share is not the size of the work. It is how much of your attention the thing asks for, in a week that has none spare. Every one of them comes with the job: knowing the system is what makes you the person everyone asks, and being the person everyone asks is what takes away the hours you would need to look at it properly. I say that as someone who sells help with exactly this problem and still has a list of his own.

You need to find out why first

There is one thing you can do while all six of those are still true: find out what is actually wrong.

In 2014 I drew a four step loop for performance optimization: Measure, Identify Bottleneck, Optimize, Repeat. Now I have rephrased it to Evidence, Identify, Improve, Repeat as I found out it works in general, not just for performance. Evidence means counting something instead of remembering something.

 

 

Sometimes the unit is seconds. Just as often it is not. Do you check for errors after every commit? And how about after every Go to Layout? Everyone knows who last modified a record. Do you also know who deleted which record, and when? When did you last try to recover a backup, to verify that it is actually recoverable?

Each answer is a count or a date, and each one turns an opinion into something you can put in front of a manager. You have evidence when you can answer in one sentence, without the word "probably" in it. The step people skip is the second one: Identify. They collect the evidence, dislike the number, and improve the thing they always suspected. That is how a system gets optimized three times and stays slow. That is how the root cause remains and issues keep coming back.

Find yourself a technical buddy

The fix for a list that never moves is not another tool, another method, or getting up earlier. It is one person, in your calendar, on a repeating appointment.

I call it a technical buddy. One technical person from outside your building, an hour a week or half an hour every two weeks, booked and repeating rather than called when something goes wrong, because by then you have no time. It gets you four things at once. A standing hour, which is the only kind that happens. A second opinion, because you cannot be your own. A wider view, from somebody who works on other systems and has time to explore options you do not. And a backup who already knows your system when you are away, or busy.

 

 

Do you want to try it out with us? Call me at +420-608301880 or Book a call

But it does not have to be us. Just not a friend who has every reason to agree with you, or a supplier waiting for a brief. And it should not be an AI chatbot. What you want is someone alive, capable of forward thinking, close enough to care what happens to your system, far enough away to tell you when it is wrong.

Keep the AI beside the conversation

Why recommend a conversation in 2026? Because of a loop I keep seeing. A customer describes what they want to their AI, which expands it into six pages. Or worse, sixty pages. The developer feeds those pages to their own AI, which summarizes them back down. The two people at the ends never exchanged a single thought.

Imagine you want an apple. You task your AI chatbot to write a requirements specification. It produces a nicely formatted document describing every small detail of the apple you want: the color, the size, the taste. But you're too busy to read it and because the AI has already done so much great work for you, you just trust it and send the document to your supplier.

The supplier uses AI as well. It lets them avoid spending hours reading your detailed specification. They simply ask: "summarize the specification and tell me only what I need to know to deliver what they are asking for." The AI summarizes the requirements clearly: "They want a red apple." So you get a red apple, but there is a worm in it you didn't ask for.

 

 

We use AI heavily, every day, so the claim is narrower than it sounds. Not less AI. Just never between two people who are trying to understand each other. One hour, two humans, talking. Then we task the AI together, and both of us know what was asked and why. The AI then helps us do what it is good at.

If you did not read it, do not send it. If they did not read it, it is not a specification.

Build beside, not instead

Recently I wanted FileMaker to watermark an image. Ten years ago that meant writing a plug-in and maintaining it for as long as the system lived. Two years ago I would have found somebody's online service and hoped it still existed next year. Last month, on a live stream, I had Claude Code write a small service that does exactly one thing, started it up, and my FileMaker database called it with Insert from URL.

That is not a story about AI writing code well. It is a story about effort. Look at what stood in the way each time: weeks of work and a plug-in to maintain forever, then a dependency on a service somebody else might retire. Web interfaces, APIs, hardware and AI-assisted steps carried obstacles like those, which is exactly how they reached your list in the first place.

 

 

And that is the part I did not see until I looked at my own list. Every item on it was filed with the effort the solution took when I filed it, and nobody ever goes back to re-estimate a list. Some of what has been sitting there for five years no longer asks what it asked then. The obstacle that put it there is gone, and what is left is an afternoon of attention rather than a project you have to carry. Looking harder at the list will not tell you which ones, because when you filed them the estimate was right. You find out by describing one out loud to somebody who spends their week on other systems. That is the wider view, and of the four things a buddy gives you it is the one you cannot do alone.

One hour, this week

The first conversation asks nothing of you but the hour. A standing arrangement with somebody outside your company may cost money. But it can be a small amount, and even half an hour every two weeks works. It is also much easier to justify once you have evidence instead of a feeling. And it does not have to be a company at all. The cheapest version is a peer, another developer with the same problem from the other side, each of you the other's buddy.

So think of the thing that has been on your list the longest. I am not asking you to fix it. I am asking you to say it out loud, every two weeks, to one person who is not you, starting with one question. Does this still ask as much of me as I think it does?

If you would like that person to be one of us, book a meeting, or simply call me on +420-608301880, and let us talk about how we can be useful to you.