Divisio's Playbook.

Our step-by-step process for designing, developing, and maintaining exceptional custom software solutions.

  • Phase 1


  • Phase 2


  • Phase 3




  • Step 1
    Design Discovery
  • Step 2
    Technical Discovery
  • Step 3
    User Experience Design
  • Step 4
    User Interface Design
  • Step 5
    Prototype and Estimation


Before we can develop a new application, or build new features for an existing application, we must first design and prototype what will be built.

This section describes our design and prototyping process, so that you know what to expect.


Design Discovery

A discovery process is started to establish scope and goals of your project, making sure everyone is on the same page.


Kickoff Meeting

The first step is a kickoff meeting with our design team and your key stakeholders. It's natural that projects begin at different stages in the process, so we use this call to evaluate what has been done so far on your project and plan out a roadmap for designing the required functionality of your application.

Competitor Analysis

Next, we'll perform a competitive analysis to evaluate similar applications built by competitors and determine where those applications have succeeded and where they've failed. By doing that our team is going to identify opportunities for you to stand out.

User Personas

As a final step, we'll define and create user personas to gain an understanding of the different types of potential users of the application. We will define what motivates them, and what goals they would like to achieve when using the app. This is a crucial step to determine the best user experience.


Technical Discovery

Early on we complete a technical discovery effort to either understand and document your existing software stack, or research and recommend the right stack for your project.

This step can include conducting an in-depth code review on your existing application, researching technology for your specific use case, reviewing documentation for third-party integrations and developing a deployment and development operations plan.

User Experience

Our UX design process ensures that we are solving user's needs efficiently. That means building an application that is easy to use and understand.

Feature Map

To start, we create a high level view of the features of your application (Feature Map). It is starting point for closer examination of how the views will interact with each other, and is updated throughout the life of the project.

Feature Mapping

User Flow

Next, we'll build the steps users will take to achieve specific goals (User Flow). This become especially important when dealing with complex conditional workflows. Being able to visualize and flow allows clients, designers, and developers to share a mutual understanding of how features will work and what feature outcomes will be.

User Flow


Then, we'll create a set of wireframes of the primary views of the application. Wireframing allows us to create the general layout of the screen without having to decide at this point the exact content and imagery that will be used in the final designs. It's useful for:

  • Rapid Prototyping
  • Understanding Functionality
  • Demonstrating the User Flow
  • Ensuring a Solid Underlying Structure

User Interface

Once Discovery and UX Design are complete, we move to visual design, by selecting a style concept, then turning the concept into a style-guide, and finally, we'll create a set of high fidelity mockups of each view of the application.

Style Concepts

Style concepts demonstrate different options for the look and feel of your application, including colors, fonts, etc. We review your competitors products and determine how we'll differentiate your product from theirs, then we'll create two or three style concepts for you to choose from.

Style Guide

We use the selected style concept to create a document which sets standards for colors, fonts, buttons, header styles, typography and other elements to be used throughout the application (Style Guide). This ensures a unified, cohesive look across each section of the app, and serves as a reference for designers and developers throughout the project.

High Fidely Mockups

These mockups serve as a pixel-perfect visual representation of how the app will look. It incorporates the structure of the Wireframes with the visuals of the Style Guide. The mockups also incorporate visual assets like photography, illustrations, and icons.

High Fidely Mockups

Prototype and Estimation

Once the high-fidelity mockups are complete, we upload them to Figma to create a interactable prototype, which we then use to build a development estimate.

High Fidelity and Interactable Prototypes

Interactable prototypes allow our team and yours to interact with the designs and understand how the app will work. Everyone can test the application prior to development, discover edge cases and improvements which would have otherwise been missed. It can be a great tool for getting budgetary approval for the development of the application, or for pitching investors.

Development Estimate

Every single step done before in our design process gets everyone involved and fully understanding what will be buil. That allows us to create a detailed line-item estimate of the hours required to develop the app, and the associated cost. It's not possible to accurately estimate the cost to develop an app without first designing it, which is why a systematic design process a must-have.

Development Proposal

The Development Proposal outlines the proposed cost to build, development team, and timeline.


Design Phase Deliverables

Those are all the results you're going to get after the Design Phase is complete - a generous set of deliverables to get your project to succeed.

  • Competitive Analysis
  • High Fidelity Mockups
  • User Personas
  • Mobile Prototype
  • Feature/User Map
  • Desktop Prototype
  • Wireframes
  • Development Estimate
  • Style Concepts
  • Development Proposal


  • Step 1
    Pre-Development Planning
  • Step 2
    Active Development
  • Step 3


