By Mihaly Fodor (ERNI Romania)
Complexity is tempting, especially at the start of a project, when ideas are flowing and architectural ambitions run high. But without clear priorities and precise requirements, systems end up built for hypothetical scenarios rather than real benefits. A pragmatic, YAGNI-inspired approach helps you start lean while staying scalable.
Try to imagine a situation many of us know too well. Your software engineering partner has just received your new project assignment, and the kick-off meeting is charged with enthusiasm. As the customer, you arrive with a bold idea, an ambitious delivery date, and the hope that smart technology will rise to your challenge. Within minutes, the whiteboard disappears under sticky notes and marker lines: boxes, arrows, acronyms, tool names, deployment diagrams.
Voices discuss Kubernetes clusters, serverless functions and the merits of microservices versus a monolith. Passion grows, and in less than an hour, the team is deep in architectural debate while user stories still sit blank. Then someone finally asks, “What exactly should the user achieve in version one?” The room goes quiet. That silence exposes a familiar hazard: when enthusiasm outpaces focus, the team risks designing for imagined futures rather than present needs. If requirements remain vague and unprioritised, architecture becomes guesswork, and the solution ends up optimised for hypotheticals instead of real value.
The temptation of complexity
Requirements engineering is more than a checklist item; it is the foundation that supports a reliable architecture. Teams need a practical, well-defined scope that separates what must be delivered today from what can wait for tomorrow. This clarity protects the project from unnecessary complexity. Sound architecture begins with a clear purpose, not with a tool or pattern.
Yet many projects still begin with a wish list: “We need the full stack.” Microservices, serverless functions and multi-cloud setups appear before anyone writes a single user story. I once worked on a project where the customer believed an elaborate cloud design would boost B2B sales, while the solution to their challenge was simply a dependable ordering system. The gap between perceived needs and actual needs is where complexity grows. Here the YAGNI principle – You Aren’t Gonna Need It – proves its value. YAGNI keeps the team focused on delivering only what is necessary, when it is necessary – and it grounds every architectural decision in real requirements instead of assumptions.
Why over-engineering happens
Over-engineering often starts with good intentions but misplaced assumptions. Four patterns appear again and again:
These choices are usually driven by fear of future unknowns, blurred non-functional goals, or a culture that rewards complexity. The results are clear: slower delivery, fragile and complicated systems, higher operating costs, and decision fatigue that drains team energy. By the time a project team sees it has tried to do too much, the cost of change is already high.
The pragmatic process
My approach to requirements engineering is practical and tied to real-world limits and business value. It starts with orientation: a detailed review of every document, removing irrelevant claims to expose the few requirements that truly matter. Once clear, I move to sizing, checking core metrics such as expected users, data volume, service levels and release pace. Any unclear figure becomes an immediate question for the customer. I rate functional scope with T-shirt sizing (XS to XL), a quick method that flags oversized or vague demands early.
With this baseline, I sketch a minimal viable architecture – often just three boxes and two arrows. Anything that cannot fit on the whiteboard is challenged; if it does not fit, it likely does not belong in the day-one plan. Before estimates, a peer reviews the sketch and tests every assumption. The last checkpoint is to return to the business goal. If a design element does not support the main KPI, we drop it. The result is a lean, validated foundation shaped by evidence, not speculation.
A YAGNI-inspired reference case
A mid-sized manufacturer of sun-protection systems once asked us to design an AWS solution based on microservices, auto-scaling and separate teams for each service. The aim was to ‘future-proof’ a new ordering platform and keep it ready for growth. On paper, the plan looked modern and solid.
We soon learned that expected peak traffic was less than fifty concurrent users, far below the level that justifies a distributed setup. Even our first draft still contained load balancers and stateless services, assuming growth that was years away. The first AWS bills showed the flaw: the system was tackling problems that did not yet exist.
Using a YAGNI mindset, we removed the excess. We replaced the spread of microservices with a modular monolith, keeping clear internal boundaries so parts could be split later if demand rose. Load balancers went away, and deployment became straightforward.
The company met every business goal at roughly one-fifth of the former infrastructure cost. Time to market improved, maintenance became simpler and the team could focus on core features instead of cloud overhead. Just as important, the platform can still grow when real demand appears. This case shows that sound architecture starts with what is necessary, not with what is fashionable.
Lessons learned
The lean approach works because it stops scope from expanding too early. Clear limits produce simpler designs and more accurate estimates. Most pushback comes from a fear of lock-in. I address this by showing the defined seams where parts can be swapped later, but only when a measurable KPI demands it. In highly regulated or safety-critical fields, such as real-time trading or medical devices, extra robustness may be required from day one. Even then, every added layer should have a written, testable reason to exist.
For a deeper dive, we invite you to also read a practical case study about the role of requirements engineering in regulated environments: From life sciences to diagnostics: Engineering requirements for a regulated release.