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

This is our Playbook.

Phase 1.


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.

mobile phone

Design Discovery

We begin the design phase with a discovery process to establish the goals and scope of your project to equip the team for success.

fsl team

The Kickoff Meeting

The first step of the discovery process is a kickoff meeting with our design team and your key stakeholders. Our clients all begin at different stages in the process, so we use this time to evaluate what has been done so far on your project and plan out a roadmap for designing the required features and functionality of your application.

User Personas

As a final step of design discovery, we'll create a series of user personas to gain an understanding of the different types of potential users of the application, what motivates them, and what goals they would like to achieve when using the app.

Step 2.

Technical Discovery

Many of our projects start with a multi-part technical discovery engagement to either understand and document your existing software stack or research and recommend the right technologies and architecture for your project.

This technical discovery can include conducting an in-depth code review on your existing application, researching technology options for your specific use case, reviewing documentation for third-party integrations, creating a DevOps strategy, and more. 

continue reading
Step 3.

User Experience Design

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

feature map

Feature Map

To start, we create a feature map - a high level view of the features of your application. It serves as a starting point for closer examination of how the views will interact, and is maintained and updated throughout the life of the project.

User Flow

Next, we'll build User Flows to demonstrate the steps users will take to achieve specific goals. User Flows become especially important when dealing with complex conditional workflows. It allows clients, designers, and developers to share a mutual understanding of how features will work and what feature outcomes will be.

user flow


As a final step, we'll create wireframes of the primary views of the application. Wireframing allows us to create the general layout of the screen without having to decide on the exact text 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
Step 4.

User Interface Design

Once Discovery and UX Design are complete, we move to visual design, first by iterating on and selecting a style concept, then turning the selected concept into a style guide, and as a final step, creating 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 generally create two or three style concepts for you to choose from, each with its own unique look and feel. Prior to creating the concepts we review your competitors products and determine how we'll differentiate your product from theirs. We combine these findings with your existing brand guidelines to create the style concepts.

Style Guide

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

Our design team can work within your brand’s existing style guide, consolidate your existing styles, or build a new brand for you from scratch

High Fidelity Mockups

High Fidelity Mockups serve as a 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. These serve as an accurate depiction of how the app will look when it launches.

At this phase, it can be helpful to show the designs to others in your team to get their feedback so that necessary changes can be made right away.

Step 5.

Prototype & Estimation

Once the high-fidelity designs are complete, we upload them to Invision or Figma to create a clickable prototype, which we then use to build a development estimate.

High Fidelity Clickable Prototype(s)

Clickable prototypes allow our team and yours to interact with the designs and truly understand how the app will function once built. This allows us all to test the application prior to development, and discover edge cases and improvements which would have otherwise been missed. It also improves the accuracy of our estimates, and can be a great tool for getting budgetary approval for the development of the application, or for pitching investors.


Development Estimate

Our comprehensive design process and the clickable prototype help everyone involved fully understand what will be built, which in turn 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 is so important.

Development Proposal

The Development Proposal outlines the proposed cost to build, development team, and timeline. If your project warrants it, we may also include a plan for phasing out the releases with the expected cost and timeline of each release.

Phase 2.


This is our development playbook. It outlines our methodical, scientific approach to building iOS, Android, and web apps. It's a reflection of all the things we've learned on over 500+ completed projects.

This section describes our development process, so that you know what to expect.

mobile phone
Step 1.

Pre-Development Planning

To ensure a smooth, effective, and efficient development process, we must first do some pre-development planning to properly prepare. This involves assembling the development team, completing a design to development handoff, establishing project milestones, creating stories, and planning sprints.

Assemble the Team

A typical development team includes six professionals: two full-time senior developers, one part-time project manager, one part-time quality assurance professional, one part-time designer, and a product owner. Our teams usually consist of a mix of professionals across our development centres. This blended approach combines the quality and convenience of an onshore team with the cost savings of a nearshore team, and has proven highly effective, and very popular with clients.

lead dev
Senior Lead Dev
Leads Development Efforts

lead dev
Project Manager
Primary Point of Contact

lead dev
Quality Assurance
Ensures Acceptance Criteria is Met

lead dev
Provides Ongoing Design Support

lead dev
Provides Ongoing Design Support