This is our methodical, scientific approach to building cross-platform apps, including iOS, Android, and web apps.

This section describes how our design phase is connected to the development phase.


Pre-Development Planning

To ensure an effective and efficient development process, we start by doing some pre-development planning, such as assembling the development team, completing a design to development handoff, establishing project milestones, creating stories, and planning sprints.

Assemble the Team

Every project tipically includes 5 professionals: two senior developers, a project manager, a designer, and a product owner.

Design to Dev Handoff

Once the development team is assembled, they meet with the original design team for a design to dev handoff meeting. A comprehensive handoff ensures that developers fully understand the application and have what they need to build it.

Prior to development beginning, the development team review all the materials created in the Design Phase, including the market research summary, user personas, user stories, user flow map, style guide, high fidelity designs, and the interactable prototype.

Additionally, the design team provides all of the required image and icon assets in the proper formats, and documents any interactions or workflows that are not properly demonstrated in the prototype.

This systematic handoff ensures that developers have everything they need to proceed quickly and efficiently, without blockers.


The project manager establishes the key milestones for the project (or version releases). Instead of just having one deadline at the end of the project, we have several milestones along the way that each include a limited version of the app with a limited number of working features for you to test.

The goal is to get a working set of features in front of the client as early as possible in the development process, so that we may gather feedback and ensure the features meet the clients expectations.



Once milestones are established and agreed upon, the project manager begins creating stories. Stories act like tickets, which are assigned to developers during sprints. They describe what the developer needs to build. The stories are created based on the designs and the individual line items from the original estimate. Each story has a number of hours to complete, according to the estimate.

For each sprint, developers are assigned a number of tickets whose combined estimated hours equal the number of hours in the sprint. This allows the project manager to measure the effectiveness and efficiency of each developer and the project speed itself, for each sprint.


Sprint Planning

Once the stories have been created, they are splitted into two-week sprints. We'll plan out as many sprints as possible at the beginning of the project. However, the first couple of sprints are planned in more detail, and are more accurate.

After the stories are added to the sprint they are assigned to each developer on the team by the project manager, based on the number of hours available in the sprint and the number of hours estimated for each story.


Active Development

Once pre-development planning is complete, we begin active development, which includes completing two-week sprints, and launching version releases based on the scheduled project milestones.

Sprint Execution

Developers are assigned a number of stories for each two week sprint. Each story is assigned an estimated number of hours to complete, and the combined estimated hours equals the number of hours available in the sprint. Each story includes a description of what to build, links to required assets like components and icons, and acceptance criteria.

Test Coverage

As the developers complete stories, they build automated unit tests and integration tests. Test coverage is important as it alerts developers when something breaks as new code is introduced. Without test coverage, each time new code is added the entire application will need to be manually tested to determine if the new code broke the old code. This is time consuming, costly, and ineffective.

Some developers skip testing early on to save time and go fast, but this is costly in the long run. All of our apps are built with robust end-to-end test suites from day one, which saves time and money in the long run.

Unit Testing

Unit testing tests the smallest testable part of an application to validate that each unit of software performs as designed.

Integration Testing

Integration testing is a type of testing that combines individual unit tests and tests them as a group. The purpose of this test is to discover faults in the interactions between integrated units.

Continuos Integration

Continuous integration testing is a development practice that requires developers to integrate their code to a shared code repository several times per day, where it can be verified using an automated build process and an automated test suite.

Quality Assurance

Once developers complete a story and build unit and integration tests, the story is then ready for review by Quality Assurance (QA). If the story passes QA it's then sent to the Project Manager for further review. If it fails QA it's sent back to the developer for revision. Quality Assurance checks for a number of factors, including:

  • Does the code meet the acceptance criteria outlined in the task description or story?
  • Does the user interface match the designs?
  • Does the code work as expected on multiple types of devices and browsers?
  • Is it mobile responsive across a larger number of form factors?

Code Review and Approval

Once the story passes QA it's sent to the project manager who reviews the actual code to endure a high level of code quality and tests the code / feature one final time. If everything looks good, the PM merges the code with master, and the story is complete.

The quality of all of the code we write is judged against our code quality standards. At Divisio, we write good code and this is what good code means:


