Of course you should write your new side project with the newest fad in trend.

Of course it must be server-side rendered with the smallest JS bundle and the most optimised user interactions.

Of course it has to be served from the Edge in under 120ms.

Of course it's fine if it takes 6 more months to build.

Of course it's fine if the competition takes the lead.

Your site is the best because you are using the best new framework recommended by everyone on YouTube.

No! you don't need to do the above because no one is going to use your shitty product anyway.

To nobody's surprise - 10xer discovers that side projects move slowly when you rewrite them in a new JavaScript framework every 3 months

You might think I'm being mean and I might be. However, this is something that every engineer needs to hear from time to time. You are spending too much time thinking of optimisation when you don't even have a product-market fit.

Does it really matter if your habit tracker runs at 120 FPS if nobody uses it?

In the early days of your product, performance shouldn't be the top of your priorities. Finding a market fit and a user base should be. That will only happen if you build rapidly and are agile enough to move according to customer demands. Products that fail to understand this, just fail at everything.

Recently a friend asked me if they should use a combination of React and React Native for their new business idea. I asked them if they had a team of 3 developers working for them. On being told "no", I advised them to just use Capacitor to bundle their web app into an Android and iOS app.

I expected to hear "Isn't that bad for user experience?" (which I did). Can most users tell the difference between native and non-native apps? No, not really. Before you tell me that hybrid apps are UX nightmares - There is no bad framework, only badly written code.

When building a business, start with something you already know. For tools of convenience, you don't need the best framework in the world. JUST START

You must prioritise your business requirements over fun-to-do things in the initial phases of your product for the following reasons:

• If you are going to fail, you'd rather fail fast. Waste less time learning things while building your product. For learning, build smaller side projects with no intention of monetising them
• If you work with what you are already comfortable with, you will build much faster than someone who is still learning

Last weekend, I met a friend who is working on a proximity-based chat application as a side project. They told me they were using MongoDB as the database with Firebase Cloud Functions (FCF). I asked them the reasoning for not using Firestore (Firebase's NoSQL datastore) since it's much easier to configure and use. They told me it was because MongoDB is more performant than Firestore at geolocation queries. A week later, they came back to me and said they were moving to Firestore because it was easier to use.

Again, emphasises the point that you should start with whatever you know. When the demand comes, move quickly

How many of your side projects did you start with a new framework but never finished building. Was it because you were too busy learning that new framework when you should have been actually been focused on building your project.

---

I am working on a small utility for readers. If you are someone who reads a lot of blog articles or newsletters, hit me up at @burhanuday or email me at udaipurwalaburhanuddin@gmail.com. I'd love to have a chat!

---

To get updated when I write my next article, subscribe to my newsletter at burhanuday.com