Building Our Own CRM in Laravel and PHP: Why We Left FileMaker and What We Learned

I have written the software my businesses run on for most of my working life. When our property company outgrew its last system, I rebuilt it from scratch in PHP using the Laravel framework. It went live in late February 2026 and has run the business since the end of March. This is why I chose Laravel, how I went about it, and what I would tell anyone thinking of doing the same.

Why we left FileMaker

In 2021 we moved our CRM onto FileMaker Cloud. I chose it because it was a quick way to get the system off our own server and into the cloud, and it did that job.

The trouble was everything around it. It was hard to connect to our accounts, our email, our phone system and, more and more, to AI. Each connection became a workaround. I came to the conclusion that low code is not low effort: you save time at the start, then pay it back every time you want the system to do something its makers did not plan for. In November 2024 I wrote myself a note: "I am going to move away from FileMaker."

Why Laravel and PHP

I looked at the options before committing and chose PHP with Laravel. It is open source, so there are no licence fees, and it runs on an ordinary Linux server. Our hosting costs about £20 a month.

I did not start with the business system. I built a site that did not matter first, so that I understood how Laravel worked before trusting it with the company. This site, and the rest of our content network, runs on Laravel too.

Design it on paper first

In October 2025 I designed the new system on paper and went through the requirements in depth with the office team before writing any code. From that first paper design to going live took about four months. That time on paper paid for itself.

The system has grown to 122 tables and 61 screens. Of the 58 changes we have recorded to the database structure since, only three altered an existing column. Only one was a genuine design mistake: two status flags where one would have done, and it was removed within a day. Most of the changes have been additions, not corrections, and that is what you get when the people who will use the system have already told you how they work.

How we moved off FileMaker

Getting the data out was straightforward. I exported each FileMaker table as a CSV file and imported them into SQL Server, the database behind the new system.

We then ran both systems side by side for six weeks, so anything missing or wrong in the new one could be checked against the old records before we relied on it alone.

I used Claude Code, an AI coding assistant, to help with the junior work. The design and the decisions stayed with me. Help like that is a big part of what makes a project like this realistic for a small business today.

The save button problem

The biggest complaint after launch had nothing to do with features. People kept forgetting to press save, moved to another screen and lost their changes.

I looked at the options and moved the screens to Livewire, a Laravel package that lets a page talk to the server as you work without writing much JavaScript. Now every change is saved the moment it is made, and I added an undo button for the times someone changes something by mistake. It made more difference to the people using the system every day than anything else I built.

Your situation may be slightly different. ask a question below ↓ and our editorial team will reply with our advice.

What our CRM does

• Pulls bank transactions from Sage and checks them against what each tenant should have paid.
• Monitors tenants' credit ratings.
• Connects to email, printed post and our 3CX phone system.
• Uses AI to read safety certificates and to summarise phone calls and emails into actions for the team.

A lease record in our CRM, with private details blurred. Dates, breaks and reviews, the rent schedule, documents, deposit, meter readings and notes all sit on one screen, and the Document Manager can open Claude to draft a letter or email.

None of that came in a box. Each piece was added when we needed it, which is the real reason to build your own.

Why build rather than buy

• Speed. When something is wrong or missing, I change it. There is no explaining it to a developer or waiting for a supplier's next release.
• Cost. About £20 a month for hosting, and everything is built on open source software.
• It fits the business. The system works the way we work. We do not bend our processes around a product built for someone else.
• Keeping up with AI. New AI tools arrive every few months. I can try them in our own system straight away instead of waiting for a vendor to add them.
• Reliability. The system has never gone down on its own. The only outage was one I chose: in October 2026 I took it offline while waiting for a patch for a PHP security vulnerability. Keeping our tenants' data safe mattered more than a perfect record.

Should you build your own CRM?

Only if you, or someone who will stay with the business, can write and look after the code. A bespoke system with nobody to maintain it is a liability.

I learned a related lesson many years ago, when I sold copies of an earlier CRM to two other companies. The support questions that followed took up my time, and I realised I was really selling my time. Since then every system I have built has been to run a business I own, and I would give the same advice to anyone else: build for yourself, not to sell.

If you do go ahead:

• Learn the framework on something that does not matter first.
• Design on paper with the people who will use it before you write code.
• Save every change automatically from day one. Nobody remembers to press save.
• Add connections to email, phones and AI as you need them, not all at once.
• Patch security problems straight away, even if it means a little downtime.