Understanding Product Development Process

In my earlier blog Technical Terms Every Founder Needs To Know!, I shared about the technical terms that non-tech founders need to know as they start their journey. Extending the topic further, I am sharing here the technical understanding of the development process for the non-technical founder. This can also be considered as the things you need to plan on the day your development starts.

Understanding and setting these things will also set up the right process and environment for predictable development. Setting these things up or asking for them from your development team makes you a savvy founder, taking control of your project.

👉 Setting Up Project Environments

As the name suggests, the project environment is the space where your project executes. Once the developer has developed the particular code, he then would be putting it on a test environment where the code runs and the developer can check for bugs. Once the segregated module is tested, it is then tested for integration- connecting it with the rest of the software and APIs. Once that is done successfully, the code is then deployed to the main server (production server). This is where real users can now use the platform.

So in summary your product goes through the cycle of development, testing, integration and launch (production)!

There are different project environments required for each action so that each action can be separated from the other and as a team as well as a business owner one knows the progress as code moves from one stage to another.

Thus, keeping the above in mind, one needs to set up the following environments.

Development and Self-testing

This is where a developer writes the code and would usually be his own machine and may be some cloud space for testing. The developer can himself test use cases or the code can be passed to the QA person who would test on his machine.

It is important that testing is done by another person and not just the developer as the developer may just consider the scenarios which he has taken while building the code and not the boundary cases. A dedicated QA can go deeper in testing and can also check the code with different manual and automation tools.

Once the tester is satisfied, the code moves to integration testing.

Integration Testing

During Integration testing, the developer tests the product with different 3rd parties that the product may be using like Facebook, Google maps or any 3rd party SDKs. All such 3rd parties provide their own testing environment and test data to test.


After getting satisfactory results, the developer then sets the product on a staging server which is where the product gets tested with real data. Testing with real data is important to make sure that you have not ended up with just a common or best case scenario dataset. Setting up a proper staging environment is crucial for proper testing and hence success. The staging environment should be set on the same server as the production is so that any issue with your server is found and rectified too.


This is where your live application runs and as you may have guessed, your code is finally deployed to the production server where it becomes part of your main application. A production deployment process set up in advance makes the process repeatable and predictable. The more, everything is tested in advance, the lesser headache for you at the launch.

👉 Setting Up Code Repository

A code repository is a place where your code resides. When a developer writes code, they would upload the code into the repository. It is also called Source control.

In contrast to saving code on their own drive or on a Google drive, a code repository provides many advantages such as

  • Branching of code which means your code is divided into sections and changes can be done to one section at a time and merged with other branches once work is done easily.
  • Version control which means in case of issue one can go back to the earlier version.
  • Access control on who accesses what.
  • Scalability to add multiple people or teams to the project.
  • Integration with various project management and communication tools like Jira and Slack make you and your team effective.

Given these advantages, code repository is must for managing and storing code as your product develops. Popular Code repos are Github, Bitbucket and Gitlab.

One often asked question is the difference between GitHub and Git.

Git is the version control system that you use to manage code. GitHub is the platform on which you use Git.

Project view on GithubFig: Project view on Github

  •  Control- System to record changes over a period of time so that you can fall back to any of the past systems in case of any issue faced.
  • Commit- To put code into the Git. This has to be done explicitly. Code does not saves automatically
  • Fork- Creating a new copy of Other words that would often be used related to Code repository are
    • Repo- The directory or storage space where your code lies
    • Version- The full repository
  • Clone – Copying the repository on your own computer
  • Branch- Copies of the program made to make changes. Unlike Fork, these copies are part of main program and would not have independent existence
  • Pull Request- The act of merging a branch with another branch or the project file
  • CodeCommit- Saving your code into the repository

Practices such as branching and Fork are used by developers to take a specific part of code and limit their new work to that only so that in case of any update going wrong does not impact the whole code. Imagine, if you were building a webpage without the ability to undo or redo facility. Anytime if you write something wrong, you have to start new- how difficult would it be?

Branching is the undo and redo for developers.

So a typical flow is that the user would create a new branch of the code. Add new code to it or make changes. If they like what gets built, they can add it to the original code. If they do not, they can just delete the branch and they still have original code intact.

Here is a snapshot of how a project looks like with its branches and files.

Project code files arranged into different branches and files on repositoryFig: Project code Files Arranged into Different Branches and Files on Repository

