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.
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.
Our UX design process ensures that we are solving user's needs efficiently, and creating an application that is easy to use and understand.
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.
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.
This section describes our design and prototyping process, so that you know what to expect.
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.
The lead developer on the project. Responsible for leading development efforts, including architecting the application, making critical technical decisions, writing a significant amount of the code, and managing the additional developers on the team.
Responsibilities include coding the application, taking direction from the Lead Developer, estimating their portion of sprints, executing on FullStack’s development process, and interfacing with Client when needed.
The project manager is the primary manager for the project and the primary point of contact with the client. Responsibilities include planning sprints, assigning stories to developers, reviewing sprints, measuring productivity, building estimates, managing changes, etc.
Review completed stories to determine if they meet acceptance criteria, ensure user interface matches original designs, test for device and browser compatibility, etc.
Responsible for planning and creating the user interface and user experience of the application prior to development, and designing changes during development.
Senior leader within FullStack Labs who is responsible for the overall success of the project. Checks in with project manager each week to ensure the project is on track. Critical issues are escalated to the product owner when required.
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 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 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.
After the public release the app moves to either maintenance mode or continued development.
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.
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.
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:
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.
Engagements start at $50,000.