Software development has a habit of being expensive, but with the right planning it doesn't have to be. There are several techniques that can be used to keep costs low and development speed high. When these techniques are used, the result can be a win for both the client and the consultant.

Designing software is hard

A project manager has the unenviable task of figuring out what their software needs to do - a process that can often feel like divinity.

In an ideal world, project managers can reach out to users to understand their needs, but this process is fraught with problems. It can be hard to separate valuable users from the noise, and users have a habit of requesting features without considering the value they will offer or the cost required to implement them. Finally, it can be hard to a user to understand what they need - or how they will use a tool - without having it in front of them. These factors typically lead to unnecessary features when determining the needs of a program.

Learning from startups

Startups are no stranger to the problem of software bloat, but their limited financial runways have resulted in a rather clever solution - the minimum viable product (MVP).

An MVP is the simplest solution to a problem. It can behave as a foundation for future development or even just a testing platform to validate the idea. MVPs do not typically focus too much on the core technology; they often even take advantage of other third party solutions to do much of the work.

Build, Test, Repeat

The key to a successful MVP is testing and measurement. Once the initial version is launched, the product now goes from a theory to a testable model. This is the point where you can reach out to your users and see which ideas worked, what was better on paper, and what to focus on next. Development takes an iterative approach - build, measure, plan the next step.

This iterative process is how we try to keep costs low. By breaking the development process into an ongoing series of features, we spread development costs over a series of more manageable contracts. At the end of each contract, the client has a usable tool; one that can be distributed to users, measured, and reviewed to determine the best step forward. Clients are not stuck paying for features that will not be used, and the development timeline is structured more around the client's needs and the true requirements of the tool.

Lower costs mean more flexibility

Breaking a project up into chunks does more than keep costs low and development speed high - it also gives clients more freedom. The cost of maintaining and developing a project goes up as its complexity increases, so by starting small we also reduce the associated costs, such as hosting fees and maintenance contracts. Breaking a project up also gives clients flexibility to schedule the development flow around their budget and schedule. Most importantly, it lets users engage with the tool before it reaches final form. This could be as simple as using the tool internally, testing it out with beta testers, or even selling it from an early stage.

Breaking projects down into multiple tasks reduces the risk of overspending, which is why we are big fans of the technique. At the end of the day, we would rather have a happy client that has paid us less than an unhappy client that has paid us more but feels they have overspent on their project.