Application Managed Service: Why We Stay After Launch

Most software is bought as a project. It has a start date, a launch date, and a budget that closes when the launch does.

The business it was built for has none of those things. It keeps trading, keeps hiring, keeps changing what it sells and how it sells it. The system that was correct on launch day drifts away from the company it belongs to, quietly, a little at a time.

Application Managed Service, usually shortened to AMS, is the work that starts where the project plan ends.

A Launch Is Not a Finish Line

Everything genuinely interesting about a system appears after real people start using it.

• Traffic arrives in shapes nobody modeled.
• A screen that made sense in a specification turns out to be three clicks too long for someone doing it two hundred times a day.
• An integration that was stable for a year changes its API.

None of this is failure. It is the moment you finally hold information you could not have had any earlier.

That is the loop our mission describes. Design the ideal future, serve its realization, and let what you learn in the second half redraw the first. Neither half ever ends.

Whether a system still has that loop is something you can check from the outside.

Three Questions

You may already be living with the opposite of AMS without having a name for it. Ask three questions about any system your business depends on:

Who is looking after it now?

Is the company that built it still around, and still answering?

When did it last change?

If the answers are vague, the system has been orphaned. It still runs. But the developer has moved on, or the agency only takes new projects, or the vendor was two people and one of them left. Nobody currently in the building can say why a screen behaves the way it does, and every change now feels expensive and risky. The system did not break. It was abandoned while working.

For example: most Malaysian businesses above RM5 million in revenue touched their invoicing systems in the past two years, because the LHDN e-Invoice mandate left no choice. The deadline work got done, often quickly. The quieter question is the one that matters now: who is looking after that integration today, and who will absorb the next change when the rules move again?

How a company answers that depends almost entirely on how it is organised.

Design, Engineering and Operation Are One Loop

We do not run design, engineering and operation as three stages in a line, where one team hands to the next and the last keeps the lights on. They sit inside a single loop, and what operation learns is what design uses next.

So the people who run a system for us are not a separate desk that inherited someone else's code. They are the team that built it and kept building it.

A handover is a loss of context, and context is most of what makes a change safe.

Which is also why we do not staff AMS as a support function working through a playbook. The people watching a system need to understand the business logic behind what they are watching.

And it is why we also take in systems we did not build. An orphaned system is a system that has lost its loop. The first months of that work are slower — we read, we document, we make small safe changes before large ones — but at the end of it the system has a team again, and the loop is closed.

What that loop does month to month is unglamorous, and worth spelling out.

What AMS Covers in Practice

• Monitoring and incident response. A problem is noticed by us, not reported to you by your own customers.
• Security and dependency updates. Applied on a schedule, rather than during an emergency.
• Performance work. Tuning as data and traffic grow past what the original design assumed.
• Small feature changes. The steady stream of adjustments a business asks for once it is really using the thing.
• Reporting and documentation. Every month, a report of what we did and how long it took, attached to the invoice. Not a summary of tickets closed, but the actual work, in hours, against the actual system.
• A named team. People who already know why the system is shaped the way it is.

The last one is the least visible and the most valuable. It is the difference between a question answered this afternoon and a question that starts with a week of reading code.

A break-fix contract pays someone to be present when something breaks. AMS pays a team to keep the thing worth having.

Changing the System as the Business Changes

A new sales channel. A tax rule that shifts, a merger, a season that triples the load, a market nobody was planning for last year.

Each of those is a change to the business first and a change to the software second. A team that already knows the system absorbs it in days. A team meeting the codebase for the first time spends those days working out where to start.

We keep what we build running with our clients, and we change it as their business changes.

That promise is only worth something if we are still there years later.

What Staying Actually Looks Like

"Long-term" should mean something specific, so here are our numbers.

Ninety percent of our revenue this year comes from clients who have been with us for more than two years. Each of our four largest clients has been with us for over four, and the longest for more than five. We have looked after a portfolio of public-facility websites in Japan since 2021: more than twenty sites today, under one continuous agreement, going into its sixth year. And across the past ten months, the retainers that anchor our work have not moved by a single yen: the same scope, renewed month after month, because the systems keep earning their keep.

We are deliberately not a company that counts projects. Our capacity is finite and we would rather it belong to the clients we already serve. What we offer instead of volume is accountability: the same named engineers on your system this year and next.

We are a Japanese company, and we run operations the way you would hope that implies. Updates announced before they happen, not after. Records kept as a habit, not as a favor.

Staying also means being reachable in the hours you actually work.

A Global Team, Built Around Your Working Day

Capable people and good ideas are not found in only one place. Alongside our head office in Tokyo we have N.D.S. Venture, our engineering team in Kathmandu, and we are now growing into Southeast Asia.

The Kathmandu team welcoming me during my visit to Nepal.

If you are in Kuala Lumpur, you sit in the middle of how we already work. Kathmandu runs about two hours behind you; Tokyo runs one hour ahead. An ordinary working day gives roughly twelve continuous hours of cover in your own time zone, from the moment Tokyo starts to the moment Kathmandu finishes, staffed by people who know your application, not a rotating on-call desk reading a runbook.

Covering that much of the day without wearing people out takes more than headcount.

AI Native, With Someone Still Accountable

We work AI into the operating loop rather than around it:

• Alert triage, before a person is woken up.
• Log analysis, faster than anyone can read.
• Drafting and reviewing changes.
• Documentation kept in step with the code.

That removes a real amount of the repetitive work which used to make maintenance slow and expensive. What it does not do is take ownership.

Every change still has an engineer whose name is on it, and a review by someone other than its author. Accountability is the part of this work that cannot be automated, and it is the part clients are actually buying.

Why the Long Relationship Wins

Many of the companies we work with have come to us not once but continuously, and several have stayed for years. Most of our work today comes from relationships like these.

We take that seriously, because a continuous relationship matters more than one large one-off project. That relationship is the backbone of realizing the future we set out to design. Explore, practice, harmony. Keep learning, act on what we learn, and look after the people we work with. Those are easiest to see, and hardest to fake, in the years after a launch.

Contact: [email protected]