If you want to ship a side project, start with unlearning the best practices

Two years ago was my last week as a software engineer at Toptal where I was leading team of 12 people. Since then I work on my projects full-time. That was my the most productive and satisfying years for the whole decade-long+ career. While I still far from achieving my goal of building a sustainable business I learned a lot about product development, copy, marketing, and sales. In this article, I share lessons I learned as a developer while I was working on a dozen projects. If you like me, have an itch for making stuff and seeking for independence, this piece is for you.

Learning the best practices

My first years as a professional developer was rough. After I failed as an indie game developer for a few years I was working as a freelancer making various web projects. I was a developer you wouldn't want to see in your team. I worked long hours on low-budget projects with unrealistic estimations that were making both my clients and me disappointed in the outcome if there was one at all. Bugs, missed deadlines, features that didn't meet the expectations, I saw it all. I didn't know positive examples I but was sure that there's a better way to develop projects.

After yet another flopped project I opened for myself Ruby world that felt like a different realm. The community greatly influenced my views on development, project management, and business. I read Getting Real and all books I could find on business and project management. I religiously studied and tried all known methodologies that suppose to improve the code quality and productivity. SOLID, TDD, BDD, GTD, SCRUM, you name it. It took another few years before I became a developer that you would want to see on your team.

During all that time I was always working on side projects. I started dozens of them of all kinds, from todo lists, ticket trackers to social networks. They were taking all my free time, but I never managed to finish any of them. At first, I got excited about the idea, came up with a new shiny stack of technologies, and then developed it applying the best methodologies I learned the hard way. Then I would be stuck, lost interest or came up with a new, better idea. When I quit my job and started investing my own money into projects, I quickly realized what I was doing wrong.

Do your worst

The practices that are vital in teams might be poisonous when you work alone. Paradoxically, to do your best you must do your worst!

When there's dozen of people working on a single code base, it's necessary to ensure that the systems are designed well, the code is easy to read and have decent test coverage. Pull requests should be reviewed and merged only when they satisfy the team standards. "I'll refactor it later" never works in the teams because there's too much going on and more likely the next person that touches your code won't be you.

When you work alone, following the best practices slow you down. When you're the single code owner, you can defer writing tests until you met a critical part that can't break at any cost. Even then just couple end-to-end test could be enough. It doesn't mean that I avoid tests altogether. If the code is easy to write thought unit tests or too hard to test manually, I do it.

There's nothing worse in code design than a poorly chosen abstraction. When I develop my products, I prefer to copy-paste code two, three and even more times until I see a common pattern and if and only if I change it frequently. It doesn't matter if you have 3 repeating pieces in the code if you are never going to change it. After all, the whole point of refactoring is to make it easy to modify. I think this realization still applies to teams, but you must be systematical about it and keep a ticket in your backlog or notes in the comments.

Focusing on performance is another mistake I was repeatable making. We all the time see tweets and articles about the importance of small code bundle, fast response time or small memory print. Developers often shame companies for their sloppy work, and you might think that your small business won't survive without providing the top-notch experience. The truth is not that important if you never ship your project. People won't buy your product only because it loads in less than a second, but if it solves their problem, they will wait 5 seconds and even more. If your page has poor performance if the user created a lot of content that is a great problem to have because that means somebody actually uses it.

It doesn't matter how well your code is written, what is test coverage or how fast is it if it never shipped or has no users. Also, your first customers will be early adopters that want to have an advantage of being the first using it, and too polished product might signal them that it's too late.

Stick to the tech you already know

The whole career I was chasing the better programming languages, newest frameworks and most efficient ways to manage infrastructure. I tried at least one new tech in every side project I started, and because most of the time I was wrapping my head around and learning new concepts I never managed to get to shipping. No doubts it was beneficial for my career as I learned much more than the average engineer. It made my truly full-stack developer that can do everything from infrastructure to front-end. It also helped me to satisfy my passion for new tech without hurting my employer by experimenting in the production code.

When I started my indie maker adventure I wanted to ship instead of learning so I decided to stick to the stack, I know the best — JavaScript both on back-end and front-end. Even though I was capable of managing infrastructure myself, I choose the Firebase platform that provided everything from static website hosting, servers to a managed database. It wasn't optimal, most efficient and elegant, but because of my prior experience, it all helped me to start and focus on products quickly.

At the end of the day, I don't use most of the technologies I learned, and there's plenty of excellent examples of founders without prior programming experience that taught them self to code by doing and started making more money and much faster than me. It made me wonder if it was worth it all.

If your only goal is to learn new stuff, you can ignore my advice, but if you want to ship, avoid using new technologies unless necessary.

Be lean

For many years I worked in companies where quality was the priority. It wasn't acceptable to deploy half backed product that doesn't provide up to standard experience on all levels from the core functionality to small details. If the user enters their name, there must be a setting for that. If there's a list, there must be pagination. And so on and so forth.

When you are small, even a standard feature like name settings or password recovery could take the time that might be spent on more important things. When I was working on designs for my first big project, Ask User a widget for web sites, I noticed that I spend too much time on details that aren't necessary for the first release. I started cutting features until I left with the functionality that solves the main problem. During the development, I decided to step further and skipped things that seemed absolutely necessary at first, like the ability to remove created sites. I was planning to introduce that after the release but to my surprise, users didn't care. They wanted utterly different features that I didn't even think of initially.

Then I spend weeks writing a billing system only to learn that people don't ready to pay for the problem I solve. For the next project, Telepost, I decided to ask users to send me money to PayPal, and it worked out. Later I added a button "Activate the Pro plan" that does nothing but shows the message "We'll contact you soon" and sends me an email (using Zapier) with the user details. Then I'd talk with each interested customer individually. During the conversation, I was able to pitch my product and hear objections about why they aren't ready to pay. That not only saved me time but also helping to shape my project for users' needs.

Getting feedback as soon as possible and changing your product according to it, must be your top priority, so optimize for shipping fast. Cut as many features as possible, then cut more.

Afterword

Thank you for reading my article. I hope it was useful for you. I tried to outline the most important lessons I learned as a developer, but there's so much more to cover! If you liked it, please let me know. I'm planning to publish more articles on the topic including more business-oriented and if you're interested in reading them first, follow me on Twitter.

The photo for cover is kindly provided by chuttersnap on Unsplash