Project Development Mistakes You MUST Avoid 🚨

Video version of this article 👉 https://youtu.be/PpaAIj0BoyI

I’ve been developing consumer projects (mobile apps and web applications) for the past 10 years, during this time I’ve learned a lot of what is needed to have a successful project release, but, in various painful ways, I’ve also learned what needs to be done to completely nuke projects (no matter how great the idea is or even implementation was!).

More recently, over the past year, I’ve been taking a crack at my project, Studify (out on all app stores btw).

I believed I had all the knowledge needed to make sure I would not commit the same errors I’ve seen a lot of my clients do over these years and it would be smooth sailing to a successful release - Nothing could go wrong, right? - boy… was I completely wrong.

Not only did I fall into the same pitfalls I continuously warn my clients about but I doubled down on a lot of them. History doesn't repeat itself but it sure as hell does rhyme.

This article is more than a way to promote Studify (out on all app stores btw) or to help any of you not fall into these same mistakes, serves as a public reminder for all the screwups I’ve made and a way to try to make it so that I don’t make these mistakes again (I’m sure in my next project I will fall into the same issues, but it’s worth a try).

The rules outlined are more relevant to side projects and that’s my focus here, however, all the rules (to a certain extent) apply to any project you work on, big or small.

The Rules

Let’s go through the development process of Studify and explain everything I’ve done wrong, I’m sure a lot of you have gone through the same in one way or another.

It was the end of the summer of 2023, I had been taking the GCP professional developer certification and was not happy with any of the apps that had a quiz-like approach to learning (personally that’s the way I learn best, by doing something over and over again, in this case answering thousands of exam questions), because of this a thought came into mind - “I’ll just make my version, how hard can it be” - I’m sure most of you reading have had this though in your development career.

That same night I went to a bar next to my house and started coding. This is where the first set of mistakes were made.

“I’ll just design as I code”

This phrase is probably the biggest project killer out there. And it is tempting to fall into this mistake.

It is incredibly fun in the beginning to design as you code since everything feels good when you are going 100 miles an hour at the beginning of the project.

You can iterate so fast and can get so much done so fast that you don’t realize how terrible the UXI is becoming.
It’s so easy to undervalue the work web designers do, it looks easy, but trust me it isn’t and you suck at designing.

A lot of us have a good eye for good vs bad designs when we are looking at another project. Having this quality is not the same as being a good designer.

So there I was in the bar, a beer in one hand and the other hand tirelessly typing code with zero to no thought put behind it - who needs Netflix and chill when you have this right?

If I had just stopped for a second, opened Figma, Excalidraw, or even just a piece of paper and started to lay out the screens I would need to reach my idea of the app I would have saved probably 40+ hours of development time. This is because I ended up redoing the entire UX/UI system 3 times - yeah you heard me, 3 times I redesigned the whole project. The funny thing is the app is not that complex but still It took me 3 tries to get to a point where I was happy with it.

I wouldn’t have done nearly as good of a job as a designer but at least the problems I eventually realized existed in the project could have been caught much sooner on the UX side at least.

As for the UI, I started strongly creating custom components for everything, but as I kept changing the UX of the app and more and more variants of the components kept creeping up it quickly became a mess. There was no design system in place, every component belonged to its system, meaning the app by the end of it was a mess without any cohesion.

If I were starting again I would just use a component library (ShadCDN or Tamagui are my go to, for this project Tamagui was the choice because it integrates well with react native) as plainly as I could without any major changes to the components themselves, odds are the default components from any library out there are better than what I or you can design.

“I know what I want, there’s no need to create user stories”

This one is tough. Over my college years user stories were one of those things that always felt useless - “As a user I want to login”, no shit Sherlock - but they are a necessity when working with clients to make sure everyone on the team has the goals aligned. However, Studify taught me that even when working alone on a side project these are a must!

On that fateful day at the bar, I believed I knew exactly what I wanted out of the app - how naive I was - but as time went on I started to have more ideas of new features I wanted in the app up to a point where the app was anything but what I had initially thought of.

I know this must resonate with a lot of you:

1. You start a project.
2. You work on that project for a while
3. You have an idea for some niche feature.
4. You start implementing it right away, dropping everything else without even thinking if this will help you reach product market fit. In your mind, it just sounds so appetizing to work on this asap.
5. You code on that for a while
6. Go back to point 3

This flow has a name that gives even the most senior of developers chills: Feature Creep

