Working on a side project involves a lot more than just coding it up. Building it effectively and efficiently requires forethought of planning the development process, architecting the database, wireframing the layout, and prioritizing features - all before implementing functionality - and finally styling the interface. Too many times I had to rewrite the code for my projects, sometimes multiple times, because I had rushed into coding. I hope you avoid making this mistake and that you find these steps useful in helping you manage your project(s). Good luck and I can't wait to see what you build!


  1. Before writing a single line of code I like to think deeply about what I'm building. I write down everything I can think of that has to do with the project without paying any attention to technical implementation details. The point here is to dump your ideas onto paper so you can organize your thoughts in the next step.
  2. Out of the mess of notes and half-baked ideas from step one I try to tease out a list of features. This feature list will dictate the interface layout and database architecture in latter steps. I really like the template for formulating feature requests from Gregory Brown's book Programming Beyond Practices. Here's an example: As a "non-registered user" I want to "create a todo" so that "I can keep track of what I need to do that day".
  3. Then I order features by priority, putting low handing fruit at the top of the list. Then I group the most important features by two or three versions. All of the remaining features go into a backlog. The general idea is to avoid intricate and complex features at the start and work in increments. For another perspective check out Andy Bell's article on how he created Jotter. Initially I used Trello for this steps but I've since found a simple .txt file to be faster and more easily scannable.
  4. Sometimes the kind of project you're building will favor one platform over others. In that case take care to consider the advantages and disadvantages of the platform you'll be building for. For example:
    • A regular web app requires no special tooling but it can't work offline.
    • An Electron app makes your project available to Windows, Mac and Linux users but picking up the framework has it's learning curve.
    • A mobile app will require you to use a framework like Cordova, PhoneGap, Ionic or React Native.
    • A progressive web app can also behave as a mobile app but it requires you to learn Service Workers and some other stuff.
    • A browser extension can enhance existing web apps but if you want to distribute it you need to go though a publishing process for each browser's extension web store.
    • A bookmarklet is simple to "install" but lacks access to some permissions like loading external scripts.
  5. The platform you choose can determine in large amount the interface of your project. If I'm building something with a graphical interface - everything but bookmarklets and browser extension essentially - I like to quickly sketch wireframes on paper to get a sense of what the visual structure.
  6. Visual layout of the page helps me think thorugh the database architecture, if a project requires one. None of my projects required a super complex database system, but even on small applications I've needed to rewrite most of the storage logic because I hadn't thought it through initially. Now I like to plan this thoroughly before I get to coding.
  7. In going throught the previous steps you'll got a more informed perspective on how features will be implemented. By this point you might have a pretty good idea how to implement features, but I still recommend jotting down notes on how you plan to code tricky recursive logic for example.
  8. Write all the code! ⌨️🔥 I recommend starting with the low hanging fruit and then moving to the more complex features. You will inevitably come up with some more ideas as you start coding, but try to resist immediatelly implementing them unless they really deserve to jump to the top of your priority list. What I do is write the idea in the backlog and then when I finish the feature I was currently working on I go back assess the priority of the new idea and place it in the appropriate version or leave it in the backlog. While on the topic of completing a feature, I like having a clean and historically accurate git log so I take effort to write descriptive commit messages when I'm done with a feature.
  9. This is the point when I start paying some attention to the aesthetic aspect of my project. Any earlier and I risk having to re-write the CSS because the HTML structure changed significantly. I've wasted so many hours rewriting CSS so here I am to warn you not to make this same mistake.