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.
We begin the design phase with a discovery process to establish the goals and scope of your project to equip the team for success.
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.
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.
Our UX design process ensures that we are solving user's needs efficiently, and creating an application that is easy to use and understand.
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.
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:
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 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.
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 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.
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.
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.
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.
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.
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 100+ completed projects.
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.
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 Colombia and USA offices. 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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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:
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 FullStack Labs, 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.
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.
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.
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.
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.
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.
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.
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.
Once the application goes live we can provide ongoing support via a maintenance agreement and / or ongoing active development 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:
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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:
Technical Discovery & Estimation
UX/UI Design & Prototyping
Ongoing Dev. of Existing Apps
Parallel Design & Development
We'll add as many developers, project managers, quality assurance professionals, and designers to your team as needed, to help you level up your team's skills and go faster.
We’d love to learn more about your project. Contact us below for a free consultation with our CEO.
Projects Start at $25,000.
An interpreted high-level programming language great for general purpose programming.
A server side programming language known for its ease of use and speed of development.
View a sampling of our work implemented using a variety of our favorite technologies.
View projects implemented using this high-level programming language great for general purpose programming.
View projects implemented using this framework that allows rapid development of native Android and IOS apps.
View projects implemented using this server side programming language known for its ease of use and speed of development.
Learn more about our current job openings and benefits of working at FSL.
Detailed reviews and feedback from past and current clients.
Detailed profiles for each member of our team.
Our step-by-step process for designing and developing new applications.
Get answers to the questions most frequently asked by new clients.
Learn more about FullStack Lab’s Mission, Vision, & Company Values.
A high level overview of FullStack Labs, who we are, and what we do.