The hard learned lessons of trying to build my first web app

Having an idea for the next great thing before having any of the technical knowledge required for it is great. The imagination runs wild, and the sky is the limit. On top of that, arrogance is one hell of a fuel. “I can easily create something better than this in a few weeks!”.

It’s not like I had zero knowledge in coding before I set out to make my creative writing app. I have done quite a bit of JavaScript coding for forms, a good number of data processing python scripts, and a few unfinished Unity games.

Though, things quickly collapsed and took a more realistic shape once I got into coding the app. These are pieces of advice I would have loved to know early on before starting developing my app.

Your scope is not narrow enough

I thought the scope I had set out was narrow enough. But, it became more apparent to me how huge the scope is the more I worked on each feature. Things took a worse turn when I realized that a certain feature doesn’t integrate well with another, and I had to do quite a bit of code re-writes to get things working correctly again. all of these things should be considered when setting a scope.

This back and forth of code rewrites can drain a person out. A good approach to stop this overwhelming storm is to narrow the scope down further. A few features for the first version, then add more for the second version, and so on. Keep iterating and adding functionality as you go.

I was hard on myself when I was trying to narrow down the scope each time, thinking that I am not good enough, that I won’t be able to realize my dream, and I don’t have what it takes to make the app. Cause “I can easily create something better than this in a few weeks!”, remember? In reality, it’s just me realizing what it takes into building an app, and I have to accept that and keep going. Compromises will be made, but those compromises will help realize our goals “sooner”.

Make a clone of the app you are trying to compete with first

Really. Do that first. I do understand that you are building a competing product because you don’t like how they are handling certain things. Re-building that annoying functionality would be agonizing for your soul. But, the idea behind creating a clone is you will be laser-focused on just coding. You don’t need to think about the design, you don’t need to think about how things will integrate because you already know that.

The advantage of this is that you will be fully focused on learning the coding part, and you won’t have hiccups during development where you are trying to figure out how to design a certain feature.

It will surely be a bumpy road still, as you are just starting to code. You will do a lot of googling and digging around. Lots of trial and error, but by the end of developing the clone, you will know what kind of knowledge, framework, and libraries you will need to build what you want to build. On top of that, you will know how much effort it’s going to take to develop an app of that category.

Eventually, this is going to help you with:

• Setting a more achievable scope for your app
• Building the base knowledge required to build your own app
• You have code that you can re-use for your own app

Learn how to read other people’s code

Most developers hate creating documentation. It’s not very common to find well-documented libraries. Sometimes you will find an awesome library, and just does what you want. but you can’t seem to figure out how to work that teeny tiny bit of functionality to your favor.

You can, of course, ask the developer of the library how to do said thing, but sometimes the developer won’t have the time to respond to your inquiry, leaving you waiting for possibly days where you are stuck with developing your app.

A more drastic situation is that a library does the functionality that you want, but doesn’t do it the way that it works for your app. Being able to read other people’s code will help you write your own customized mini-library quickly that will fit your needs and gets you back into the flow.

What’s really awesome about this is that once you understand other people’s code, you will be able to learn how to do things as well. In my app, I wanted to build something like VS code’s file browser, and reading Material UI’s “Table View” component code helped me figure out how I could make my custom version of it.

Do not start from scratch

You do not need to build every component from scratch. use something like Material UI to get you up and going quickly. I didn’t need to build a text editor from scratch, as a wonderful framework like SlateJS already exists. Your backend doesn’t need to start with an express/mongoose/prisma/etc combination. You can use things like Supabase, Hasura, and Strapi.

As you are just starting out, you probably don’t know much about APIs. Maybe some basic knowledge, but not all the things you can do with them. What’s great about using something like a headless CMS is that you will have a visual representation of how your data looks like, wonderful documentation that shows you the ins and outs of your API. how to search, filter, paginate, and so on. It will be much better for you to learn what these concepts are and how to work with them before developing them.

Let it be hacky, let it be wonky. Your goal here is to do rapid prototyping to get your functionalities working and finalize your app quicker. After that things have stabilized, you can worry about building your backend with a more elaborate express + prisma + graphql combination for example.

Stick with the technologies you started with

I changed between 4 state management libraries, 2 databases, 3 ORMs, and 2 ways of building APIs (REST and GraphQL) throughout the development cycle of the app.

That’s A LOT. a lot of time and energy were spent learning a new thing, trying to adopt the new methodology, a lot of code rewrites to accommodate for the newest hottest way to use state management or ORM. All of this is progress, but it’s vertical progress, not a diagonal one.

A vertical progress is when you apply a new technology, but you are not really adding new features in the app.
A horizontal progress is when you aren’t adding new technologies, and purely adding new features.
A diagonal one, as you might have guessed, is when you apply new technologies and add new features into your app.

Stick with what you end up choosing in the beginning, and try to finish the first version of your app with that thing. There will always be progress in technology. Libraries will probably develop quicker than your app because they are built by multiple people in the open-source community.

Yes, switching to that other library might probably help you out with building your features quicker, but you have to also think about how much time it’s going to take for you to re-write all of your code to replace the old library with the new one.

Of course, there can be exceptions to this. Your app for example might have better use for a SQL database like PostgreSQL rather than MongoDB, with relational data being a big factor in your app. At the end of the day, this comes with experience to see if changing a technology mid-way through development is worth it or not.

Conclusion

Of course, not all of these lessons may apply to you as well. Certain things may work better for you if you do the opposite of what I just said. For example, sometimes changing a library can be more beneficial for you, since it can help you develop faster. but still, if that happens too often then it’s an addiction more than anything at this point.

My Journey with developing an app has been a wonderful one, with the good and the bad of it. Coding is a really entertaining thing for me, and seeing how it can help shape up my vision is a surreal experience. Am looking forward to sharing more of the lessons I will be learning in the future.