For seven years, I worked on a project in my spare time. Don’t misunderstand; sometimes I took long breaks and sometimes I even quit but for seven years, I kept coming back.
In this article, I will share the biggest mistake from this time.
Origin story
It was my last year of high school; I was trying to get a job to save money for university because education was expensive in the United States.
Companies forced me to apply using online applications. They asked many boring questions. Each took a lot of time, and they all asked similar questions — it was frustrating.
I was new to coding at the time, but the rage motivated me to find a solution.
Specification
The idea was a browser extension that would automatically type text, click buttons, upload files, and select dropdown items. The user would enter their information once into the program; then while viewing an application, with the click of a button, the extension would automatically answer the questions.
It consisted of two parts:
- Analysis – the program understands which information is being requested and where.
- Interaction – the program manipulates the webpage to correctly enter the data.
Execution
Initially, it was going to work with any job application. But with so much variation in the format it was hard to build an algorithm that worked everywhere.
So I decided to simplify the problem by creating a system with handmade instructions for specific websites. This way, the program’s only responsibility was executing them. It allowed me to continue making progress. And because a clear boundary was defined, later, I would be able to easily replace it with something better.
But then there was another consideration: where should this system be located, on the client or on a server?
Here was my thought process:
Well, strictly speaking, there’s no need for a server because the client only needs to read data, not modify it.
But that seems like a bad design because, um … Oh! And there could be delays in publishing changes because each new version must go through the approval process, which can take days.
And I’m going to need a server eventually anyway, so it would be a good use of time.
The mistake
In case it wasn’t clear, I decided to build a server. Pretty quickly I had something basic going. But after that, I would add another feature, and then another, and then another.
It felt like progress – Sure, I had no users, but after a couple of years, I had a system that was automatically deployed, with restful API design, shared types, monitoring and much-much more.
But these things weren’t needed for launching. In all honesty, they were a stalling tactic to avoid failure. It was more comfortable to keep building than go out there and face rejection from potential users.
Building the server wasn’t the fatal move, it was getting lost forever on things that didn’t matter.
After a while, I came to realize this, and instead of changing my behavior, I changed my mindset, so instead of building an MVP, I was building a passion project: something that doesn’t try to be commercially viable , but rather something that is fun to build.
Which is fine, if that’s what you want to do, but then it is important to be honest with yourself.
So, how am I going avoid this in the future?
Here are some things I am going to do to avoid getting lost.
Focus on the user
At least for MVPs, effort should be allocated almost exclusively to relieve pain, specifically, user pain. Not anticipated pain, and especially not anticipated developer pain.
Let me use a metaphor. Here is some common advice for young adults, “After moving out of your parents house, you should buy a big but cheap toolset; it should include basically everything you could ever need for home or vehicle maintenance. Including drill, saw, lots of screw drivers, etc. And when a tool breaks, you should buy a higher quality version of that tool.”
The idea being: don’t waste your money on something you use only once a year. Well, I was doing the opposite, I was spending a lot of time building something that was not being used at all.
If I were to do it again, my MVP would be a “quick and dirty version” and then only adding more complex things once there was actual user interest.
Regularly checking the path
I could have asked myself if it was really a wise decision to spend so much time developing a server, but I chose not to.
I had a destination in mind and I kept driving towards it without asking myself if I really should.
To avoid failure like this, it seems that it is good practice for big tasks, to have a designated intervals asking yourself, “is this really the right path?”
Thanks for reading
I hope you enjoyed the article, I know it ends a little abruptly, but I was getting tired of reflecting on this topic.