2
3 Comments

Should I start building frontend or backend first?

So I am working on one of my side gigs which essentially is trying to streamline processes for financial analysts (landing page: https://www.memofi.co/) when I picked up an amazing design book called "The Design of Everyday Things" by Don Norman and started reading about designing your product in a Human-Centered way.

Human-Centered Design (HCD) focuses on the person that you are building the product for, therefore, a big part of it is actually watching a user perform the task you are trying to streamline, then building a prototype (wireframe) from what you've learned and watch the user interact with that. Then iterate.

This makes me think that you would focus on iterating the frontend (not fully building it out but using some sort of prototyping tool) and then implementing the frontend code, followed by the backend code.

My worry is that if I start with the backend code, and then ideate/iterate on the frontend the endpoints/business logic that I will need will change.... which is why I am asking for some help here!

Side note: anyone know of a really good high fidelity prototyping tool?

on June 24, 2020
  1. 1

    Well you just answered your own question as jake_db says. In my case I always design the front end first since that helps me find out if I forgot some data structure, etc that would be needed to support this or that function.

    In my experience, the backend will always be easier to modify than the front end since the main business logic your users will experience is in the front, and you need to make sure it feels as fluid and flawless as possible with a very simple to follow logic. Ever tried a tool or website where the steps where not exactly clear on which button to press for what? That most likely could be a website where backend was created first and then the front end.

  2. 1

    I think you've just answered your own question. I started as a back end developer and because of this I was quite biased towards starting with back end first. But as the time went on and I got more interested in the front end I've realized that it's much better to design and perfect the front-end first (because it will change a million times by the time you consider it finished). Once you have the front end which your client is satisfied with then you should proceed with back end. By then you'll have a pretty good idea of what to write.
    I wouldn't start with only a prototype/wireframes. Building a proper front end first will force you to solve a lot of issues that wouldn't even cross your mind if you were only to do a prototype. And if you are using the same language for both ends then you'll have a lot of logic already in place that you can extract into a shared module/project.
    As for the prototyping tool, somebody recently posted their prototype on this website which was done in https://marvelapp.com/. I have not used it but I liked how the prototype looked and behaved. It seems to be quite similar to https://www.invisionapp.com which I used in my last contract and seems to be a great software.

  3. 1

    I use Figma to design my prototypes. It's free. The paid version includes stuff for teams and shared component libraries, but they're not absolutely necessary for solo developers. Highly recommended.

    I start with a feature in mind, write down its use case and requirements, design it in Figma, then develop it. Iteratively, of course. Sometimes even the requirements need updating.

    You can avoid the pitfall of endpoints/business logic changing too quickly by decoupling the front-end from the back-end. Develop the "JAMStack" way. All your front-end code should be doing is make fetch requests to your API. Host your front-end assets on a CDN and host your backend code on a server of choice (e.g. Linode, Heroku, Raspberry Pi, whatever).

    If you were to use GraphQL you'd have just a single API endpoint, instead of many, and a lot less code to rewrite when requirements change. It's a breeze to change your queries as needed. The one thing I hate about GraphQL is that you find yourself writing duplicate code a lot, only in a different format. Thankfully tools like Hasura and graphQL-generator exist to address these headaches.

    Start with your app's requirements. Then develop a basic API, then a front-end.