"Dushnylo" Series: Monolith First approach.

I keep hearing, “You MUST start with a monolith.” Every new project? Always?

When I hear that, two thoughts immediately come to mind:

    1️⃣ “It depends.” You can’t just blindly say every project must start as a monolith.

    2️⃣ My inner Dushnylo whispers: “Time to make a post about this.”

So, here’s my take: I disagree. Not only do I disagree, but I believe the most critical and dangerous part of system design is analyzing and understanding business needs before making architectural decisions.

Why? Simple. Imagine you’re building a streaming platform that processes massive amounts of data, handles notifications, and integrates with third-party services. Does this sound like something you’d build as a pure monolith? Of course not. But I do agree on one thing—you have to start somewhere.

That starting point could be a simple core application—yes, it might look like a monolith at first. But you’re not designing the entire system as a monolith. Instead, you’re building additional components around the core to meet business needs.

So why do people insist on “monolith first”? Because too often, engineers rush into microservices without understanding how their system should work. They waste time crafting dozens of services, struggling with communication between them, dealing with data transfer headaches—all because they skipped the analysis phase. They don’t know what they actually need to build and just follow trends instead of using their brain.

You might say, “But isn’t that the same as saying start with a monolith?” No. I’m saying:

    ✅ Start by thinking.

    ✅ Analyze what needs to be done.

    ✅ Design the system based on business needs.

    ✅ Begin development in the simplest way possible—by crafting the core instead of rushing to build infrastructure around nothing.

Monolith or not, architecture isn’t about dogma. It’s about making the right decisions at the right time.