Developers create a starter file

On several occasions over the past few decades, in local and international settings, I have asked fellow developers if they created a starter file for themselves. If so, why did they do that, and if not, why do they refrain from it? The answers were as varied as there were people present.

Seasoned developers had totally different settings in which they worked. Some had a single client and worked for decades only for that specific client. Others created standard software solutions, which they continuously improved. These working environments didn’t need any starter files due to a lack of new projects. There was simply no reason to use a starter file.

Others repeatedly told me that each project was different and no starter file could cover the different needs. Usually these were larger projects with many stakeholders.

Still other developers did create starter files for themselves. They regularly started new FileMaker projects. Each new project had basic demands, like navigation, text label management, user management, and the like. To build these functions from scratch for each new project had some drawbacks: It took time, even when copying bits and pieces from other projects; it was prone to bugs (like any development); and it was repetitive work for basics a client doesn’t even think about. A starter file solves these questions.

Using your expertise

Starter files require time to build. The time you put into creating such a file does pay for itself, as it simplifies new projects considerably. Starter files can be maintained, updated, and enhanced whenever you learn a better method. Creating your own starter file is helpful as you can add functionality you already developed and are familiar with. Your own starter file can cover your personal preferences. Each time you update a starter file, the next project will benefit.

To be clear, this is not about creating ready-made solutions. It is about functionality in the background. Think of a basic theme, a basic structure for your next project, utilities like search functions you always use, or more demanding basics like a user management solution or a dynamic navigation. All these things require substantial work to figure them out, test, and improve them. If you put these things into a file, you can start a new project by duplicating that file and rely on proven functionality.

Prepare for every scenario?

What should a starter file do? Only you can define that for your situation. However, I have seen people preparing for every possible scenario and by doing so, creating a huge starter file. If that feels good to you, go for it.

Personally, I think you cannot prepare for every scenario, and your next project benefits from a sleek setup. You might have a smaller project. There is no need to start with a huge file for a small project. Less might be more. Considerations of what needs to be part of a solution are helpful. One does not strive for perfection, but for usability. If you have a smaller starter file, you need not reduce the functionality but can simply refrain from using certain parts. That doesn’t create a bulky overhead. The file is small anyway.

As I have upgraded my starter files over time, I also came to the conclusion that a clean setup benefits from a modular approach. This allows you to create a navigation as a single part of your starter file, which can easily be replaced or enhanced over time. Another constructive idea was to put settings in a dedicated interface for the developer. That greatly improves efficiency, as settings once hidden in scripts were now openly visible. Everything became easier to manage and more about configuration.

Configurations also answered the idea that every project requires a different approach. If configurations count for that, a starter file can be used in multiple and different scenarios.

Start building

I also met FileMaker developers, who said they wished to have a starter file for new projects but did not have the resources to make one. Some asked around and found other developers willing to share what they had already assembled. Another option is to purchase a starter file, as offered on this website, and use that as a starting point.

Over time, any starter file you start to use will be enhanced. You will improve it, change it, or enhance it. That is precisely what should happen. You should make it your own. The most important thing is to start, however limited it is at first.

What I typically see is that having a working and reliable starter file gives you an advantage. If you speak with a client on a new project, you probably can cut weeks, if not months, from the development time by using a starter file. You also could use a FileMaker starter file to quickly assemble a navigable mockup for a new project (RAD, Rapid Application Development) and present it the next day and ask something like, “Is this the workflow you had in mind?”.

Learning FileMaker

There is yet another reason to build or purchase a starter file. To start building a starter file can be seen as a personal development project. Learn to become a better developer. Nobody knows everything. A starter file is not a client project, more like a playground for your personal ideas. While building a resource, you become a better developer. Enhance your skills and create something useful. Select the functions you think are needed most. Build from scratch or copy and paste from older projects, then enhance and test.

If you are new to FileMaker, you benefit from other developers. They can help you get started and help you solve issues you encounter.  You can book a course, “of course”, or work for certifications. A different hands-on approach could be the use of an already assembled starter file. By using one, you look, so to speak, over the shoulder of another developer and see how they did something. You also have a working starting point for your next project. That might be quite efficient to learn how to use FileMaker.