My Software Development Process

Having built a couple of projects from start to finish. I’ve noticed a simple process that I naturally default to when it comes time to tackle a new Fullstack application project. Here it is: Talk to the client: I first start by hopping on a call with the client so that I can listen to him explain what exactly he is trying to build. This helps me to understand what problem he is trying to solve using the software. Usually they have big ideas for their application, a whole lot of features that would take a long time to build so I try to narrow it down to the most important thing. Requirements Document: After the call, I ask the client to prepare a document listing and explaining each individual feature that they want in the application. Most of the time, any serious client will already have this available which he sends and I take my time to read through. Development schedule/timeline Document: One of the most important things that a client wants to know is how long the project will take to be completed. It’s difficult to just give an estimate off the top of my head, hence why the Development Schedule document is needed. All I need to do is look at each individual feature in the requirements document and assign a timeframe of 1 or 2 weeks depending on the complexity. I also throw in an extra week here and there for features that I have no experience building or have some uncertainty with. At the end, I add up all the weeks to give the total estimated time for the entire project. I also avoid trying to impress the client with short timeframes that’ll be difficult to meet up with, it’s better to give too much time and complete a feature before the deadline than to give short timeframes and miss deadlines. Figma Designs: A client may already have designs available and we can get straight to work. If they don’t then I proceed to refer to them a designer to work with if they don’t know any. Database Design: Now that I have both a requirements document and figma designs, the next step is to study both of them and use dbdiagrams.io to do some basic database modelling just to get an overview of what tables l need to create in the database and what their relationships are. An e-commerce site for example, will have tables for users, products, orders, transactions, carts, etc. I try to predict what queries I would need to make when I start writing my controllers and I include fields in the tables that would make the queries possible. I’ve found that it’s important to not overthink this part or try to be perfect, requirements may change mid development and you can always figure things out as you go. Database Migration files and Models: For my backend, my go to NodeJs framework is AdonisJS. I love it because it comes with libraries for building production ready applications out of the box such as auth, emails, CORS, migrations, seeders, etc. It also uses Typescript. So, I create a basic AdonisJS app, and using my Database design, I prepare database migration files and models that match, This is easy because AdonisJS framework makes use of Lucid ORM for handling MySQL queries under the hood. Build UI: For building the UI/frontend of the application, I use ReactJS, NextJS if SEO is important. I use Atomic Design pattern, the folder structure involves categorizing my components into Templates, Organisms, Molecules and Atoms. Basically, an atom is the most simple component usually made of just one element, example is a button. A molecule is a combination of two or more elements, example is a Search bar which is a combination of an input and button. An organism is a more complex component such as a navigation bar. Finally, organisms and molecules come together to form the template for an entire page. Deployment and Demo: After completing the first feature on the development schedule, it’s time for a demo. If the client doesn’t have an AWS account then I deploy the backend on render.com and the frontend on netlify.com or vercel.com for free. Depending on the client’s preference, we can hop on a call where I share my screen and Demo or just do a quick loom screen recording and send the link along with the Netlify or Vercel link for the client to test. I repeat this for every other feature in the document till the project is finished. This is my current process for ensuring a successful delivery of fullstack application projects. If you have any tips to give or anything I can start implementing to improve the process then I would like to hear it, thanks for reading!

Apr 1, 2025 - 23:58

Having built a couple of projects from start to finish. I’ve noticed a simple process that I naturally default to when it comes time to tackle a new Fullstack application project. Here it is:

Talk to the client: I first start by hopping on a call with the client so that I can listen to him explain what exactly he is trying to build. This helps me to understand what problem he is trying to solve using the software. Usually they have big ideas for their application, a whole lot of features that would take a long time to build so I try to narrow it down to the most important thing.
Requirements Document: After the call, I ask the client to prepare a document listing and explaining each individual feature that they want in the application. Most of the time, any serious client will already have this available which he sends and I take my time to read through.
Development schedule/timeline Document: One of the most important things that a client wants to know is how long the project will take to be completed. It’s difficult to just give an estimate off the top of my head, hence why the Development Schedule document is needed. All I need to do is look at each individual feature in the requirements document and assign a timeframe of 1 or 2 weeks depending on the complexity. I also throw in an extra week here and there for features that I have no experience building or have some uncertainty with. At the end, I add up all the weeks to give the total estimated time for the entire project. I also avoid trying to impress the client with short timeframes that’ll be difficult to meet up with, it’s better to give too much time and complete a feature before the deadline than to give short timeframes and miss deadlines.
Figma Designs: A client may already have designs available and we can get straight to work. If they don’t then I proceed to refer to them a designer to work with if they don’t know any.
Database Design: Now that I have both a requirements document and figma designs, the next step is to study both of them and use dbdiagrams.io to do some basic database modelling just to get an overview of what tables l need to create in the database and what their relationships are. An e-commerce site for example, will have tables for users, products, orders, transactions, carts, etc. I try to predict what queries I would need to make when I start writing my controllers and I include fields in the tables that would make the queries possible. I’ve found that it’s important to not overthink this part or try to be perfect, requirements may change mid development and you can always figure things out as you go.
Database Migration files and Models: For my backend, my go to NodeJs framework is AdonisJS. I love it because it comes with libraries for building production ready applications out of the box such as auth, emails, CORS, migrations, seeders, etc. It also uses Typescript. So, I create a basic AdonisJS app, and using my Database design, I prepare database migration files and models that match, This is easy because AdonisJS framework makes use of Lucid ORM for handling MySQL queries under the hood.
Build UI: For building the UI/frontend of the application, I use ReactJS, NextJS if SEO is important. I use Atomic Design pattern, the folder structure involves categorizing my components into Templates, Organisms, Molecules and Atoms. Basically, an atom is the most simple component usually made of just one element, example is a button. A molecule is a combination of two or more elements, example is a Search bar which is a combination of an input and button. An organism is a more complex component such as a navigation bar. Finally, organisms and molecules come together to form the template for an entire page.
Deployment and Demo: After completing the first feature on the development schedule, it’s time for a demo. If the client doesn’t have an AWS account then I deploy the backend on render.com and the frontend on netlify.com or vercel.com for free. Depending on the client’s preference, we can hop on a call where I share my screen and Demo or just do a quick loom screen recording and send the link along with the Netlify or Vercel link for the client to test. I repeat this for every other feature in the document till the project is finished.

This is my current process for ensuring a successful delivery of fullstack application projects. If you have any tips to give or anything I can start implementing to improve the process then I would like to hear it, thanks for reading!