Okay, so today I wanted to share my experience with making a “technical decision.” It’s not about choosing the fanciest new tool, but more about picking the right tool for the job, and that can be surprisingly tricky.

It all started with a problem. We were building this internal tool, basically a dashboard to track some key metrics for our team. Initially, I jumped straight to what I knew best – React and a * backend. I mean, it’s my go-to stack, right? I started whipping up the basic structure, setting up the project, getting the build process going. Everything was familiar and comfortable.
But then, a teammate, bless their soul, asked a simple question: “Is this overkill?”
And that stopped me in my tracks. Was it? We were tracking, like, five metrics. We didn’t need real-time updates, fancy animations, or complex data manipulation. A simple, static page that updated once a day would probably do the trick.
So, I took a step back. I started by listing out the actual requirements. Not what I thought we might need someday, but what we needed right now.
- Display five key metrics.
- Update the data once a day.
- Accessible to everyone on the internal network.
That’s it. Three bullet points.

Then, I considered alternative. It sounds a little bit silly, I even considered just using plain HTML and a simple Python script to fetch the data and generate the page. I looked into some static site generators, too, like Jekyll or Hugo. These seemed like a much better fit for the actual needs of the project.
After some quick research and prototyping (literally just a couple of hours), I decided to go with a static site generated by a simple Python script. I created a basic HTML template, wrote a script to pull the data from our existing database, and used that data to populate the template. I set up a cron job to run the script once a day.
The result? A super lightweight, super fast, and incredibly easy-to-maintain dashboard. It took a fraction of the time to build compared to my initial React/* approach, and it did exactly what we needed. No more, no less.
The big takeaway for me? Don’t get blinded by your favorite tools. Always start with the requirements, consider all the options (even the “boring” ones), and choose the simplest solution that gets the job done. It’s not always about the coolest tech; it’s about the right tech.