Ideally, software should cost less than the value it creates. For an established product, we may be able to easily calculate the ROI and determine how much is worth investing in it. But when we're expanding our market or don't have one yet, the risk of failure is often higher. We typically serve these types of projects in our Studio Model, where we take a different approach in order to reduce risks and contribute to the project's success.

We follow agile practices to break up large projects into small bits of functionality (called user stories). Software development companies typically proceed to estimate these and bill per hour of work, but in our Studio model we bill per feature instead.

For example, let's say we're decorating empty rooms and spaces in your house. We'd bill for each finished room, so if your budget runs out you'd still have completed, functional spaces you can use. Once you're ready to keep improving your house, we can incorporate the new ideas you bring, or pick up where we left off. In the Studio model we bill per feature, so you'll always have a working product (even if your budget runs out).

Fixed Cost: Project vs. Features

Fixed cost projects sound attractive to clients: they hand out a list of requirements and in return receive a quote for the whole project. But the problem is that requirements change. This to-do list is just a big picture, and we can't see the lower-level details until we start implementing each piece of functionality. It is until that point when questions arise, or we find better alternatives, or discover some features shouldn't be built. On a fixed cost project, it's very difficult to respond to change because the contract doesn't allow it. Developers are trying to stick to the specs, and both parties start working against each other instead of collaborating to create the best product possible.

On the other hand, agile practices establish feedback as a vital part of the development cycle. We embrace it, and prepare for change. This flexibility typically leads software teams to charge per hour, but there's no guarantee the budget will be enough to complete any features. This is safe for developers but becomes a risk for stakeholders.

Paying per feature has the best of both worlds: stakeholders own the business risk, and developers own the execution risk. The product gets built incrementally, so the development team is not affected by scope changes. They commit to deliver features and are held accountable for their estimates in the short term.

Instead of billing per hour:

• Teams create and estimate user stories for the near future
• The client chooses which features will get built next, and they know the cost beforehand
• If the estimates are wrong, the development team absorbs the difference in cost and delivers the work for the iteration
• Rinse and repeat

We consider the optimistic, realistic, and pessimistic scenarios when we estimate stories to help us mitigate any risks. We've successfully served dozens of projects with this model. This is not a silver bullet to ensure success (there's no such thing), but it helps us predict the development rhythm and costs with more accuracy than other alternatives, and our clients can make informed decisions of how to best spend their budget.