Pricing Guide
How much will it cost to build your MVP?
How much will it cost to build your MVP? Ask ten different web development firms, and you'll get ten different answers.
The path to shipping software is not always straight and narrow. Recognizing this, we've put together a pricing guide that we hope will not only help you to plan your expenses, but also help you to reduce the risk that's naturally involved in selecting a company to develop your Minimum Viable Product (MVP).
This is a make or break moment. Your product is the heart of your business. Getting your MVP right the first time means the difference between success and, well… having to start over.
All that translates into high risk for you. Just at a moment when you need to reduce risk as much as possible.
Our job is to reduce your risk. One of the ways we do this is by structuring our pricing around our Lean methodology. In practical terms, what this means is that we work in a series of sprints (more on that below), and each sprint is billed separately. This gives you a tremendous amount of control over your spending and the velocity of your project.
Sprint: The Basic Unit of Work
Through our iterative approach, your project is broken down into many smaller units that we call Sprints. A Sprint is a short period of intense work with a specific goal and a strict timeline. Your project will be billed and completed as a series of Sprints.
Each Sprint results in working software that you can actually use, test, and ship to early adopters. The goal of each Sprint is to put new features into the hands of users in as short a time as possible, to test those features, and then to use feedback that you gather to inform the next Sprint.
Sprints are usually two-weeks in length. We kick off each Sprint with a planning meeting, followed by a period of intense work. We then pause for review, process any necessary revisions, and then celebrate a mini-launch.
You are an integral part of the process
We do not just take your project spec and hide away like mad inventors while we build your app, then emerge weeks or months later in a puff of glory.
Instead, you are a critical and integral part of the process. This is your app, after all. You guide the creation of the Flight Plan, you help us define the Critical Path, you communicate with your early adopters and collect their feedback.
We’ll meet with you many times over the course of your project and during each Sprint. At the beginning of each Sprint, we’ll have a Kickoff meeting. The objective of the Kickoff meeting is to agree on exactly which feature or features will be built during this Sprint, and what the expected outcome will be. Then, during the Sprint we’ll meet with you daily for a very brief, 15-minute “Scrum”, where we share progress and talk about any needs that we have or issues that are blocking progress. Finally, on the last day of the Sprint we deploy your project to a staging environment and meet with you again to go over what has been done, discuss next steps, and talk about user tests and experiments that can be run to validate our work and inform the next Sprint.
Launch Early, Launch Often
Our goal is to help you launch your project as quickly as possible, and to give you control over your costs. That’s why we’ve modeled our process on Lean Startup and Agile methodologies.
You can push hard and fast, one Sprint after another, or you can take time between Sprints to test, learn, and iterate on your business idea. The pace is completely up to you.
Booster Stage pricing is clear and straightforward. Each sprint is billed separately and results in working software that you can use and test.
- No monolithic project estimates.
- No estimate padding.
- No never-ending projects.
- No ambiguous pricing.
- No hourly billing.
Forest for the trees
One of the tricky things about software estimates is that it's sometimes difficult to see the forest for the trees. It's easy to get caught up in the details of how we're going to build that big beautiful app that you have in your head, and forget that first and foremost, your app has to be viable. What do we mean by viable?
- Your app must solve a real or perceived problem for someone.
- You must be able to reach that someone with your product.
- They must be willing to pay for it.
Just completing your project according to spec is not enough. These three conditions must be met for your app to succeed.
Is your project a whale?
Have you gotten a whale of a project estimate from another firm? Chances are your project actually is bigger than you might think.
There is a positive correlation between the length of your project and your risk. The longer your project takes to get in front of real users, the higher your risk. This is because, no matter how awesome your software looks, no matter how easy is it to use, until it’s introduced to real users in the real world (and they decide to pay for it), we can’t be sure that it solves a real problem for your end user. The only way to know that for sure is to ask users to pay. The quickest way to answer this question is through our Iterative Development approach.
Our promise to you
No monolithic project estimates.
Instead of putting together a gigantic "statement of work" and trying to anticipate every single detail ahead of time, we create a more general "Flight Plan". The Flight Plan is a guide and outline that describes your project and its major features at a high level. This gives us a good sense of how many individual sprints your project may take to complete. However, each sprint is billed individually. This gives us the ability to pivot if we need to, as we are not locked into a gigantic specification document that may become obsolete as soon as we introduce customers to your product.
No estimate padding.
We never pad our estimates. Because each Sprint is a distinct unit of work, we don’t have to. Padding estimates is literally planning for failure. Padding means that we’re just taking a wild guess as to how long something will take, and we’re adding 50% or more time just in case the guess is wildly wrong. If your project ends up taking longer than expected (as most projects tend to), it’s OK. On the other hand, if you decide to scale back the scope of the project based on user feedback (for example, if we planned to create features A, B, and C, but user testing revealed that users are willing to pay for features A and B, but don’t really care about C), you’re not locked into the scope of work. You have the flexibility to pivot to respond to user feedback.
No ambiguous pricing.
Where does that number really come from? Is it an hourly rate multiplied by some number? How accurate is the estimate? Can the hourly rate be negotiated? Can we just do this hourly and see how it goes? Our Sprint-based pricing makes all these questions go away. Each Sprint is billed separately and you know exactly what you are paying for before we start.
No hourly billing.
Nothing against hourly billing per se. Though it can seem attractive because it gives you some control over your expenses, we’ll let you in on a little secret: hourly billing is actually not favorable to you, the client. Hourly billing disincentivizes rapid development. It does this because there is no penalty for taking too long on a particular task. Sprint-based billing, on the other hand, is favorable to both sides: it provides you with a fixed budget and a clearly-defined deliverable, and it allows us to structure our time to accomplish a task that is fixed in scope.
You are in the Pilot’s Seat
Our goal is to pull that beautiful vision out of your head and make it real. But this is your project. It’s your brainchild, your invention, your inspiration. Our iterative Sprint-based approach puts you in control of your project. You control the pace: you can push fast, doing one Sprint after another. Or you can slow down and conduct more extensive user testing to gather and apply feedback between Sprints. Data that you gather from users is fed back into our process and helps you to decide to pivot or double-down.
