Learning from my my side project failures

Hello everyone. So this was originally a talk given at London Web Standards in January.

However, due to recording problems, we weren't able to upload the video back then.

So I thought I'd take the time today to record the video so that it can be kept for prosperity.

So this isn't my first time talking at London Web Standards, having spoken many years ago.

Previously, my talks were pretty technical based on whatever I've been working on at the time.

So usually they're on topics like responsive design and web performance.

Today, I thought I would follow a similar trend. However, this time focusing on the pitfall and mistakes I've made on my side projects.

So hopefully you don't make the same mistake yourself. So without further ado, let's get started.

So most people, at some time or other, have come up with an idea for something they wish existed.

That could be in the physical world, like when Edison imagined a world where we could light our rooms with electricity.

Or it could be a digital space where Tim Benners-Lee imagines a world where people could share information freely between one another.

And he subsequently created the first web browser. And while our ideas might not be world changing, as either Edison's or Tim's creations,

we all hope that our ideas will have some kind of positive impact. When I think about my own ideas,

I'm often thinking about things I can create that I personally would find helpful.

And hopefully others will as well. Sometimes these ideas are small as a calculator for how long you spend with your partner.

And sometimes these ideas are grander, like an engineering metrics platform.

And as an engineer, I'm fortunate enough skills to create many of my ideas. However, this hasn't always led me down to a road of success.

So today, I thought I would share some of these mistakes I've had, have a little fun doing it and share what I've learnt.

So the first thing I've learned about my side projects is that they can fail from not having a clear goal from the start.

I end up with a feeling of "why am I building this again?" whereas my more successful projects are those that are more clearly defined.

A really good example of this is a project I've called "Shopping Mindful".

I had this idea of a site where users could find environmentally conscious products and could then click out to buy them.

The problem was I didn't really understand this market very well and how it would attract users,

which made it difficult to have a clear goal of what should be part of the first version.

This meant while I bought the Shopping Mindful domain, the project didn't get much further.

So the first thing I learned with this is establish a clear purpose for a project from the start.

A strong "why" keeps you motivated at when the initial excitement fades.

I also learned that it's important to set concrete measurable goals to keep myself on track and ensure the project has a sense of direction.

One way you can define a clear goal is to write an elevator pitch type note about the idea.

This helps you really define what the end goal is for building your building.

Given that Shopping Mindful is likely to never be built, I thought it would be fun to do this posthumously for this project.

As you can see, I kept it short to the point, focusing on what the idea was and what options would be included in that product.

I also find that along with goals, it's important to set deadlines for yourself to give yourself a sense of urgency to deliver something.

The second mistake that I have made is striving for perfectionism, where in reality, perfectionism is actually the enemy of most of my projects.

Perfectionism is what leads you to spending hours on a login page for a project that does nothing else.

An example of this was a project I started called Action Metrics.

It's a tool that's supposed to be allowing me to capture GitHub action metrics for data that wasn't available from GitHub itself.

This idea came to me before I'd heard of tools like Sleuth.

In theory, it would have been something I not only use for my day-to-day work, but could also potentially monetize.

The problem was, while I had a bold ambition of what it could be, I got bogged down in the details.

For example, I spent days implementing a login system to find, oh, I should try this other one instead.

I was never quite happy with how it worked.

I was aiming for that perfect experience for my users from the start, but this meant that other areas of the project were ignored.

Looking back, Action Metrics should be called No Action Metrics.

I've learned that it's important to not get lost in the details.

It's better to ship something that's good enough than to spend endless hours perfecting details no one notices.

Your users won't care if the login button is blue or green.

They'll want to use the product.

I also learned that Side Projects is more about having that MVP mentality from the start.

I know we're encouraged to do that in our work, but we should also apply that to our side projects.

It is therefore makes sense to prioritize functionality over flawless aesthetics in early stages,

figuring out what the minimum viable product can be, and then launching that to enable you to test the core idea.

To help with defining the MVP, it can be good to create a set of features and categorize them into muscle features and features for after release.

I've done that here again in Notion.

Then once you have your MVP, you can then have something around the world and start to improve your project.

Remember that perfection is a journey, not a starting point, and the updates and refinements can come after the initial release.

Just keep reminding yourself that real user feedback is far more valuable than endless tweaks.

While perfectionism slowed me down, sometimes I found it wasn't even perfectionism that was causing me problems.

It was something far more sneaky. Scope creep.

And this is where a calculator might become a full loan spreadsheet.

So the project I had that was most impacted by scope creep was Event Focus.

Event Focus was supposed to be an alternative to Meetup.com.

The idea was to build something that was free to use by people in the tech community to organize meetups.

The problem was, as someone who hadn't run events at the time, I didn't have the understanding of what was absolutely necessary.

This meant I would often find myself thinking about features that might not have been necessary, which kept my backlog of features growing forever.

This ultimately led me to abandon the project, and I lost interest as it dragged on.

The key learning areas really start with the MVP.

That focuses on the core functionality. A smaller scope helps the project become more manageable and increases the chance of completion.

To manage your scope, it can be reusable to set up a basic task board.

I often use to-do lists for this or even Trello for this.

You can then sit down and define your initial scope clearly.

Once the core idea proves valuable, you can then start to consider adding more features.

User feedback can guide you what enhancements are truly needed.

You can even add an additional column to the Trello board if you want to keep track of future ideas so you don't forget.

Mistake number four was actually related to feedback.

This is letting yourself drown in feedback you're given, which makes you have a feeling that you're sinking under a tidal wave of other's ideas.

