icon picker
Evolve Plan

Basis Labs


Fast, high quality development for clients who want to ship quickly, learn fast and deliver products that make a mark in their industry.

Helpful terminology

Before we embark on this crazy journey we call “App Development”, it would be helpful to establish a shared dictionary of somewhat jargony yet useful words:
Sprint: A time-blocked period of work in which we tackle as many of our planned features as possible. We work with you to prioritise and scope the features before each sprint.
Scope: Encapsulates the sometimes unpredicatable and creative process of accessing a new feature request before outlining its requirements and giving a rough estimate for how long it will take to complete.
Backlog: Where all tasks live before they are assigned to a sprint. If a sprint is a nightclub, then the backlog is the line of people shivering in the cold (but super eager to come in and dance!)
Feature: This could represent some new functionality or improvement to the app, or more of a behind-the-scenes update to improve performance, security, or reliability moving forward. At its core, this is simply some change that’s going to happen to the application.


Picking a plan

Everything we do happens in a sprint, and a sprint is always three weeks long with one week reserved at the end for light feedback and planning of the next sprint.
Before we start work you’ll decide how much developer capacity you want to reserve within the next sprint. This works just like your mobile data plan: you get a certain amount of capacity to use on whatever you want. Of course, some things use up more capacity and some less. How much capacity is appropriate is something we can help you with but ultimately it boils down to how many features you want to prioritise getting done in the next three weeks. Below you can see an outline of your capacity options.
Plan options
Not synced yet
Two days
Good for occasional small tweaks, fixes, and small feature additions.
Four days
One or two solid new features.
Eight days
A big, complex new feature, or several medium ones.
Sixteen days
Close to a full time effort.
Not currently available
There are no rows in this table
We use credits to track the amount of work each feature takes; this is the equivalent of a megabyte in your mobile data plan. You can get a feel for how credits map to work below:
Estimate levels
Rough time reference
Tasks Example


0 - 1 credits
30min or less
Add a new category filter to a list of properties


1 - 3 credits
30min - 1.5 hours
Create a new table view for a list of transactions using pre-existing UI


3 - 6 credits
1.5 - Half a day
Create a sign up/login page using pre-existing UI


6 - 12 credits
Half - Full day
Setup credit card payments with the Stripe API


12 - 24 credits
1-2 days
Implement a reviews system, with email reminders and the ability to add and view reviews for booked properties


24 - 48 credits
2-4 days
Add bookable 'Experiences' feature, with support for creating experiences, searching for experiences and booking experiences
There are no rows in this table

Planning a sprint

Planning each sprint happens in three distinct steps:
You’ll add all the features and updates you want done to the Backlog
We’ll then give an estimate for how many credits we think each one will take. We might ask some clarifying questions. We’ll include the uncertainty and risk in our estimate.
Finally, we’ll have a conversation with you about what takes priority. This is just a triaging of the tasks where we decide that adding in that new commenting feature and connecting with your CRM are must haves for this sprint, while adding in that new admin view can wait till the next sprint.
We’ll give estimates using T-Shirt sizing (see above). The idea of this is to develop a shorthand way of talking about task complexity. Over time it will become more intuitive, but we’ve given a rough time estimate and example of a feature in the table as well to help initially.
Please note that while we’ll always endeavour to make our estimates as accurate as we can, there is often unforeseen complexity and unknowns that make truly spot-on estimates nigh on impossible (if that wasn’t the case, a robot could do our job. Maybe one day....).
All that is to say, we may occasionally get features which take less or longer than our estimate, but as mentioned , we’ll do our best to communicate this timely and adjust our planning accordingly.

Running a sprint

Once the sprint starts we’ll tackle each feature, working our way through the queue and tracking the credits used so you can see the progress being made.
If it looks like we’re going to need more credits than we estimated, we’ll let you know as soon as we’re able. In this scenario, you can either:
Purchase bonus credits for use within the sprint.
Do nothing, in which case development will simply pause once we’ve exceeded our allowance, resuming once the next sprint starts. In this scenario we always re-arrange the queue to make most effective use of the remaining credits.
If we finish all features in the sprint with credits to spare, we’ll start working on tasks from the backlog. It’s worth noting that unused credits do not carry over to the next sprint. To reduce the chances of this happening (working as efficiently as possible!) we always want to have enough features in the backlog that we can pull into the sprint if we’re able.

After a sprint

A sprint is three weeks long followed by one week for light feedback and planning for the next sprint. We won’t be doing any real development here, but instead catching our breath, reviewing what we’ve built, and figuring out what to build next. We’re effectively re-doing the step, just for the subsequent sprint.

Changing your plan

We ask for a minimum of two weeks notice for any plan change; this includes starting a new plan, moving to new plan with more or less capacity, or cancelling a plan.

Plan billing

Payment for subsequent sprints is due two weeks from the sprint’s start date.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.