Interfaces are not “future programming” or “unnecessary complexity”

They manage complexity and enable loose coupling.

If a senior dev tells you interfaces are only needed when you have multiple implementations:

That’s a red flag.

One implementation or ten: it doesn’t matter.

Interfaces exist to enforce boundaries, not to count classes.

Their value lies in how cleanly they separate concerns and reduce coupling.

Every now and then you hear the same story:

“You don’t need interfaces when you only have one implementation.”

It’s often framed as wisdom from a seasoned senior developer who claims to favor simplicity over premature optimization. And it’s usually followed by the same arguments:

• Interfaces with a single implementation are just future programming.
• They add unnecessary complexity.

But here’s the truth: software is already complex by nature. The real question isn’t whether complexity exists, but how you manage it.

Simplicity is important, but skipping interfaces because there’s only one implementation completely misses their purpose. Interfaces are not about counting implementations. They’re about separating concerns and enabling loose coupling.

In every project, complexity will eventually surface. If you don’t define where it belongs, it will spread everywhere.

Yes, in greenfield startup projects you hear “don’t over-engineer”. And I agree. But using interfaces isn’t over-engineering: it’s responsible engineering. A simple interface can reduce complexity instead of multiplying it.

I’ve worked on various long-running e-commerce systems. Examples of parts that tend to change at some point (and sometimes multiple times):

• Payment providers
• Accounting software
• Third-party fulfillment services
• Email sending providers
• Etc.

Why do they change? Poor service, rising costs, or a new accountant who insists on different software. And when those integrations are hard-wired across the codebase with no abstraction, refactoring becomes one of the most painful things you can do.

I learned that lesson the hard way. A few simple interfaces could have saved weeks of frustration.

Real-world lessons

I’ve seen this mistake play out in multiple projects.

In one case, we started with a single payment provider. It felt simple to just wire Stripe directly into services and controllers. Then the business needed PayPal. Suddenly, dozens of files had to change, and refactoring turned into a nightmare.

With Stripe wired everywhere, PayPal became a nightmare. An interface would have turned it into a non-event.

Another time, a client switched accountants. For them it was just a business decision. For us it was a disaster. The new accountant used different software, but our integration was scattered all over the codebase.

What should have been a simple swap became weeks of messy rewrites. A clean AccountingSystem interface would have kept the blast radius under control.

Fulfillment providers tend to change even more often. Shipping, tracking, and warehouse APIs come and go. If those integrations aren’t abstracted behind a clear interface, every change cascades through the system like falling dominos.

Interfaces isolate the churn so the rest of the system stays untouched.

These stories all point to the same principle:

Interfaces with a single implementation aren’t “future programming”. They’re a guardrail. They keep complexity in its place.

Loose coupling

This is the most important reason to use interfaces from the start.

Interfaces let you control dependencies between packages and modules by relying on abstractions, not implementations.

That’s how you keep boundaries clear: one module doesn’t need to know the details of another, only its contract. It’s a defense against complexity bleeding into the wrong places.

Domain Driven Design

I’m not going to dive into the full philosophy of Domain Driven Design.

But if you organize your application around business domains, you’ll quickly see why interfaces matter. They’re the glue between domains.

Even if you only have a single implementation at the start, interfaces help enforce separation and prevent dependencies from leaking.

Collaboration

Interfaces let teams move in parallel instead of waiting on each other.

Imagine you’re working on a feature with multiple developers. The implementation will take time. But you can quickly design a public API as a set of interfaces in no time.

That way, each developer can work in isolation, write tests against mocks, and move forward without waiting for the implementations to be ready.

And if an interface changes in early stages? No problem. You’re not in production yet.

Not every class needs an interface

Should every class have an interface? Of course not.

If a class is private to a module and never used outside it, you don’t need an interface. Refactoring those is usually contained and straightforward.

For rapid prototypes you plan to throw away, just hack it together. For simple helpers used only inside a module, skip the interface.

But when you’re building features that will survive past the MVP phase, or when you touch external systems:

You absolutely want interfaces.

Interfaces are difficult

Designing good interfaces takes practice. So does performance tuning, clean architecture, and disciplined testing.

But “difficult” doesn’t mean “unnecessary.” It means it’s a skill worth learning.

Closing

Reward seniors who promote loose coupling and domain separation. They’re not over-engineering: they’re building resilience.

Those are the developers who can handle complexity, refactor without fear, and carry your product beyond the MVP phase into long-term success.

What’s the hardest refactoring lesson you’ve learned about interfaces?