And the project that comes to mind where this was most impacted is actually one of my most successful projects, which is Performance Budget I/O.

This is a website that allows you to create performance budgets.

While overall this project has been a success, it did at one point become bloated with features.

This is because I received feedback that it would be nice if you could run the performance tests.

It would be nice to incorporate different kinds of budgets, etc.

I took all the feedback on board, however this result in the website becoming significantly more complex, which is not what I wanted when I set out to build it.

What I've learned from this can be split into two parts.

Firstly, it's important to show your prototypes early on to get feedback on whether you're on the right track.

This can be from friends, family or potential users to catch things that you didn't consider.

These early reactions can help you refine your idea before you get too deep in code.

Once you've released your first version, you can then seek feedback from early adopters.

This will help you know what you can do to improve your product.

And having released your project, you can then use a free tier of things like Full Story that give you session replays of users who've used your site.

However, there is something to be aware of.

You need to be aware of feedback overload.

Too many opinions can lead to confusion and derail your original vision.

Remember, you can't please everyone, nor should you try.

This is exactly where I went wrong before.

I try to please everyone and I please no one due to an overcomplicated UI with less clarity of what the tool is for.

Ultimately, you want to be listening, but you don't have to take all that feedback and pod.

That leads me to mistake number five, allowing myself to be paralyzed trying to pick a tag stack,

even depending on spending an embarrassing amount of time trying to decide whether I should use React or Vue.

PerfBadger was supposed to be my own take on web performance metrics capture, so run metrics analysis.

Given performance budget IO was pretty successful at the time, I thought it'd be great to create a complementary product that allowed you to capture real user metrics.

Unfortunately, the project got stuck in tech choice paralysis.

The problem was I wanted something that would be super easy to run the infrastructure of while being scalable enough to handle large amounts of user capture.

This led me to be doing test implementations with Vercel, Netlify, Firebase, and even a Node app deployed to Kubernetes.

I wasted a lot of time on this, resulting in the actual ad product not being ready yet.

And ultimately, dare I say, I probably could have shipped something quicker if I built a monolith and deployed it also easy too.

The challenge is there is so much choice.

Even in our own server-side runtime, we have things like Node, Deno, and BUN.

The lesson here is to avoid spending too long on choosing your tech stack, as it can have a detrimental cost to the success of your project.

It can be better to use technologies you are comfortable with to accelerate development.

Familiar tools reduce the learning curve, letting you focus on building, not learning.

Trending technologies are tempting, but can add unnecessary complexity.

The goal is to deliver a working project, not to test every new framework.

Ultimately, any choice is better than no choice, so it's important to make a decision and move forward.

You can always refactor later and optimize later if needed.

My sixth mistake was getting lost in proprietary tech.

It was me realizing that while Firebase seemed like a great idea, it really wasn't.

So the project that I tried to use proprietary technology was CareerLadder.io,

which was a tool I was building to enable companies to create career ladders for their engineers.

For this, I chose to use Firebase as I initially thought it would accelerate my ability to build the tool.

Unfortunately, this didn't turn out to be the case.

I found I had to first learn how to use Firebase, including any complex permission models to ensure data was secure.

And then I had to adapt how I planned to structure the data to be more Firebase-like.

In the end, I spent more time learning Firebase than I did to building the project.

The first takeaway here is that learning proprietary technology will take away time.

So unless you're certain it will save you time in the long run, stay clear.

And if you do decide to choose something off the shelf, make sure you're not choosing something that will lock you in for the future,

as you might want to scale more in the future.

A good example of this is Versal, which has lots of interesting technologies,

how if we look at the pricing page, once you have locked in, it gets quite expensive.

The first terabyte of data transport is only $20, however, the next terabyte is $150.

And talking of wasting money, this leads up to my seventh and final mistake.

This was wasting money and failing to keep my spending under control.

For this final lesson, it's hard to have a clear case study because it applies to so many of my projects.

However, in the past year, I've been spending a lot of time on clearing up and canceling all domain names and infrastructure that I set up for failed projects.

Often I apply the rules I have at work, which is to deploy quickly,

and often this results in me having infrastructure costs before I've barely written any code.

Sometimes I've even forgotten to turn this off.

I recently found I was wasting $30 a month on digital ocean droplets, which were completely unused.

In addition, because I once had a domain name I wanted to go before I purchased it,

I got into the habit of buying the domain names for every idea I had, resulting in me having far more domains that I'd ever need.

So avoid any necessary upfront costs, holding off on those portions of the domains, proving tools or services until necessary.

The next part of this lesson is don't use tools just because you use them at work.

Kubernetes is great for building scalable systems, however, on your side projects,

you don't have to have an entire infrastructure team available to you to run your cluster, so it's not likely to be a good tool to use.

Where possible, you can utilise free resources and trials during the initial development phase.

Vercel, for example, offer a great free TA for experimentation.

And finally, avoid pouring more money and time into a failing project just because you've already invested in the domains or other parts of the infrastructure.

So, having shared some of my side project failures, hopefully you now feel a bit better about your own abandoned side projects.

So the first thing you've learnt is probably that I probably start too many side projects.

And as we wrap up, I want to reiterate, making progress on your side projects is far more important than getting them perfect from the start.

Use feedback to improve, not to completely redefine your project, and balance external input with your own goals and instincts.

And in the end, if I hadn't made all these mistakes, I wouldn't have been able to put together this talk.

So thank you for taking time to listen to this talk.

All my links, including my blog, are available on this URL.

And I hope to see you again soon.