Keeping the practice of branching code also allows the team to insert good practises like code review, code checks etc on these smaller daily activities. Like you can create a rule that there should be a code review before every pull request or the code should pass through certain tests, at every pull request. If there are any issues found, the developer can fix the issues and then redo the pull request procedure.

Additionally to make sure that code is regularly being worked on and changes are visible, code commit frequency can be set up in the team. Unless a code commit happens, the team can never know what is being worked upon. One of the early signs of project failure is the irregularity in code commits. When you do not even know if developers worked on the code or not, or the developer told that he/she is working but there is nothing to show for 2 weeks, understand you are already in trouble.

Ayush Jain, CEO & Co-founder of Mindbowser Group

At Mindbowser, my CTO and I teamed up to build an agency that can bring the best of tech and knowledge to founders.

In case you would like to discuss your options further, feel free to get in touch at  or book a 30 minutes free consultation call!

Get Free Consultation!

At Mindbowser, the team commits code everyday so that our customers can see progress happening. We require developers to create a new branch for every new feature and the code to pass through the automated code review test at every pull request. These small wins make the larger win of predictable software delivery and good quality achievable.

Mindbowser CICD ProcessFig: Mindbowser Software development cycle

Now that you have understood code repositories as well as other terms around code management, let’s understand the deployment and automation process in detail as well as how to make the most out of it.

Code Commits and Branches tell you that work is being done, updates are being made and so on. Now, the important part is to understand whether the code executes properly or not. This is ensured by a process called Continuous Integration and Continuous Deployment (CI/CD).

Going back to the above example of building your website, the CI/CD is like the autosave and auto publishing with self checks built in.

Continuous Integration automatically checks for errors and runs tests on the code to make sure that new code integrates properly and does not cause any breakage. The tests can be pre defined or added on the go.

Continuous Delivery automates the deployment to the various environments- your machine, testing environment, staging and production.

By automating, you reduce the human tasks as well as human errors in these processes. The different parts that we learnt above like code commits, integration, deployment etc can all be automated, measured, monitored and even trigger an action. This setup and continuous improvements are together called the DevOps process.

Your team can build a DevOps process and can even set up a dashboard where you are able to visualize the logs, security, errors etc at one place.

At Mindbowser, we have built the dashboard using Elk and comprises of log monitoring using which devs can easily check application logs instead of having to gain access to servers.

  • Monitoring server usage
  • Network Traffic
  • Security protocols
  • Compliance violations related to HIPAA, GDPR etc

Here are a quick snapshot of the dashboard that we use at Mindbowser

Application logs divided into an easy layout allowing to filter, search and check issues Fig: Application logs divided into an easy layout allowing to filter, search and check issues

Fig: Application logs monitoring helps developers to check logs easily without having access to serversFig: Application logs monitoring helps developers to check logs easily without having access to servers

Apart from this, you may be using a project management tool like Jira. These project management tools allow you and your team to create a to do list, assign work, get updates, see reports etc.

Most of such tools have inbuilt features as well as integration to overlap with the process created by your team.

Fig: Screenshots of project from Jira- The project management tool showing the different user stories and their statusFig: Screenshots of project from Jira- The project management tool showing the different user stories and their status

This project management tool is where all progress and updates should reside. Emails or chats should not be the way to manage or get updates of your project.

Another important aspect of your development process is Demos. Demos are the time when your team shows you what they have built. Demos should be regular and timely. Once every 2-3 weeks or at every important milestone is a good frequency.

Here are my tips for a successful Demo

  • Communication should be free flowing
  • Have enough time and full attention during demo
  • Take note of any major or minor errors and get a clear action plan from the team to rectify it
  • If there are errors that form a pattern, discuss them with the team to find the underlying issue
  • Get detailed test cases, test executions, and defect reports for that release
  • Request a Code quality report
  • Compare against the original sprint plan and make sure nothing is missed from it
  • Get a link/build to test from your developers to keep testing post demo as well


To summarize these are the major things that happen during the development process. By understanding the process you can be better engaged with your development team in executing it.

Keep Reading

Keep Reading

Mindbowser is excited to meet healthcare industry leaders and experts from across the globe. Join us from Feb 25th to 28th, 2024, at ViVE 2024 Los Angeles.

Learn More

Let's create something together!