1. Home
  2. Docs
  3. ccBegin
  4. Design Philosophy

Design Philosophy

We at Cleveland Consulting have been building custom FileMaker solutions for customers large and small for over 20 years. We have seen any number of development and design standards come and go, and have built up a huge portfolio of solutions in every version since FileMaker 2.

For our own internal use we have developed a number of launching points to begin new systems. These internal systems have been a huge help in getting a project up and running very quickly, without bringing anything unnecessary to the project a client doesn’t need. We have benefited so much from them we have decided to make them available to the community at large so others who wish to can benefit from the jump start they offer to new projects.

The systems and CCBegin in particular, are all built on two founding principles:

Design only matters when you get it wrong.


You should be able to fix any problem where you find it.

What does this mean for the system it’s self?

First of all design. Rather than build something from scratch trying to reinvent an elegant, battle tested user interafce that would appeal to a wide range of users, we have leveraged Google’s fantastic Material Design standards as best we can in a FileMaker system. This means we have chosen element arrangements, sizes and field and button interactions that closely mirror or directly reflect what Google suggests in their published standards. This gives us systems that are very comfortable to users, and systems that feel polished and complete. This makes roll-out and training easier and gives end users a sense of confidence in the system.

In addressing our “fix it where you find it” motto, first let me explain what I mean by it.

What we try to achieve is a system where no concept is stored two places. If taxes need calculated, we store that calculation one place, if inventory needs updated, the process to update inventory in central to one script, called with the parameters necessary regardless of the inventory type or the reason it’s updating.

What this has done is led us to adopt a “MVC” architecture for developing our systems. We have taken this approach in our starter solutions as well. Every script does one thing, which is done nowhere else, and it does it very efficiently and robustly. This means our systems have more scripts than other systems, but this brings an efficiency that makes support much simpler.

These two guiding principles are at the hear of all our systems, and are at the heart of the success of our starter systems.

Was this article helpful to you? Yes No

How can we help?