lead dev
FSL Product Owner
Responsible for Project Success

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 from the design team to the development team ensures that developers fully understand the application and have what they need to build it. Prior to development beginning, the design team meets with the developers and reviews everything that was created during the design phase, including the market research summary, user personas, user stories, user flow map, style guide, high fidelity designs, and the clickable 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.


Establish Milestones

As a next step, the project manager establishes the key milestones for the project, which we call version releases. Instead of just having one deadline at the end of the project, we have several version releases along the way that each include a limited version of the app with a limited number of working features for the client 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 needs.


Create Stories

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, and include acceptance criteria, which indicates how the feature should perform in order for it to be accepted by QA. The stories are generated 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, and include acceptance criteria, which indicates how the feature should perform in order for it to be accepted by QA. The stories are generated based on the designs and the individual line items from the original estimate, and each story is assigned a number of hours to complete, which ties back to the estimate.based on the designs and the individual line items from the original estimate, and each story is assigned a number of hours to complete, which ties back 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, for each sprint.


Sprint Planning

Once the stories have been created, they are bucketed into two week sprints. We try to 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, then sprints planned later in the development timelines.

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.

Step 2.

Active Development

Once pre-development planning is complete, it's time to begin active development, which includes completing two week sprints, conducting retrospectives at the end of each sprint, and launching version releases based on the scheduled project milestones.

Sprint Execution Begins

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 into the code. 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

Unit testing tests code at the unit level (the smallest testable part of an application). The purpose is to validate that each unit of software performs as designed.

unit testing
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.

unit testing
Continuous 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. 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:

qa icon
Does the code meet the acceptance criteria outlined in the story?
qa icon
Does the user interface match the designs?
qa icon
Does the code work properly on multiple types of devices and browsers?
qa icon
Is it mobile responsive across a larger number of form factors?

Code Review &

review icon

Merge to Master

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 lead developer 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 Software Co, we write clean code. This is what that means in practice:


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.

Obvious to Other Programmers

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.

Linting / Code Formatting

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.


Writing clean code the first time through is very difficult. Prior to committing (and after you have written your tests to cover the functionality you just completed) you should spend some time refactoring your code.

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

Code should always have an automated test suite that must be green prior to merging a branch to master. If your project does not have one you should set this up as soon as possible. You should have e2e, integration and unit tests and achieve a 95% coverage level for each project.

Sprint Retrospective

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 vs the estimate, and if FullStack's process is being followed properly.

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.

constant improvement Constant Improvement

Version Releases

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

version release
version release
version release
version release
Step 3.


Eventually all of the 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.

After the public release the app moves to either maintenance mode or continued development.

version release
Phase 3.


Once the application goes live 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 CodeClimate, Eslint, 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. Each update is called a "version". It's important to keep versions up-to-date, to ensure performance, security, etc. So 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.



Wonder how we make this process work? Here’s the tactics and tools we use.



We create a Slack channel..everyone on your team and ours joins the channel. You have direct access to everyone on our team...not just the PM. 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.

Hours Reporting

We track and report our billable time with unparallelled 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.

Other consultancies bill on a weekly or monthly basis, and don’t guarantee a set number of hours or try to hide it. They will say a PM is full time, but you don't really know how many hours they are putting in. This should be taken into account when comparing hourly rates or monthly rates.

Toggle entries are documented with the Jira identifier which allows you to see how much time is billed toward each jira story, each feature, each version, and the entire project.

We also provide daily reports showing the work logged in the previous day alongside month-to-date and year-to-date totals. Each month, a detailed report is attached to the invoice for your review.

Weekly 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.

Engagement Opportunities

This playbook focuses primarily on development of a new "greenfield" application. However, building new apps isn't the
only thing we do. We offer a variety of engagement opportunities to clients, including:


New Apps

    • Technical Discovery & Estimation
    • UX/UI Design & Prototyping
    • Custom Development
    • Maintenance Agreements


    • Technical Discovery & Estimation
    • UX/UI Design & Prototyping
    • Custom Development
    • Maintenance Agreements

Staff Augmentation

    • Technical Discovery & Estimation
    • UX/UI Design & Prototyping
    • Custom Development
    • Maintenance Agreements

    Let’s talk.

    Note: We’ll keep your idea confidential with a signed NDA.