Nobody at Our Company Owns the .NET Application Anymore

August 19, 2026

The first time I came across an orphaned .Net application, the agency in charge of building the app had blown through the entire project budget without finishing the project. After spending $350k building the app, the agency was not able to deliver a workable product to the company so they were let go putting the IT director in a tough place: the total budget spent, no working product and there wasn't anyone on staff to finish the app development.

This wasn't a .Net development shop, so when nobody at the company owned the application anymore. I came in as a contractor to pick up the parts, put them together and get this app to a live application in 3-4 months. When I met with the client the first time, they told me "the agency we hired spent the entire budget and we need someone to get this project done."

It had been stuck for two months by the time I came onboard, thus pushing the go live date back two months. For two months no work was done and therefore no progress was made. During this time IT director and other people working on the project had to keep the stakeholders informed about what the problem was - which is a terrible look for them.

Why was it not completed and where did the money go? The fact was that they hired a big agency who couldn't get the job done and now they were in a tough spot. They charged a big agency fee. It was a huge project and was now going to cost the company more money to complete.

When an application sits midway through the development phase - there are other downsides other than not making progress. Here are a few things that start to decay:

  • Domain knowledge. Over time the project is not at the front of mind for the people on the team. That's dangerous because requirements or business rules start to be forgotten. Regaining this knowledge costs money and time.
  • Tech debt. The apps, frameworks, APIs and libraries. When there is no active development those codebases become out of date, or worse, breaking changes are introduced.
  • Team turnover. People starting the project could move to other projects or work, or leave the company. When team members leave, so does all their knowledge. It takes time to ramp up new employees on the project.

The company that hired me was led to believe that this was a working MVP. After I assessed the project, I provided a report on the status of the app and it wasn't in any shape to be used as a working app, unfortunately. None of the business requirements were met and it still needed a lot of development to get across the finish line. It would go on to cost an additional $60k for me to complete the build and deliver a working product.

They approved the $60k and pushed to get the product out the door. Most of the remaining development got done for that $60k and the app went live. Set that against the $350k already spent on a product that did not work.

We hit the 3-4 month window with the specific terms that had to be complete. Phase 1, if you will. There were revisions to go after once it was live, and I stayed on for another year to make improvements and handle maintenance.

For the IT director, the change was having someone to trust on the development lifecycle. That let them put their attention back on the parts of their job that demanded it.


Working through a problem like this?

Describe the system and where it's stuck. I'll tell you what the work actually involves.

Get in touch