You just finished another tutorial and have decided to try to build something of your own. You get an idea you’re excited about and want to jump in and start building right away! It might feel productive and energizing at first, until soon you start hitting blocks of things that maybe you didn’t think through well enough, or possibly at all. Is this even possible? Did i just spend two weeks on a feature I don’t actually need? Should I just start this over? --- Sound familiar?

When you are learning and building a side project, often one of the first mistakes made is not creating a plan and a process for building the project. One of the first things that may cause your project to go into a pile of abandoned GitHub repos, is if you get an idea and then you don’t limit the scope of that idea to an MVP (Minimum Viable Product). To get a clear idea of what you want to build you need to think through a few major things. I suggest using the questions below to write up a quick project spec.

MVP

• Description: What does your product do? What is its main purpose/function?
• Features: What are the bare minimum features you need to build it?
  • Go through these features and ask again if they’re really necessary for your first iteration of something you can call finished.
• Architecture: What will your front-end and backend architecture look like?
  • What frameworks/tools do you want to use? Are you using these because you want to learn them? Because they are the only things you know? Because they are the best choices for the project at hand?
  • Do you need a backend? Will you be persisting data? how? Will you have a user system? And is it necessary for an MVP? What will your data models look like? What API endpoints do you need? Are you integrating data from third party APIs?
• Design: What views/routes will you have and a very simple design mock/wireframe of each so you have a visual idea of the structure of your application.

Workflow/Process:

Create broad milestone goals for your MVP features

• Create or find a project skeleton with the frameworks/tooling you have chosen
• Model your data/ create API’s / backend
• Front-end that consumes your data
• Design

Start breaking down goals into smaller problems, and begin to write up issues/tickets. You can group these on a kanban board such as on GitHub projects, a trello board etc.

Work as though someone else might join you at any time and will need to be walked through your codebase/process.

For me this meant using the idea of feature branches that corresponded to tickets which looked something like this: Create a feature branch, work on the feature or bug, push it up to GitHub and create a PR(pull request) to get my code reviewed before merging.

Sometimes seeing your code in a different format (i.e. not in your favorite code editor/IDE), but in a PR will be enough to make your brain catch something you might not have, or hold you to maintain a better standard of code quality and readability. If you are working alone, ask yourself would I submit this code for someone else to review/understand/merge?

Create a README file. Document how to get your environment set up in development. Even if no one else ends up working on your project, your future self will thank you. Document things in general.

If you have any feedback or comments about your own processes, or lessons learned, I would love to hear them!