Always start with the Front End
10 reasons why you should start with the Front End when creating a website
I am a full-stack software engineer. Today I will talk about a design choice that I found repeatedly useful over the years, for developing new applications from scratch, in particular new webapps. When creating a new application, always start with the Front End. More precisely, always implement the UI first, then do the data bindings and only later touch the API and the Back End.
Over the past few years, I had the opportunity to implement or supervise about 10 greenfield projects, both personal and for clients. Looking back, one thing was common across all the projects that went smooth and ended up successful, something which the projects that initially struggled to come together were missing. In successful projects, I always started by building the Front End first.
This advice applies to new projects where you own both the Front End and the Back End and have freedom to start from either side. It also applies to developing new macro features for a product. It also applies if you are managing a bigger team by giving the Front End group a head start.
10 reasons why you should write the Front End before the Back End when creating a website
- Easier to show progress. Stakeholders — both technical and non-technical — pick up on visual concepts a lot faster. You can have more meaningful conversations if you have something tangible to play with. You can spot corner cases early on and bring them up easily, by showing exactly what you mean rather than asking users to imagine scenarios.
- Easier to receive feedback. Everyone understands UI, it is either what you want or it is not. You can afford to summon 10-minute meetings very often with the stakeholders to make sure you are on the right track. You can pop by their desk with your laptop and have a quick chat. You can record a screencast and send it over for feedback. There is no friction.
- Brings everyone on the same page. If your project is low-funded, you probably don’t have the luxury of a dedicated designer to make beautiful Adobe Illustrator mockups. Unless you start with the Front End, the managers and other stakeholders definitely have different ideas of how the final product should look, feel and work. By creating the visuals first, you make sure everyone is on the same page.
- Easier to iterate. Client doesn’t like something? Throw it away easily and change as necessary. You don’t have to worry about all your data bindings, about the way you structured your database, or about reshuffling your entire API, because you have none of those just yet.
- Development becomes more enjoyable. Nothing is more annoying than looking at a half-baked bootstrap default template for hours at a time, while getting the project off the ground. It is just ugly and off-putting. Development should be enjoyable, you should be looking at beautiful designs.
- No more context switching during development. If you start with the Back End, every so often you would have to implement bits of UI in a rush, to make sure that the end-to-end integration works as expected.
- Preserves development momentum. If this is not your full-time gig, but rather a side-project you moonlight during Saturdays only, being able to get back to the project 7 days later is a lot easier if you “see” where you left off, rather than understanding what exactly you meant in your back-end BDD test which you left failing.
- Backend design becomes easier. Things fall into place much smoother when it is time to design the API. Once the Front End is completed, the client is already assured that they receive what they asked for and there are less last-minute-changes. You also are sure that you are building the correct product and you know all the edge cases. Building the API will feel like filling in the gaps. Everything will fall into place.
- 99% of webapps are just fancier excel spreadsheets. Another way of putting it is that webapps are just nice UIs over some data. Airbnb: a table of available properties with the ability to add rows (new properties) and reservations. Netflix: a list of available movies sorted by relevance. Instagram: a list of your friend’s pictures with the ability to filter by hashtags. Getting the UI right is 50% of the job. Adding the other 50% (the data) is much easier once you can visualize the data.
- Front End more in line with the business. I am sorry, but the users do not care about the Back End. They don’t care about the beautiful API you designed, and definitely do not care that you designed it such that it is backwards compatible for the next decade. Users care about things in this order: 1. Does it solve a pain point for them. 2. Does it look good? 3. Does it crash? If you have a larger team, giving the Front End a head start will allow them to polish the UI and UX while the Back End catches up. Starting with the Front End addresses the most important 2 points of the product.
That interview question
In an interview, earlier this year, my interviewer asked me: “How do you ensure that you are building the correct thing, once you are given the specification of a project?”.
My answer back then was a variation of the following vague points:
“I do not develop in a vacuum, I do not take the specification run away for a month and then come back with something. Instead, I try to keep the stakeholders of the project (users / managers) in the loop from early on. Every time I achieve a milestone, I present it to them and ask for feedback. I want them engaged and enthusiastic about the project. Yada, yada…”
All of this above is true. I do believe this is the correct way to ensure that you are building the correct thing. I do all the things I mentioned above, but in the way I answered, I did not provide any actionable piece of information to the interviewer. Looking back at it, what I really wanted to say is:
“To ensure that I build the correct thing, I start with the Front End. That simplifies the interaction with the users from the early stages of the product and allows me to course-correct when things diverge from requirements.”
Case Study — www.cashflow.finance
www.cashflow.finance was my moonlight project for 2018. It is a budgeting app, similar to mint.com, but more privacy-focused. (It is currently in beta, so you can subscribe if you want to be part of the test group.) There are few things that are special about this project:
- It was one of my 4 New Year Resolutions for 2018, which meant that I really wanted to have it done by the end of the year (today).
- I did not have a clear business model. I was building it mainly for myself, which meant it was never top priority.
- As a result, I started working on this project on 4 discrete occasions. Every time I worked on it for 2 days, after which priorities changed and I was pulled into something else for several months.
- After each multi-month break from this project, I would start it from scratch, but from a different angle.
Each of the screenshots below was taken after exactly 2 days of development for each attempt. It is a powerful illustration of how far you can get if you start with the Front End.
Take 1 — Starting with a single feature
Starting this project, I was convinced that it would differentiate itself through better data visualization, in particular better charts. After being one of the top contributors of Plottable.js I knew that no off-the-shelf open-source solution for charts would be as flexible as I wanted, so I decided to build my own. What better way to start the project than with its core feature, right?
Wrong. After 2 days, I did not get very far, I was pulled into a different project and I was not motivated to continue this way few months later.
Take 2 — Starting with everything at once
After the first failed attempt, I figured that it is demoralizing to start by obsessing over a particular feature. Instead, I should cover the breadth of the application and list all possible ideas I can find. Two days and dozens of paper sketches later, I had a pretty good idea how each page would look like, what are the menus, what data I show, how I show it, etc. This is almost like starting with the Front End, right?
Wrong. After 2 days, I did not get very far in terms of code. Most of my work was on paper. There were so many features, it was intimidating and I was not sure where to start from. I got pulled into a different project again and, before I knew it, I lost all my paperwork. I did not record anything on the computer, so all the effort was in vain.
Take 3 — Starting with the data
After second failed attempt, I figured that I would reduce the scope of the project to budgeting only, which was the initial idea. No fancy features just yet. I decided I would start with the data. That way I would know what to to build and how to plot it, right?
Wrong. After 2 days I had setup webpack, redux, file uploading, an XLSX parser, a query engine, some hacked-together tables, a way to download files, a way to delete files, etc. After 2 days I got pulled into a different project again and when I resumed work, I could not remember which data goes where, or how exactly my data looks like. Understanding where I left off was an overhead, so I keep delaying resuming the work.
Try 4 — Starting with the Front End
The end of the year was quickly approaching and not much progress has been done. On the 4th attempt, I tried figuring out where I left off before. After half a day, I decided to scrap everything and start by building the Front End.
After two days I had the look-and-feel of the theme setup, finished logo, chosen colors, created plots with dummy data, converted all my ideas from paper sketches to HTML. The difference is staggering. I can “touch” my idea now and it almost feels like a finished project. Yet, all the data is dummy and no interactions are implemented.
I got pulled into a different project again, but this time, resuming where I left off was easier. Everything was falling into place so nicely. It was a pleasure to add new features when the entire app was looking so good. It felt like a polished product even after only two days of work.
Conclusion
To ensure that I build the correct thing, I start with the Front End. That simplifies the interaction with the users from the early stages of the product and allows me to course-correct when things diverge from requirements.
— Andrei Cioara
If you enjoyed the article and want to make sure you know about my next one, you can sign up with your email address below. I only send blog-related updates and have a zero-spam policy. Otherwise, I hand picked my best software-related articles from the past (just below the form).
