From a Developer’s Side Project to a Client-Ready Tool: The Story of Our .NET Application Runner

Every successful engineering team has moments where a small spark becomes something much bigger, a quiet idea that grows into a tool powerful enough to change the way people work. This is one of those moments.

What began as a single developer’s side project, a simple way to wrangle the growing number of .NET micro-services needed to run our application locally, has now evolved into a polished internal tool that our client is adopting into their own development workflow.

Here’s how it happened.

It Started with a Simple Pain Point

Local development had slowly become a juggling act. Our project includes numerous .NET APIs, workers, and background services that all need to run together.

The original problem was clear:

“I just need an easier way to run everything locally… without 15 terminal windows and a memory test against my brain.”

Batch scripts worked, but just barely. So our lead developer, Mike, took the initiative and built a basic tool to start and stop all required services with a single click.

No ceremony. No grand plan. Just a small convenience app to make life easier.

A Side Project Turns into a Team Collaboration

Once the first version was shared internally, the team saw the potential immediately.

Together, we began to expand it:

🔧 A Manage Screen

So new services could be added through a UI instead of editing JSON by hand.

🏷️ Branch Awareness

Showing which GitHub branch each service was running, preventing confusion and misaligned debugging.

📜 Integrated Log Output

Each service's logs captured cleanly inside the tool, replacing a desk full of terminal windows.

📊 Automatic Sequence Diagrams

Using those logs, the runner could generate visual diagrams of how services interact, making debugging faster, clearer, and far less painful.

The more we added, the more valuable the tool became.What started as a personal utility was now a team-developed asset.

Demo Day: Showing It to the Client

As the tool matured, we realised it solved not just our problems, but the same problems our client’s developers face every day.

So we demoed it.

The reaction was immediate and enthusiastic.The client saw the reduction in friction, the reliability, the visibility, and most importantly, how it could:

• speed up onboarding

• standardise local development

• reduce misconfigurations

• improve debugging and service understanding

Within a week, they began integrating it into their own workflow.

Now It’s Being Implemented Client-Side

Today, the tool is moving beyond our team and becoming part of the client’s development ecosystem.

We’re supporting them in:

• onboarding their devs

• adapting it to their environment

• integrating with their repositories

• extending features based on their needs

What began as a personal time-saver is now a cross-team productivity multiplier.

Why This Matters

This isn’t just a story about building a tool. It’s about culture.

• A developer spots a problem.

• Builds something small to improve their day.

• The team recognises the value.

• Everyone contributes.

• And the end result is good enough that the client adopts it, too.

These are the moments that quietly transform how we work, and strengthen the relationship with our clients in ways that matter.

The Application Runner didn’t start as a “project”, it started as a need, and now it’s become a shared solution that everyone benefits from.

If you would like to contribute then please see our github repository here