← All work

case study · Techcrowd s.r.o.

Real estate CRM

Role
Backend developer, CRM from scratch
When
2025 → 2026
  • PHP 8.4
  • Laravel 12
  • MariaDB
  • n8n
  • REST API

The situation

Two estate agencies merged. Each of them arrived with its own system, and what they needed was one: a mobile app, an admin panel and, eventually, a CRM to run the business from.

It was also the first time I worked on something designed as microservices, and I was sceptical from the first week. For a team this size the split bought us very little and cost us a lot of ceremony — separating the code by domain inside a single repository would have drawn the same boundaries. I had no experience with microservices at that point, though, so I didn’t want to arrive being negative about something I’d never built.

What I did

I was on the project twice. In January and February 2025 I built the forms for rental and sale listings and helped design the foundations of the API. Then I moved elsewhere, and came back in the autumn when the client wanted a base for an internal CRM.

From December to January I built that base — leads, contacts, the domain model underneath them. In February we added webhook support and put n8n behind it, and that’s the decision worth writing about. Instead of us developing every integration the agency asked for, the application fires a webhook and the client wires up whatever service they need on the other end. They stopped ordering small connections from us, and we stopped maintaining them.

Three more senior developers were on the project alongside me, and two juniors at the start. With a fixed deadline and inexperience showing, I took the harder tasks myself and had less time for the juniors than they deserved — I was focused on the result. It was also the first time I properly saw what AI does in the hands of a developer who can’t yet judge what they’re handing over. The code arrives fast, it looks plausible, and reviewing it takes longer than writing it would have.

How it went

We handed the project over in the spring of 2026. The client built their own internal team and took development in-house, and because everything had run on their infrastructure from the start, there were no servers to hand over with it — only the code and what we knew about it.

It started on PHP 8.2 and Laravel 11 and went across on PHP 8.4 and Laravel 12.

What I’d do differently

I’d argue against the microservices. Not because they’re wrong in general, but because they were wrong for a team this size and a product still deciding what it was, and I could see it in the first month. Domains separated inside one repository would have given us the boundaries without the overhead. I spent that year reading my way to being certain of it — articles, other people’s post-mortems — while continuing to build it the other way.

The rest of what I’d change is about people rather than code. A fixed deadline made me choose between delivering and teaching the juniors, and I chose delivering — probably the right call for that project, still the part I’d want to do better. And I spent a lot of that year arguing about quality with developers more senior than me: API documentation that didn’t match the API, tests that never got written. I still don’t know why they wouldn’t write them. What I do know is that I never found a way to ask that changed anything.