From Monolith to Microservices: My Journey at Safarway

In 2018, I quit my government job to join a tourism startup with no name, no office, and no users. What followed was a full monolith-to-microservices rewrite mid-product — and I still don't know if it was the right call. It was terrifying.

How It Started

When I was freelancing, I worked with an amazing man who dreamed big about tourism. We worked on a local project together. When he saw the result, he asked me something bigger: let's build the best Arabic platform for tourism.

That man became the owner. And I said yes.

The owner and I started from nothing. We needed an office. We bought computers. We tried to hire senior engineers to work at a company that didn't exist yet.

The pitch didn't work well. But somehow we built a small team anyway.

We used Vue on the front-end, Laravel on the back-end, MySQL for the database. Standard stuff. I knew it. We could move fast. I knew about servers and deployments, but I didn't know anything about CI/CD.

For 4-5 months, we almost finished the MVP.

The Pivot

Then we contacted a senior DevOps engineer. He said: if you want me to join, I'll rebuild the whole infrastructure. We should use microservices. We should use Node.js or Python instead of Laravel.

I'd never worked with microservices. No one on our team had.

The owner said yes.

We threw away 4-5 months of work and started over.

The Long Hours

I was a team lead and engineer. I had to understand microservices well enough to teach my team. I'd never done it before.

I worked 11-13 hours a day. Seven days a week. Some weeks I felt like I was disappearing.

The rewrite took another 4-5 months. We used Express.js. We split everything into separate services. We learned as we went. Every day brought new problems: how do services talk to each other? Who owns the database? How do we deploy all of this?

I didn't sleep much. But I learned.

Two Years In

By the time things stabilized, I'd learned more about building real systems in 2 years than in the 5 years before. Safarway grew. We hit 1 million downloads. The system worked. Each service could scale on its own.

It actually worked.

But I kept thinking: did it work because we built microservices, or despite building microservices?

What Sticks With Me

I lived a startup from the beginning. I saw how real companies form. Not in blog posts. In a room with people figuring it out.

Hiring the right person mattered more than picking the right technology. We hired someone who knew infrastructure. The tech was just what he knew.

Here's what bothers me though: I learned a lot about microservices. But I still think most startups should start simple. Build one thing. Keep it clean. Build it modular. Don't split it apart until you have to.

You know when you have to? When one part of your system needs way more power than the rest. When your team can't work on the same code without stepping on each other. When deploying one feature breaks something else.

We had an expert to guide us. Most startups don't. We had time and money to spend rebuilding. Most don't.

If I could tell 2018 me anything: start simple. Understand your business first. Pick fancy architecture when the business needs it, not because it sounds cool.

Key Takeaways

Hiring someone who owns infrastructure will shape your entire architecture — the technology is just what they already know.
Rebuilding a working monolith as microservices costs 4–5 months before you've validated a single product assumption.
Before splitting services, your team needs concrete answers: who owns which database, how do services communicate, and how do you deploy them independently.
Microservices earn their complexity only when one part needs to scale independently, teams are blocking each other in the same codebase, or a single deploy breaks unrelated features.

After

I left Safarway in 2021. I wanted to try something new. I wanted to build with a remote team.

The microservices thing was one of the most intense things I've done. I also don't know if it was the right call at the time. But it helped me later when I worked with Asal Technologies.

The best lessons are the ones you question and then use anyway.