Price per Phase, Not per Project

– How Software Pricing Works

Introduction

You’ve been sitting on a great Startup idea for months decided to pursue it. You’ve done your homework, talked to potential users/customers to validate the product and now you want to get it built. You approach a number of companies to build the software. Some of the companies provide good advice in initial conversations and they really seem enthusiastic about the idea. You narrow your list to two or three development houses that you like. “So how much will it cost to build?”

Each company provides a proposal and quotes for the project. You select the one that best fits your budget. A few months down the line, you’ve been building the hype and meeting prospective users/customers/partners in preparation for your launch date, but go-live is still on the horizon. Worse still, new information has come in through your research so you’ve had to ask for additional features not in the original project plan. You’re over budget and the product experience is lacking somehow, which you’re not quite happy with.  What went wrong?

At Enhance we believe that phasing your project by breaking it down into specific bi-weekly or monthly targets at a flat rate per period is a better way to build software.  Here’s why:

You Don’t Really Know What You Need

Jeff Bezos, Founder of Amazon, “said people who were right a lot of the time were people who often changed their minds” – source

No good startup knows exactly what their business or product will look like 6 months or two years’ down the line. Over the course of development new information will come in or condi-tions will change. In the beginning of every project there is a discovery phase, but this does not mean that discovery stops once you are into design and build! It is impossible to account for everything in the early stages. But if you decide you need a fixed price then this means a fixed scope, which means consciously ignoring new information until the product is built. This is not an option for most startups, whose primary advantage over established competition is usually their ability to adapt to change.

Help Us Help You

Good software development teams are multi-disciplinary, which means team members per-form different roles & functions on the project. Each team member should have years of experience working with an array of different industries and can provide valuable guidance and in-sight throughout the project. Unfortunately, given a fixed scope/fixed price, experienced development teams have little incentive to suggest improvements after the discovery phase.

This is because new ideas might create extra work not account for in the original price or worse, cause a dispute about what is in scope & out of scope. In scope/out of scope discussions can lead to conflict between client and agency, so should be avoided as much as possible.

In a phased build where flexibility is valued there is typically a 30% variation in scope – meaning what we think we will build is different to what we actually build. This is really important, and suggests an iterative approach in which the application are built in a cyclical fashion, piece-by-piece.
As in the diagram (right), discovery leads to design, to development, to delivery. Feedback is gathered on the delivered product, which is integral to the discovery phase of the next cycle. This process produces great software products and web applications.

Developing an application like this inevitably means throwing out some features that were in the original scope but now seem a waste of resources. It will also mean introducing or bringing forward critical tasks that were either not prioritised or not considered at all at the beginning.

In the end, everyone will be happier with a better product, but the development team need you to buy-in and commit to the process. So help us help you!

Put Your Best Foot Forward and Prioritise

Many of us are perfectionists and founders often believe they need to launch a complete product. The first point to make is that there is no such thing as a complete product, good software is continuously developed throughout its life, until it is decommissioned or made redundant.

In the past software was built in a waterfall process, in which every aspect of the application was mapped out in detail before anything went to build. This meant that software was rarely delivered on-time or on-budget. Worse than this, much resources were spent developing features and functionality that became irrelevant. Real users will give you data on how people are using the service and what features to prioritise.

“The biggest mistake I see is companies waiting too long to release the product. It’s easy to let the scope of what you’re building get out of hand. But equally importantly most startups build much more than they truly need to, but this is often only realized in hindsight. Whether your product is working or not, looking back it’s easy to see that you only really needed to build a small fraction of the stuff you built. Most features/options/buttons/settings/etc. simply aren’t crucial to success or failure, and for an early stage startup that means they were wastes of time — you could have done 10x more with that same amount of time and resources.” — Jona-than Wegener, Founder, Timehop and ExitStrategy

Select the highest priority features, build and release it to the public at the first opportunity. During the second phase gather feedback on market traction and user-activity to inform the third iteration. Each iteration of the build should run in tandem with your market research, which should continue to provide direction for your development plan. This will mean you only build the most important features to your users/customers at any given time and you don’t waste resources unnecessarily.

Nobody is Good at Software Estimates

Seriously! Software estimates are notoriously difficult due to the number of variables involved, whether that be in the team, the technology or pressure from the product owner/market envi-ronment, etc… Added to the fact that there are many interpretations of the word “done”, de-velopment teams can increase or decrease the amount of time spent on a task to the amount of time they are given. For example, spending an extra week working on architectural concerns early on can provide a more solid foundation that saves weeks or months of work down the line, and given a tight deadline can force developers to cut corners on issues like security or user experience while still technically fulfilling the brief (clients rarely mention security or user experience in a brief and it is impossible to be completely explicit about this means.)

Once you get a live product to play with, even a basic version, you can get a feel for the user experience and what the development team calls “complete”. You can also use these initial it-erations to make improved estimates on the pace of development and time frames. These es-timates won’t be completely accurate, but they are likely to be better than a month previously. Without delivering a product iteratively it is almost impossible to improve your estimates over time and therefore your estimates will be as bad in 3 months as they were in the beginning.

Be Very Careful with In Scope / Out of Scope Conversations

One man’s “bug” is another man’s “feature” – unfortunately what is deemed complete is very subjective. No matter how detailed the brief, there will always remain relatively innocuous pieces of the application that are not explicitly mentioned. Faced with a tight deadline and a narrowing profit margin for the agency, the developer may leave out important features not mentioned in the brief. There is usually no way of definitively confirming that these features are in scope or out of scope but most of the power is in the hands of the development team. By delivering a product early you get a feel for what is termed “in scope” and “out of scope” early and can avoid unnecessary conflict.

It’s Cheaper

An agency can bid high or bid low for your project. Bidding high means covering themselves in case additional features are required, which avoids the “in scope/out of scope” conversations but the client ends up paying over the odds. Bidding low means under-cutting the competition by lowering the quality of development. A company that bids low will say “out of scope” to any-thing not explicitly requested, otherwise they can’t make money. Features not included in the original specification might turn out to be critical once tested with real users and are retro-spectively bolted onto a badly architected system ad hoc. This can result in significant problems and additional costs for “fire-fighting” down the line.
Building in stages is therefore more efficient and less expensive in the long run.

Plan, Assess, Plan…

A short-term deadline, working towards a soft-launch date, is much easier to manage and stick to than a long-term deadline. Maintaining a consistency of delivery through iterations allows you, the entrepreneur, to make more concrete decisions with fewer variables. Your market re-search becomes more efficient because you can focus in on what the development team need to know for the next iteration and only this.

Fund-raising is easier because you can show potential investors a tangible product immediate-ly. Customer acquisition is easier because you can break down your users into categories and demographics and slowly build out your community throughout the development process ra-ther than launching the entire product in one go. Technical support is also much easier to pro-vide & manage if it is spread over iterations than condensed into a single launch date.

The underlying concern here is that phasing your build and getting prices for monthly iterations requires trust and cooperation on both sides to make life easier for the agency and produce a better product for you. But this is by far the most successful approach to software development projects you can take.

To get the best advice on how to develop your new startup idea email Ciaran@Enhance.ie or call (01) 851 2800.