The easiest way to keep code clean and understandable is to be concise. Less code means less complexity, less chances for bugs, less code to maintain. Keep it short and simple.

By Humans to Humans

You can read clean code in plain english. Directories should be structured according to the best practices of each language/framework. Filenames, classes, functions/methods, variables and parameters should be named explicitly and with context and intent in mind.


Code should always be run with and automated linter. If your project is not setup to run automatically with CI or with git hooks, you need to set that up as soon as you can.

Self Documenting

Comments are reserved for situations that you cannot properly convey the intent and functionality of a method or class with naming and clean code. Notice that this should be a very rare situation. You can almost always refactor and use thoughtful naming to convey enough context and intent to your code.

Test Coverage

An automated test suite must be green prior to merging a branch to master. It must be setup as soon as possible, as the project should always have end-to-end, integration and unit tests and achieve a 95% coverage level for each project.


At the end of each sprint the team meets for the sprint retrospective, where they determine and discuss if the sprint was completed on time, if the stories were properly estimated, if there were any unforeseen blockers or challenges that popped up, if the project as a whole is on track.

The feedback from each retrospective informs the plan for the next sprint. We track sprint completion by developer over time to ensure that developers are hitting their sprints consistently. In the rare event a developer consistently fails to complete sprints on time, the project manager works with them to identify and create a performance improvement plan, then measures improvement against the plan going forward.


Version Releases

As sprints are completed, they roll up into version releases which include a limited number of completed features that are ready for User Acceptance Testing (UAT) by the client. Clients are able to test the version releases and provide feedback to the development team.

Version Releases


Once all version releases have been completed and accepted by the client, and the app is ready for beta testing, and eventually, a public or internal release.



  • Step 1
  • Step 2
    Ongoing Development


Once the application is published we can provide ongoing support via a maintenance agreement and / or ongoing active development agreements.

Maintenance Agreements

For applications with limited planned future development, a maintenance agreement is all that's required to keep the app running well. Maintenance agreements cover the following:

Error Monitoring & Bug Reporting

We use several third-party tools for error monitoring and bug reporting, including Eslint, CodeClimate, Sentry, and Bugsnag. These tools alert us when something goes wrong, and help optimize performance.

Update Versions

Open-Source software languages are constantly updated by the open-source community. It's important to keep versions up-to-date, to ensure performance and security. All of our maintenance agreements include updating versions as a standard deliverable.

Performance Optimization

For applications that manage large amounts of data or which have large numbers of users, ongoing performance optimization may be required. This can include monitoring and optimizing servers, load testing and optimization, crash reporting and response, etc.

Update Integrations & Dependencies

Modern applications are built with a variety of third-party dependencies and API's, but these dependencies and API's can change over time. So an important part of our maintenance agreements is updating applications to ensure they continue integrate properly with third-party dependencies.


Ongoing Development

For clients who wish to continue adding features and making changes over time, an ongoing development agreement will be needed, in addition to a maintenance agreement. Ongoing development agreements include the following:

Product Roadmaps

We'll work with your team to create a robust product roadmap that outlines which new features will be built, and when. This helps prioritize features, plan budgets, etc.

Design New Features

After new features are added to the product roadmap, we'll complete a short design process to demonstrate the new feature and how it will operate within the existing application.

Develop New Features

Once design is complete, we'll estimate how much time will be required to develop the feature, then will add it to an upcoming sprint to be completed.

How we work

Here’s the tools and strategies we use to deliver
the best experience.


We create a Slack channel and everyone on your team and ours joins the channel. You have direct access to everyone on our team, including developers. Daily standups to review what was completed the previous day and what will be done that day. Find and overcome blockers. Weekly Client Check-In.

Project Management

We create Epics, Stories & Sprints using JIRA, a powerful project management tool that help us visualize the progress in a organized way while maximizing efficiency.

Hours Reporting

We track and report our billable time with crystal-clear transparency. Our entire team tracks their time using Toggl which tracks time down to the second, and you are only billed for the time we are actually working on your project. No rounding hours, no block billing, and visibility into each time entry.

Client Meetings

We conduct weekly client check-in meetings each week for each project. The purpose of this meeting is for the Project Manager to update the client on how things are going each week, and review things like sprint completion, hours worked vs the estimate, budget, timelines, and milestones.

Let's get in touch

We’d love to learn more about your project. Contact us below for a free consultation with our CEO. Projects start at $15,000.

Type of Project

What do you want?

How did you hear about us?