Ideal workflow for building a web application (side-project)



What is a typical workflow you follow while building a web app? How do you prioritize and complete task items like Mockups, TechStack decision,DB Schema design,API design, front-end, back-end coding? Can you kindly give some insights?


The workflow I find most useful is to start with getting the backend/data layer talking to the frontend as fast as possible, even if it’s not flashy, because once you have both sides communicating on a feature, then you’ve got something that you can start getting feedback and ideas for more features.

Once you’ve got that feature in place, then you can build out your frontend and backend to be more polished. For that I recommend getting some unit and end to end test coverage in place on each layer of your app (database, HTTP, frontend) and also having a build process (ex a Makefile for the backend and Webpack for the frontend) so in addition to making it easier to tell which bugs are actual bugs and which are just configuration errors, and it will also help you onboard new contributors.

When your project is just starting, if you don’t know how often you’ll be able to work on the project, I recommend using a framework on the backend so you don’t have to spend as much time writing boilerplate early on, and you can return to that framework’s logic on Saturday morning instead of having to spend the morning remembering your context on what you were working on. If you’re using Go I recommend Mark Bates’s Buffalo (, which is similar to Rails


i really like to sketch out the front end first and use that to inform how my data structure gets built.

usually i start with a wire frame, or even just a uml, of what the user interface is going to look like, with an eye to what data is going to be coming in and going out and then, next, design my data.

i go this route because many times in the past i have had minor changes or spec clarifications on the front end result in major refactors in the api and data layer; things that would have easily been realized if more attention had put into designing the front end at the beginning.

once the data layer is established, i then move on to the api. normally i try to keep it as generic as possible, at least initially. you can always go back and create very specific api endpoints later when the requirements of the front end come more into focus.

this is also the point where i start writing documentation in earnest.

once i have a data layer informed by the requirements of the interface and complete if somewhat basic api, the front end is (hopefully!) just a matter of stitching the api to the interface with a lot of cursing at css and whatnot.

of course, while building the front end, new requirements and ideas will always crop up that will demand changes of the api and even, maybe, the data layer. but if you start with the basics of the front end these will be less frequent and difficult to accommodate.


Principles of user-centred design can really help you here.

Your app probably exists to serve a user need. Regardless of how you identify what that need is, once you know it, you can start to design and wireframe interfaces that meet that need. You should be continually refining these throughout the project, ideally with feedback from users.

Start with the front-end, because that’s what users see.

Once you have a good prototype of the front-end, you can consider what kind of data your app will need to store. These will become your database models. Also consider whether you need to make use of any third-party data sources or APIs.

You can also consider non-functional requirements at this stage. Things like uptime, maintainability and desired cost will help you choose the right stack to build your app.

Once you have all that decided, actually building the back-end to knit all these things together should be a straightforward, methodical process.

In terms of keeping track of your work, a kanban board on a free service like Trello will do in a pinch for a side project. You might want to represent each task in terms of a “user story” - phrased in terms of something the user will be able to accomplish once the task is complete. This will also help you understand the order tasks need to be done in.


this is such an elegant summation of the ideas i’ve had floating around my head for years. spectacular! seriously considering actually printing this out…


Agree with all of this, and I love Waffle to keep myself organized.


Thank the Government Digital Service!