Software Quality and User Experience
One thing I hate about fixed-price work contracts, is that quality is usually the variable. Once timeframe, budget and features are agreed upon, only quality is left to be adjusted as the project moves along. That will always have the same result for the client: bad quality. In a fixed-price setup, contractors are incentivised to save their own time and money by reducing quality to the lowest possible value that will still see them paid and hired in the future. This is not a good incentive – and the reason why we at interfacewerk don’t do this kind of contract.
For any project that intends to produce a robust result, the variable should not be quality, but the number of features. If the stakeholders agree on timeframe & budget, then the featureset must remain flexible — because quality is non-negotiable. That is how things should be, because more features means higher complexity, higher complexity means a worse user experience, which in turn worsens – you guessed it – the quality of the product.
There is one exception, though: what if you don’t intend to keep the result? Sometimes, especially as startups, we don’t need to build something sustainable, we need to learn quickly. To facilitate quick learnings, quick prototypes are the best way. A quick prototype with all core features can’t have great quality – otherwise it wouldn’t be a prototype, it would be a finished product.
So once more, it all comes down to your intent. Do you intend to learn something and then throw it away? Then you can hack something together quick and dirty, because that’s what will allow you to achieve your goal. Do you intend to build something that will last? Then you have to build it in the best quality you’re intelectually able to achieve.