The key to lower software development costs
If you want your software development to deliver something truly valuable to your business, understanding how things work behind the scenes is a major help.
In this series of interviews, we’re talking with the people who are best placed to understand key software development processes that non-developers often aren’t familiar with.
Prototyping is the place to start. Because few things set you up for lower software development costs, minimised risk, and results that add value better than effective prototyping, discovery, and scoping before development starts.
Here are /MyOxygen CEO Andrew Farmer and Head of Product Design Ben Hall talking about how these processes work and why they’re so important:
How prototyping reduces development cost and risk
Andy: Let’s begin with the bottom line – why should companies that want to develop a software product start with prototyping and discovery?
Ben: The short answer is, if you care about how much time and money your software development is going to cost and how good the result will be, you need to have discovery and prototyping at the forefront of your mind.
Prototyping is often thought of as something that comes in later down the line. Maybe just before you’re ready to build the product you’re developing.
The way we build prototypes for software development is different. They’re about 90% true to life and they’re quick to build. You’ll have something you can put into the hands of your users for feedback and show off to stakeholders and investors in a matter of weeks.
With a prototype like this, the bottom line is you end up creating a better product. You don’t waste time and money on features that don’t meet user needs. And it all happens upfront so development time and spend are properly targeted right from the get-go.
Andy: What exactly does the process of building a prototype look like?
Ben: I sit in on the initial meeting and workshop taking notes about the user journey, the core users, and how this product will fit into their lives. I then go back and forth with clients to increase that understanding.
After that, we create wireframes and sitemaps with the team and build a very alpha architecture, a kind of blueprint of how the product should look. We can use that to ensure the product is fit for use cases and understand the sort of technologies we might use to actually build it.
Modular prototypes like this are componentised too. So if you have immediate, mid or long-term requirements or ideas, they can be switched in and we can explore what the best solution is.
Andy: That’s the sort of thing that usually takes a lot of time and money in software development.
Ben: Well that’s the beauty of the prototyping software we use. It happens before development starts and it’s incredibly cost-effective. You can input all kinds of ideas and react to changes and it costs you little to nothing in terms of development cost and time.
In the traditional design process, by the time you learn about the ideas stakeholder X wants to include or find out your customers won’t use feature Y, you’re already in or past the development process. If you want to change anything, now you’re paying to alter something you built pointlessly.
With our more agile way, you only commit to the initial scoping and discovery phase – a fraction of the overall cost of software development. Then you know what you’re building has value and purpose.
You’re not even committed to sticking with us to actually build it. But armed with what our discovery and prototyping show you, you’ll find it much easier to get quotes from other developers that are actually accurate.
Andy: Many clients ask us to quote for a whole product before discovery. It’s a real challenge to explain that any quote a software development company provides for a product based on a list of requirements isn’t going to be at all accurate.
Ben: Which is how so much software development ends up going way over budget. Budgets end up being based on quotes that don’t have any knowledge or proof behind them.
With a quote like that you’re also tying yourself to requirements that aren’t based on any research or discovery or what the best solution really is or what your users will get value from.
With the discovery-based prototypes we build, you can click this here, interact with that there, and see what’s supposed to really happen. It’s all visual and interactive.
Not only does this make it easier to see what you’re getting in the end – much easier than imagining it from wireframes and flat designs – you can estimate costs with actual accuracy.
Andy: So it’s best to think of prototyping as part of the discovery process?
Ben: I would definitely say so. It’s a big change from the way things used to be done.
Once upon a time, we’d get a concept, build and develop it, and then give the product to a user. Now, with this new agile way of doing things, the user can actually help with development.
This keeps costs way down. Maybe as much as 20% lower. Mainly because you can explore all the ideas and make changes in this sandbox before you write any code.
It’s like building a house. It’s much easier to change at the drawing stage than after you’ve built and suddenly decide actually you didn’t want four stories and maybe the bathroom would be better over there.
Andy: Which is the kind of thing businesses are looking for in economic times like these.
Ben: Exactly. We need to concentrate on helping businesses save costs and time and not build things that aren’t fit for purpose.
There’s no need to start with a massive brief. You don’t need to go to the stakeholders and say, “We need big money for this massive new project”.
Instead, you only need a tiny investment. Plus, the kind of prototype created at the end of a good discovery and scoping process gives you something to actually put in the hands of stakeholders and they can say, “I see what we’re getting”.
Maybe more importantly, they can see the case for why it’s a benefit to the business as a whole. The same is true if you’re someone with an idea you’re looking for investment in. We can build something completely viable with no development cost and no database setup required.
Something that feels very real and viable is always going to be much more persuasive than going in talking about how amazing your idea is with no proof or knowledge and no discovery done.
Andy: Ben, thank you very much.
Want to see how discovery and prototyping would work for your product?
Set up a FREE demonstration today to explore how the process could work for you.
We will keep you up to date with all the latest in mobile and web app development