Baby Steps to Your First Full-Stack App
Around Christmas 2018, I decided to take a two week vacation and finally build my first full-stack project, which I had vaguely conceptualized two years prior. After a lot of learning and bug squishing, I finally finished v1 of Cellar Scraper… a year later. Building your first app can be daunting, and I’m certainly not the first developer to massively underestimate how challenging a project will be. With that in mind, I thought I’d share some tips for making the process as painless as possible.
Plan
Planning is essential for large projects and can also be a great tool to help keep you motivated. There are a few parts of planning that you may want to consider depending on the scale and complexity of your project.
Before you even start coding, create a high-level doc explaining what your goals are for this project and what the end system might look like, including what tools you plan to use, where everything will be hosted, etc. Here is the doc that I worked from for my project.
Consider using different tools at different stages of the project. For example, when I first wrote my scraper, I found it easier to store the collected data in Google Sheets rather than having to set up a proper database, but I knew I couldn’t use that as a long-term solution because it would quickly hit row limits.
Almost as important as outlining what you will do is documenting what you won’t do in v1. Unless it’s essential to your app, leave off things that add a lot more complexity. For my app, I thought it would be really cool to use the data I’m collecting to offer predictions rather than just describing historical data. Having never made a predictive model before, I know it could take me months just to learn enough to implement that one feature.
By documenting what is outside the scope of what you’re working on for v1, you can keep yourself from going down a rabbit hole and cut down the time it takes you to have a minimum viable product. And since it’s written down, you won’t have to worry about forgetting it if you want to come back to it in a future iteration of the app.
I also find it helpful to outline user stories. Rather than thinking in detail about the technical needs for the project, think about what the user will want to do. For example “user can sign up for email alerts” or “user can filter a dashboard to see high-level stats about a specific comedian.” If you’ve worked on any assignments for coding classes, you’ve probably noticed that they phrase the requirements like this, and it’s also a common practice in Agile companies. Of course, you’ll need to break out each user story into more detailed technical goals later, but it’s a good way to start segmenting your work (and depending on how eager you are to share your app with the world, you could potentially ship it with only a couple of user stories completed and add the others later).
When you’re ready to start coding, pick a user story and break it out into even more granular steps (e.g. for filtering a dashboard — I needed to populate a dropdown menu, make the selection trigger a GET request to the database, and update the charts based on the response from the request). I used a white board to diagram what the relevant features would look like and keep track of my to-do list for the features, but you could use an app or a notepad.
Know when to fold ‘em
I learned this one the hard way — don’t throw too much time at something that you’re not making any progress on. After I had a working scraper, I wanted to host it in Heroku so that I could schedule it to run every night. I spent most of my second week of vacation trying to get this to work, and every time I thought I had found the solution, it was another dead end. Eventually, I just gave up and figured out how to schedule the program locally in a couple of hours, and I leave my laptop open every night so it can run. If I ever have a ton of users relying on this, I’ll go back to researching this issue, but for now, I don’t think my mom will be upset if she misses an update one day a month.
Talk to people!
If you’re working on a solo project, get input from other people at the outset and intermittently throughout your work. Maybe they’ve seen a similar project that could be a useful blueprint, have suggestions for what functionality they would want to see as an end user, or can recommend some technology that you didn’t even know existed.
I was initially planning to use MongoDB and Node just because those were the tools FreeCodeCamp promoted when I first started learning web development (even though I had never used them). A former coworker suggested Flask instead of Node, and I was able to reference an old project he had worked on to see what the Flask routes should look like. Another friend took a look at an early iteration of my landing page and suggested some revisions to make it easier to interpret.
Note: you should specifically be talking to people to get ideas/feedback, not just a pat on the back.
Be kind to yourself
Ok, this advice sounds like the kind of empty nonsense that you use to justify eating a dozen Krispy Kreme doughnuts in a weekend (not that I’ve ever done that). But it’s important to keep in mind that you’re a human who has a life outside of whatever app you’re working on.
I genuinely thought that within that two weeks (give or take a couple extra days) I could write a scraping tool, schedule it, and build a full-stack website to show cool D3 charts with dynamic filtering, despite the fact that I had never worked with schedulers or back-end technologies and had limited experience with D3. Once I missed that self-imposed deadline and was back to work, it was hard to make very much progress each week, and I quickly became disheartened.
If you’re setting your own deadlines, be exceedingly generous. Or consider not setting any deadline at all (if it’s a side project). Work on it when you have the energy, and acknowledge that you need time to decompress from work/school, hang out with friends and family, and enjoy your other hobbies.
Hopefully these tips help you have a better first project experience. Or feel free to be really contrary and do the opposite of everything I said and let me know how that goes — wing it, never give up, only share your ideas with your cat, push yourself. Honestly, that doesn’t sound so bad either. Maybe I have it all backwards.
Thanks for reading this far. Here’s a picture of my cat helping out with my project on the Fourth of July as a reward.
