How DDD (almost) killed the startup I work for

#designpatterns #cleancode #sass #startup

Introduction

I joined a startup a few months ago as a junior software engineer. This startup provides a B2B SaaS and was founded six years ago by a solo non-technical founder. To start his journey and create the software, the founder chose to work with an IT service company.

This IT service company has its own “framework” to quickly build a all-in-one solution including, backend, back-office and mobile applications. The software was developed, released, and used by many clients (each with thousands of users) over six years.

For various reasons (not the subject of this article), the relationship between the founder and the IT service company came to an end and the founder made the decision to stop the collaboration and to hire tech profiles to build new internal version.

V1 to V2

Remember my previous sentence “This IT service company has its own “framework””, and as you know every benefit comes with a drawback. That custom framework enabled fast development, but came with a cost: it was overly complex and unfamiliar to most developers. So we made the decision to start from scratch.

Objectives

The main goal was quite simple: build a completely new software product within 12 months.

This new version must have all V1 features and add a few new ones. The plan was to build an entire new version, start to onboard new clients and migrate V1 clients.

Was DDD the Right Choice?

As many other software design, infrastructure, patterns, etc, sounds all time good and has many advantages ! But all has a cost, and the cost of this technical choice on the company was really important.

During 8 months, we were coding following DDD and many problems occurred during this development phase. Let’s break it down :

Too Much Boilerplate: When you follow DDD (especially at the beginning of a project) there are so many files to create, even the smallest feature. Each new feature requires new entities, repositories, mappers and so on. To achieve a minor task, adding a simple GET route, for example, you create 1, 2, 3, …, 8 files, and the PR is so huge, and if someone wants to rename a concept he has to rename all files, it’s really overwhelming. This causes frustration among developers, reduces productivity, and slow down code workflow.
Steep Learning Curve: DDD is a great approach, but it still needs to be implemented correctly. In our team, only one developer on the team had real expertise in this approach and DDD has a steep learning curve. Instead of focusing on (real) important things, we spent a lot of time learning and the expert spent a lot of time teaching each other and reviewing all PRs to ensure that all principles are followed.
Low Flexibility: At the stage we were at, we had to be able to change something quickly and frequently. Sometimes a task specification is not clear, or the product vision not taking technical constraints into account and so on. Once you started to model your domain in the software, it’s very complicated and time-consuming to change a detail.
Developer Frustration: The overhead, complexity, and friction created resentment in the team. Everyone wanted to move faster, but the process felt heavy and academic.

Conclusion

On paper, DDD is a powerful and well-thought-out approach. But our company didn’t need “perfectly architected software” — it needed progress, fast iterations, and revenue. In our case, DDD didn’t fail because the principles were wrong. It failed because we applied it in the wrong context. After switching to a simpler, pragmatic architecture, things moved faster (built 70% of our software in 4 months compared to 30% in 8 months). We focused on delivering value instead of enforcing patterns — and we finally started onboarding clients. This experience taught me something essential: clean code and smart patterns are only valuable when they serve the product and the team. Every technical choice is also a business decision.

So don’t choose DDD — or any architecture — because it’s trendy or “clean”. Choose it because it solves a real problem you have right now, with the resources you actually have.

I’d love to hear from other developers who tried DDD in a startup context. Did it work for you? Or did you run into the same issues we did?