Learning by Doing: The designing and building of Foodsie.io

Lessons and take aways from building a web app from start to finish

As a developer, sometimes it’s easy to get caught up in the fervor of learning new technologies, tooling, and best practices and forget that at the end of the day software is an ends to a mean of build services and applications that benefit people.

In this article, I’m going to talk about my wholistic approach to building apps by discussing design decisions and lessons I learned while making Foodsie, a restaurant review app that you can check out here. I want to share what I learned from Foodsie, because I believe the lessons learned from building and deploying a web app from beginning to end have served me tremendous wisdom.

Lessons I’ve learned along the way building Foodsie.io:

Commit to a plan and stick to it

Failure is an option here. If you are not failing, you are not innovating enough — Elon Musk

When I started working on Foodsie, before writing a single line of code I had drawn probably at least 5 pages worth of sketches and had written many lists and blocks of text about features, user flows, and r&d. This proved invaluable, because it let me iterate on my ideas quickly and get feedback without having to implement a single thing in code.

original ideation sketches

It’s a lot cheaper to iterate with pen and paper than it is to iterate with code. Just by writing ideas out and drawing user stories, I was able to flesh out my vision of what Foodsie could be and tailor it to an audience —from the beginning I knew Foodsie would be some sort of restaurant review aggregator. After prototyping on pen and paper, I realized Foodsie would work really well as a platform on which restaurant reviewers (aka Foodsies) could write and share restaurant reviews.

When thoroughly thought out, mock ups translate to code seamlessly.

Before getting to building, I found it important to form a brand and identity for my product. One of the things I really take pride in about Foodsie.io is that it looks consistent and cohesive. An app’s identity matters because it reflects the developers confidence in the product and the health of the rest of the app.

Foodsie.io’s color scheme (using coolors.io) on the left and app’s index.css on the right

Pick a color scheme, a design principle (material / flat / bootstrap), and ideally one to two fonts. These can change over time, but it’s important that if they do change, they change consistently. The goal of all this is to ensure you have some sort of plan that you’re following so you have something to reference if you ever feel lost. This goes a long way, and was a pillar in the success of Foodsie.io.

Be opinionated and decisive with your architecture

A startup messed up at its foundation cannot be fixed — Peter Thiel

In projects I’ve failed, I realize that one my common pitfalls was indecisiveness with architectural decisions. With how fast the software development ecosystem evolves, it’s incredibly easy to start off using a certain set of technologies, only to read a medium article or two and realize that you actually want to try out a different set of technologies.

There’s nothing wrong with using a better technology if it brings benefits to the project and your workflow. In fact, a big part of the building process is stepping out of your comfort zone and trying out new things. It’s a problem, however, is if doing so impedes with your progress and motivation to work on the project.

One strategy that has helped me not fall into the trap of tech envy, was taking the time before beginning to code to thoroughly research and refine my stack. For Foodsie, the technologies I decided on were React, Redux, and CSS Modules. I already knew I wanted to use React and Redux because I absolutely love React + Redux, but I wasn’t sure what styling technology I wanted to use. Before deciding this part of my stack I actually bootstrapped an app with stylish, css-blocks, and CSS Modules before deciding that CSS Modules was the technology that I would go with.

A good architecture will empower you to build quickly and modularly 💯

If you want to check out my tech stack and my project layout, Foodsie is completely open source. You can check out and fork the project from here on Github.

Building something you’ll be proud of inside and out

What ever good things we build end up building us — Jim Rohn

In every application that does anything interesting, there’s always going to be technical decisions that have to be made. The decisions that have to be made are generally a tradeoff decision between getting the job done fast and getting the job done right. In professional settings the right decision isn’t necessarily obvious due to timelines and strict project constraints. But in solo projects it’s almost always a better idea to take the time and figure out the best solution.

The reason why is because a project will be most successful if you enjoy building it, and technical debt will strip away the enjoyment of building. If you don’t enjoy the building process and times begin to get rough, it’s going to be hard to build up the motivation to continue working on your project.

In creating Foodsie, I’ve made it a ritual to refactor my code in the mornings and build out features in the evenings. This has helped me tremendously in keeping tech debt to minimum because it meant I could implement a technical solution naively in the afternoons, think about the problem over night, then spend the mornings cleaning my slate by finding the best solution.

One method I’ve found successful for doing high-level design refactors is to use CSS to add a cyan border to every div: div { border: 1px solid cyan; }.This helps visually verify that your layout is clean and that there aren’t any hacks or shortcuts being made in the app’s styling.

border: 1px solid cyan is a great way to identify visually any hacks or short-cuts being made with CSS

Another thing I occasionally do is I navigate the DOM tree using chrome dev-tools and manually check for any div-soup. It’s important to ensure your DOM tree is as semantic and as light weight as possible. Doing so benefits users who use screen readers to navigate your webpage, and reduces page load times across the board. On top of that, a light weight DOM tree will also reduce encounters of bugs and side effects relating to html and styling.

Ultimately, you want to ensure that your app is thoroughly beautiful inside and out. Having a poor codebase is an easy way to get frustrated and burn out of your project. A clean codebase will serve your project well and make you better developer in the long run.

A clean UI reflects a clean codebase and a well executed product

Have the mindset of learning in mind

I’ve created over 64 projects on Github. Of those, I would say I only saw through at most 6 to the deployment phase. Sometimes you hammer away endlessly on a side project only for some other shiny idea to come along and steal your interest. You might feel guilt for the ever growing pile of unfinished projects you leave in your wake.

All I want to say is that this is how great developers are born. Every time you take on a new project you’re trying out new technologies, gaining intuition on new patterns, and pushing your limits. Your building associations and intuitions continuously. And those intuitions carry over to your next project and your next next project.

Failure is inconsequential — it even deserves respect. Regardless of whether you complete a project or not, you’re become a better developer by trying.

So please, don’t be afraid of starting a project and never be afraid to try, because the worse that can happen is that you learn.

Thank you so much for reading! If you want to reach out, I’m on Linkedin and on Github. You can also shout me out on any social media: @FermiDirak.

Cheers!