When developing software, we constantly hear the same concepts: Clean Code, Design Patterns, Clean Architecture, MVVM, MVI, MCP.
At their core, these approaches are not designed primarily for users, but for making the development process more sustainable.
And to be fair, they work.
"Doesn't all this strict architecture slow the project down and turn development into a tangled mess over time?"
This is a common complaint among developers. On the other side, there's a strong counterargument:
Without these structures, many large-scale systems simply wouldn't survive. Yes, they may cost performance and time, but the real goal is finding the right balance.
From the user's perspective, the situation is much clearer. Users don't care about the architecture behind the product. They care about the quality of the service they receive.
This brings us to the key question: When building software, who should we focus on first? Developers or customers?
A. Developer-Centric Approach
Medium to large-scale projects usually involve multiple developers working together. In such environments, shared rules, architectural principles, and agreed-upon conventions become essential.
Without them, familiar questions arise:
- "Why does this class exist?"
- "Who wrote this code, and for what reason?"
A structured, standardized architecture improves collaboration, reduces conflicts, and lowers long-term maintenance costs.
The Trade-off: These approaches often consume more CPU and RAM, slow down development, and can introduce unnecessary complexity especially for smaller projects.
B. Customer-Centric Approach
In customer-focused projects, the priority is clear: speed and performance. Developers may intentionally compromise on architectural purity. The key question becomes:
Does this product help the user achieve their goal efficiently?
In this model:
- Time and resources are allocated directly to customer satisfaction
- Performance is a critical metric
- The "cleanest solution" is less important than the "most effective solution"
The Risk: When shared rules are weak, developer alignment suffers. Each developer may follow their own mental model, which can make the project fragile and hard to scale over time.
So, What Should We Do?
Developer-centric and customer-centric approaches both have strengths and weaknesses. My personal view is straightforward: the most effective strategy is a hybrid of both.
I say this as a .NET developer, where the ecosystem naturally leans toward strict rules, clear contracts, and well-defined boundaries. Backend development, by nature, favors discipline and structure.
The Hybrid Mindset
Having strict rules doesn't mean ignoring the customer perspective. On the contrary, we must constantly ask:
- "Which data does the user access most frequently?"
- "How can we index this more efficiently?"
- "Where can we gain performance without sacrificing stability?"
In areas like GDPR, where there is zero tolerance for mistakes, both legal compliance and user data privacy become top priorities.
Conclusion
Using modern architectures and patterns can look impressive. But software development isn't about pleasing a single group. In reality, we must balance the needs of three key stakeholders:
- Shareholders (founders, executives, investors)
- Developers
- Customers
The Pragmatic Approach
Instead of applying heavy architectures to every project, we should ask:
- How many users are we targeting?
- How many developers are working on the project?
- What is the expected lifespan and scalability requirement?
For smaller or simpler projects, Clean Code and SOLID principles shouldn't be ignored, but they should be applied in a lighter, more pragmatic form.
This allows teams to ship faster, avoid unnecessary complexity, and save time and resources.
Finally, architecture decisions should always align with team culture and company vision. In customer-driven organizations, speed and performance take priority. In engineering-driven environments, architectural discipline naturally becomes more important.