It is fun to code this way (on side projects, with client projects the story is completely different) but more than suboptimal it is a quick and sure way of never releasing your baby into the world.

That’s where user stories should come in. They should act as a way to constantly remind yourself of the goals you had set for your project and, anytime you think of something else, look into that list of boring old user stories and deeply think if this new feature will help you reach product market fit. Take a week or more on this. Only if you cannot see the app without that feature should you squeeze it into the MVP, otherwise throw it in the column of nice to haves, after releasing your project you will have a bunch of time to work on those.

“Analytics? Who needs those”
It is quite easy to overlook this part on side projects, however, it will be the primary way you will have to figure out what your users are doing post-release, don’t overlook it!

By the time I was about ready to release Studify, I figured this out since it was one thing that customers always complain about after releasing a project - “How do I know users like the app?”.

With tools like Mixpanel, Firebase Analytics, segment,... It is so easy to gather basic data on how users are using your product that it is a no-brainer, in around 2 hours I can guarantee you can have something up on running that will make it easier to make decisions later on. This is especially true for side projects, you don’t have an unlimited budget to run full end-user tests before releasing to validate your idea, so you will have to rely on this data post-release and quickly make educated decisions on what you should improve on next.

“Let me just try 10 new tools on this project”

On Studify I decided I wanted to try some new tools, packages,... that I had been reading a lot about for a while and that my main job didn’t require, side projects are great for learning new things while not being afraid of failing.

For me, it was 3 main tools: expo router, supabase, and Tamagui, but there were others.

This sounds good at first but using a completely different stack on a project will increase the risk that you never release it. I stand by every decision made when it comes to this however there’s no denying that it delayed the release of the project.

Let me just say that it is really important to try new things, and devs should always strive to try different things, but if your goal is to release a project and not just learn new things try not to jump into a bunch of new tools at once, pick one or two that you want to try and leave the rest with what you feel comfortable with. Again this is true while making the assumption you want to release a product as fast as possible.

“The app is just not good enough”

When I started Studify I honestly thought it would take me at most a month to get it out - Devs are so prone to be over-optimistic about timelines, I’m no different - but life gets in the way, my main job takes 70 hours of my week at a minimum, you have to socialize, you have to take courses, take care of your house and the list goes on…

However 2 months out and I had the first version of the app ready to use, did it look good? No. Did it have bugs? It was crawling with them. Was I confident it would succeed in its current state? Hell no. Should I have released it? Absolutely.

Fail fast, Learn faster. This is the quote you should live by when working on these types of project (and to some extent, every project should do this).

If I had released it back then I would have learned what users needed much faster and maybe that feature I spent 1 month working on 6 months into the project that eventually was scrapped wouldn’t even have been started. That time could have been put into something users want.

This depends on the app, Studify is pretty low risk, if something broke for the users because I released it prematurely nothing terrible would happen, so look at this rule as something that heavily depends on the project.
That same night I went to a bar next to my house and started coding. This is where the first set of mistakes were made.

Final Remarks

Building a project, especially one like Studify, is a journey full of excitement, learning, and inevitable missteps. Studify taught me that no matter how much experience you have, it’s easy to fall into the same traps that you’ve seen time and time again. But that’s part of the process.

The key takeaway from my experience is simple: humility and planning are your best friends in development. No project is immune to pitfalls, but recognizing these common mistakes can help you navigate around them. Whether it’s failing to plan your design, overlooking the importance of analytics, or getting lost in feature creep, every mistake is a learning opportunity. And while it's easy to chase perfection, sometimes it's better to launch, learn, and iterate than to never release at all.

In the end, the most important lesson is to embrace the messiness of development. Accept that you will make mistakes and learn to adapt quickly. Keep your eyes on the goal, don’t be afraid to make changes, and above all, enjoy the process. The success of a project doesn’t just come from the end result but from the lessons learned along the way.

If you’re working on something, don’t get discouraged by setbacks—lean into them, learn from them, and keep pushing forward. After all, every great project is built on the back of countless mistakes that were ultimately transformed into stepping stones. Keep building, keep learning, and maybe—just maybe—you’ll avoid some of the pitfalls I fell right into.

Happy coding!

Studify is out now on all app stores, check it out on www.studi-fy.co

iOS version 👉 https://apps.apple.com/pt/app/studify-ai/id6670405467?l=en-GB

Android version 👉 coming soon!