When YAGNI Actually Makes Sense

5 things worth building before they’re needed.

May 17, 2025

low angle photography of building — Photo by Matthew Henry on Unsplash

YAGNI—or, for short, You Ain’t Going to Need It—is a software engineering principle that states we should avoid adding unnecessary features until they become real user needs.

The gist of it is that when you are implementing a feature that users don’t need or use, it will add some hidden costs that you and your team must pay1:

Cost of Development — Analyzing, programming, and testing the feature.
Cost of Delay — Postponing the implementation of features users actually requested.
Cost of Carry — Maintaining, debugging, and extending the feature over time.
Cost of Repair — Rewriting or fixing the feature if you misunderstood the real need (spoiler: you probably did).

Imagine you are working on the MVP for a mobile app, and your team decides to add support for dark mode.

After all, you’re developers. You love dark mode; surely your users will, too. 🖤

But this decision comes with a price tag.

The development cost is clear: the team must scope, implement, and test the entire app’s UI in both light and dark modes.
The delay cost is less obvious: while you’re obsessing over dark mode, your users are still waiting for must-have features like basic settings or notifications.
The carry cost shows up later: every new feature has to be tested in both themes, increasing QA overhead.
And when users finally demand dark mode—well, odds are you didn’t get it quite right the first time, and you’ll need to rework it. That’s repair cost. 🤷‍♂️

When YAGNI Is Actually Good

As a tech lead, I always push my team and the product owners to challenge their decisions against YAGNI.

From a tech perspective: Don’t write extra code “just in case” because someone vaguely mentioned it might be needed next quarter.

From a product perspective: Don’t delay checkout implementation just to make the add-to-cart button glow in the dark.

But sometimes, what looks like YAGNI turns out to be low-cost, high-leverage work that pays off long-term, especially if tackled early.

Here are five areas where “just-in-case” actually makes sense:

1. Software Architecture and Design

This is not a feature per se; however, when starting a new software project, it is worth considering the high-level aspects and thinking about the components, their relationships, and how they are arranged in your system.

The goal is to defer as much as possible the decisions on what tech stack you will use to power your application (database engines, external services, etc.) and make them pluggable to your system.

2. i18n and l10n

Internationalization and localization scream YAGNI straight from the bat, especially when the app supports only one language.

However, considering localization from the beginning and implementing the required abstractions in your app might be one of the best acts of kindness you do for your future self.

3. Code Formatting and Linting

Every team should define its coding standards—rules and guidelines that dictate how code should be written, formatted, and organized—to work efficiently together.

The best time to do it? When you start the project. Don’t forget to automate these decisions with linters and code formatting tools.

4. Logging and Analytics Hooks

This is an aspect that should be considered when considering your software's architecture and design.

The idea is not necessarily to implement logging and analytics from day one, without any concrete business needs.

However, the design should allow logging and analytics to be injected into the app without having to rewrite every use case or repository method when they become a priority.

5. Time Zones Support

Time zones deserve their dedicated section, even though they fall under i18n.

You should consider user time zones if your application contains date and time-sensitive information. We are no longer bound by the country we live in, and users might access that information from other time zones while traveling.

Thus, make sure to account for time zones across all the layers of your application.

Closing Thoughts

Have you ever added something early that felt like over-engineering… only to thank yourself later?

Maybe a bit of abstraction, some early i18n scaffolding, or a logging hook you added “just in case” saved the day six months later.

I’d love to hear your story.