One of my client wasted nearly $80,000 trying to build an internal tool.

Their product team started working on it, got version 1 out quickly, and thought they were doing well. But then progress stopped. When people started using it, they had lots of feedback, and fixing things slowed everything down.

You see, the developers that they have are building things on mobile apps, and APIs to support the apps. They’re amazing at that.

But the internal tool was built for the web. With all the complexity of the modern web dev, it’s a whole new beast.

They thought their backend developers could handle it. So, the devs started in the way they knew best: they made scalable APIs and wrote everything in Go. They built a front-end with React, struggling through TypeScript. Somehow, they got version 1 done.

But after that, no one on the team wanted to work on it. Management found a couple of their developers to keep it going, but they left the company, unhappy with the work.

This went on for 8 more months.

All in all, they ended up with lower product shipping velocity, 3 people left the company, and they still did not have a functioning tool to make teams productive.

They chose the wrong tool for the job.

Either they should have taken the MVC style approach here, with Rails/Django doing all the CRUD heavy lifting, and providing all the required tools to make these internal tools a breeze.

Or they could have used something like Appsmith, that is built for making internal tools.

A lot of projects look simple at first, but it’s the updates and fixes that make them hard, turning a small project into a big mess.

It’s like thinking your cat can fetch a ball, just like your dog does.