Yes, We Built a Real ERP-Like System with AngularJS

And years later, we’re still taking care of it

Every time someone mentions AngularJS these days, the conversation usually goes in one of two directions.

The first group reacts with nostalgia.

“Wow, I haven’t heard that name in years.”

The second group reacts with concern.

“Wait… that’s still running?”

In our case, the answer is yes.

And not only is it still running, it has been running successfully for years.

A long time ago, our team built a fairly large web application using AngularJS.

Not a simple website.

Not a marketing page.

A real business application.

Something closer to a mini ERP system.

Orders.

Inventory.

Master data.

Reports.

Approval workflows.

User permissions.

Various integrations.

Thousands of daily transactions.

The kind of system that quietly becomes part of people’s daily work.

At the time, AngularJS was a perfectly reasonable choice.

In fact, it was one of the most popular frontend frameworks available.

Many enterprise systems were built on it.

Many talented developers used it.

And honestly, it helped us ship a lot of business value.

The funny thing about software is that success creates its own challenges.

If a system fails, it gets replaced quickly.

If a system succeeds, it survives long enough to become legacy.

That’s exactly what happened.

The project worked.

Users adopted it.

Processes depended on it.

Departments built workflows around it.

New features were added.

More users arrived.

More integrations appeared.

Years passed.

And before we knew it, the application had become part of the company’s operational backbone.

Then AngularJS reached end-of-life.

And suddenly everyone started asking the same question.

“So when are you migrating?”

That’s a reasonable question.

But reality is rarely that simple.

One of the biggest misconceptions in software development is that old technology automatically means bad technology.

In reality, there are systems generating millions of dollars in business value every year while running on technology stacks that younger developers have never even seen.

The real question isn’t:

“Is it old?”

The real question is:

“Is it still serving the business effectively?”

That doesn’t mean maintenance is easy.

Far from it.

Once a system enters what I call the “maintenance era,” the nature of the work changes dramatically.

You’re no longer building from a blank canvas.

You’re managing an ecosystem.

The first challenge is knowledge preservation.

This becomes critical surprisingly quickly.

Many systems outlive the people who originally built them.

Developers move on.

Architects change jobs.

Team structures evolve.

Years later, somebody opens a module and discovers code written by someone who left the company five years ago.

Nobody remembers why it was implemented that way.

Nobody remembers the original business discussion.

Yet the code remains.

This is why documentation becomes more valuable with age.

A feature that seemed obvious during development can become a mystery years later.

Good documentation often saves more time than good code.

Another challenge is dependency management.

AngularJS itself may continue running perfectly.

But the ecosystem around it keeps moving.

Browsers evolve.

Operating systems change.

Security standards advance.

Third-party libraries disappear.

API providers introduce new requirements.

Authentication systems get upgraded.

Infrastructure modernizes.

The application may remain stable while everything around it changes.

Maintaining compatibility becomes an ongoing responsibility.

Sometimes the application itself isn’t the problem.

The world around it is.

Security becomes another major concern.

When a framework reaches end-of-life, official security updates stop arriving.

That doesn’t automatically mean disaster.

But it does mean the team must become more proactive.

Dependencies need review.

Access control requires attention.

Infrastructure hardening becomes more important.

Monitoring becomes more important.

Regular audits become more important.

The safety net is smaller than it used to be.

Then there’s the issue every maintenance team eventually encounters.

Feature requests.

They never stop.

Users don’t care whether a system was built last month or ten years ago.

If they need a new report, they need a new report.

If a business process changes, the system must adapt.

If regulations change, the software must change.

Business keeps moving.

Technology age doesn’t pause business requirements.

This creates an interesting balancing act.

You want to avoid major architectural risks.

But you also need to continue delivering value.

Sometimes the smartest decision isn’t rebuilding everything.

Sometimes it’s carefully extending what already works.

One lesson I’ve learned is that maintenance is not passive work.

Many people imagine maintenance as sitting around waiting for bugs.

The reality is completely different.

Good maintenance teams are constantly doing small improvements.

Refactoring risky areas.

Improving monitoring.

Cleaning technical debt.

Updating documentation.

Strengthening security.

Simplifying workflows.

Reducing operational risks.

The best maintenance work often happens before users realize anything was wrong.

Over time, we also learned to separate changes into categories.

Some changes are safe.

Some changes are risky.

And some changes belong in the category I call:

“Let’s schedule a meeting before touching this.”

Every mature system develops modules that nobody wants to accidentally break.

Not because the code is terrible.

Because the business impact is enormous.

The most valuable habit we’ve developed is treating the system like critical infrastructure.

Not like a coding project.

Infrastructure.

Because that’s what it eventually became.

People depend on it.

Departments depend on it.

Daily operations depend on it.

When viewed through that lens, decision-making becomes clearer.

Reliability often matters more than novelty.

Predictability often matters more than elegance.

Stability often matters more than chasing the latest trend.

Would I build a brand-new ERP-style application in AngularJS today?

Of course not.

The industry has moved forward.

There are better choices available now.

But do I regret building that system back then?

Not at all.

It solved real business problems.

Created real value.

Supported real users.

And years later, it continues to do its job.

In many ways, that’s one of the highest compliments software can receive.

Nobody talks about it much anymore.

Nobody celebrates it.

Nobody posts screenshots on social media.

It simply keeps working.

Quietly.

Reliably.

Day after day.

And honestly, that’s what most business software is supposed to do.