Insights Blog| Business| Product Development| Remote Work Fixed price contract vs Agile for product development
Blog
|
Business
|
Product Development
|
Remote Work
Oct 8, 2021

Fixed price contract vs Agile for product development

AUTHOR

James Wondrasek James Wondrasek

Software is expensive to build. Throwing around the kind of money it costs to build a new product — whether it’s an app or web site — should make you nervous.

And if you’re not familiar with software development, starting down the product path might feel like you’re rolling the dice and hoping for an eleven.


If that captures how you feel, then this article is here to show you that you do have control. Success is never guaranteed, but there are processes and strategies that enable you to move systematically towards the best outcome. Any decent development partner will have these in place.

“Insert cash, get app” is the wrong model

Commissioning a new product is not a transaction. It’s the start of (cue cliché) a journey. It’s going to change your business. You’ll need to onboard new responsibilities. You might need to create new roles.

The first step in taking control is to look at your future product as an investment in a long term process. This opens up opportunities to move your product forward based on new cash flows it will bring in. Which brings us to the biggest decision you’re going to make, and one that our team at SoftwareSeni has strong opinions on.

Fixed price vs Agile

Some people will not give up the “Insert cash, get app” model. This model’s real name is “Fixed price contract” and it drags software development back to the 70s when the Waterfall Methodology was the only option.

Don’t go commissioning waterfalls

For a fixed price contract to avoid cost overruns you need to first scope and price every single thing that needs to be done. This feat of excessive documentation is the start of the Waterfall Methodology. It’s followed by first doing A as described in the documentation, then B, and years later you might be up to L. Forget about Z.

No matter how much documentation is done, scoping and defining a complex project in advance will never get everything right. Issues, oversights, and moving targets will only show up once the project is underway. This inevitability requires budgets to be drawn up that will cover contingency costs. These can increase the final cost by anywhere from 20% to 100%.

That’s right. Your software developer, even SoftwareSeni, will add 20% to 100% to a fixed price contract to protect themselves. And you. You don’t want your software developer going out of business just before your product is finished, do you?

It gets worse. Creating all that documentation delays the start of development. Then there are more delays as developers meet the documentation for the first time and try to understand it. This is slow. It gives the project plenty of time to shift out of sync with the business and the market.

Changing course, which will happen for the reasons given above, requires making changes to the fixed cost plan. Which means more documentation and more time and more billable hours taken to price out the cost variations to catch up with the status quo. And another 20% – 100% on top. It’s a lot of money and none of it is being used to add value for the customers.

Move quickly, be Agile

At SoftwareSeni we find our clients get the best outcomes using an Agile methodology. If this is all new to you we suggest you read this quick introduction on Agile. When using the Agile methodology product development starts with a high level estimate based on an hourly rate.

The high level estimate

To arrive at a high level estimate, at SoftwareSeni we go through an initial review of the product with you. We look at proposed functionality, third party services it will interface with (such as payments, authentication, booking and inventory systems, CRM, etc), admin requirements, and more.

Out of this we can provide you with an initial estimated price range. It can be a wide range, with a 50% spread or even more. That’s why the next step is to tighten that range, but at this point it’s your first opportunity to commit to the project or delay it.

Narrowing the range

The next step is the scoping stage. Even with Agile you cannot escape some documentation. But in Agile we document to understand rather than to determine implementation.

In the scoping stage we work to capture all the key items the product needs. Depending on the complexity of the product this can cost $5k-$15k.

Take something universal like user accounts. How are users going to log in? Will social logins be allowed? Email and password? Both? Decisions like this will have design and technical impacts.

From feature decisions like this we build a high level overview of the product and the project to build it.

The output from this stage is a set of wireframes. They look like cartoon versions of the product, but they document visually the features of the product and how they will interact. They are really a visual documentation of the requirements. They are much easier to understand and to grasp than a shelf of ring-binders full of written documentation.

From the features documented in the wireframes a tighter estimate is derived. Now comes the time where you decide how to allocate your budget.

Strategising your spend

With a more detailed estimate that breaks out the key costs, you can make decisions on which features to start with and which features to delay.

Under Agile and Lean Business methodology, these decisions are best made by focusing on achieving product-market fit. How do you know you have product-market fit? Users spend money on your product.

How do you get there? Iteration.

Iterate to focus your spend

Following Agile and Lean Business, you’re going to hit the market with an MVP — a Minimal Viable Product. This is the product that requires the least time and money to build but still delivers value to the users.

How do you know it delivers value before launch? You will have run user tests with your wireframes, or invested in a clickable prototype based on those wireframes. You won’t be launching blind into the marketplace.

But the market might not match your expectations. In fact, it probably won’t. But because you’re following Agile, you’re prepared for this. You watch the response to your launch and plan your next iteration.

That next iteration will be a new version of your product. Because you’re following Agile, it will go live in 2 to 4 weeks. It might have new features. It might be a tweak of the design. You will get more useful feedback to use in the next iteration.

By working with your development team you can direct your spend for each iteration, targeting resources at the areas that will deliver the highest returns.

If you do it right, if you find that product-market fit, revenue generated by your product will enable it to become self-supporting and fund its own subsequent iterations before you have burned through the initial estimate.

How do you know you’re finished?

After several iterations you will come to realise one of the truths about software based products — they are never finished.

You might stop adding features, but your product runs within, and is powered by, a complex network of services, code libraries, programming languages and technical standards. There is no escaping your product’s dependence on these. When they change, and they do, your product may need to be updated in order to keep working.

Keeping your product working, as well as keeping it available via hosting and monitoring, is an ongoing cost. When you include the costs of third party integrations, it may cost as much as 20% of your initial development budget per year to keep your product alive.

Agile for the win

The costs outlined above are the final reason why launching with an MVP and iterating as fast as you can to generate revenue, the Agile methodology, brings better outcomes than the Waterfall methodology aka Fixed Price Contract.

There is one place where a fixed price contract makes sense, but why would you want to go there? That place is when a category of product or app or web site is so well-established and well understood that there are white label solutions available. Those markets exist and they are saturated. Why launch into one of those?

Given that caveat, we would always advise you to choose the control, flexibility, and velocity of Agile methodology and pricing over fixed price contracts. Leave those to the businesses breaking into overcrowded markets, while you launch your new product into a market that’s still wide open.

If you’d like to take the first step in getting your app started, get in contact and we’ll get started on those estimates.

AUTHOR

James Wondrasek James Wondrasek

SHARE ARTICLE

Share
Copy Link

Related Article

Need a reliable team to help achieve your software goals?

Drop us a line! We'd love to discuss your project.

SYDNEY

55 Pyrmont Bridge Road
Pyrmont, NSW, 2009
Australia

+61 2-8123-0997

JAKARTA

Plaza Indonesia, 5th Level Unit E021AB
Jl. M.H. Thamrin Kav. 28-30
Jakarta 10350
Indonesia

+62 858-6514-9577

YOGYAKARTA

Unit A & B
Jl. Prof. Herman Yohanes No.1125, Terban, Gondokusuman, Yogyakarta,
Daerah Istimewa Yogyakarta 55223
Indonesia

+62 274-4539660