You’ve got a vision. A big vision. A glittering future for your business is shimmering ahead of you, dripping with success. And all you need is a whizzy new cloud-based app to make it all come true.
So why are these software engineers spending so long talking to you about end users and the intricacies of how your company works on the ground? Why don’t they just crack on with the coding and deliver it?
“New clients who haven't worked with us before have all sorts of assumptions about how it might work – and few of them are right!" explains Doug Winter, Isotoma’s co-founder & CTO.
A bigger picture
We get it. When you embark on a software project, it's easy to get fixated on code as a solution. You picture the sleek interface, the seamless functionality, and the transformative impact it will have on your business.
But what many clients (and even some software engineers) fail to realise is that the code itself is just one piece of a much larger puzzle.
If 20 years in the business has taught us anything, it’s that software development is actually less about the code and far more about communication, collaboration, and a deep understanding of your business needs.
The missing context
When clients come to us with their big, glittering vision, they often see our role as giving them little more than a boxful of code. Once we’ve filled the box with our magic tricks and handed it over, they think the job is done.
But software doesn't exist in isolation – it has to be delivered with its vital bedfellows, including:
- A solid foundation: Discovery, scoping, and planning. We need to deeply understand your goals, your users, and the specific problems you're trying to solve.
- An effective launch: Getting your software into the hands of your users takes planning, marketing, communication and onboarding.
- Ongoing support: Maintenance, administration and FinOps (financial operations), to help you manage unpredictable cloud costs.
Managing it all
That’s why, to effectively manage the complexities of a software project, we hand the reins to people holding two key, separate roles.
- Lead developer: Focuses on the architecture, managing the development team, defining tasks and technical quality.
- Project manager: Handles non-technical project management elements, including Gantt charts, risk management, communication, and hitting all-important deadlines.
It’s an approach that means we can dovetail both the technical and logistical challenges of software development. In other words, your project stays on track and delivers business value.
Shifting left
The ‘shift left’ principle is a concept we hold dear. It’s a software term that means moving tasks to earlier in the development process: discovery, agreement, and initiation. It might seem counterintuitive to slow down at the beginning – and clients are often eager to gallop ahead – but the quality of this groundwork decides if your project is going to fly or flounder.
It’s here that we make sure we’re building the right solution, agree on outcomes and develop a strong working relationship, establishing trust between our team and our client. Plus, of course, we can identify potential risks early on – and work out ways to solve or avoid them.
It also brings meaning to quality assurance (QA), so when we come to review how things are going, we can focus on understanding the business value of each feature and prioritising tasks based on their real impact.
With clients typically unused to the process, and developers who are too close to the code itself, having a dedicated QA team enables this more balanced and pragmatic approach.
Launching to the world
‘Build it and they will come’ might have worked for Kevin Costner’s baseball diamond but delivering a project isn’t enough to miraculously attract an influx of users.
“Visionary founders often trip up when it comes to launch,” says Doug. “In their head, they see the dream and imagine loads of people using it. Then, on day one, they go live. And there are no users.”
It’s a common challenge, which proves that, while the software build is going on, you also need to work on planning, marketing, communication and onboarding. We don’t want the project to flop any more than you do – especially if it’s for lack of a comprehensive launch strategy. So we nudge clients to get clear on:
- User acquisition: How will you attract your first users?
- Onboarding: How will you guide users through the software and make sure they understand its value?
- Cutover planning: If you’re replacing an existing system, how can you promise a smooth transition?
The Agile spirit
It’s worth saying that underpinning our way of thinking is an Agile approach. But we’re not necessarily talking about Agile as some might imagine. Because when you clear aside the jungle of confusion and overcomplication (mostly created in the hope of making a quick buck) that has grown up around Agile, you get back to the real spirit, as set out in the original manifesto.
“The Agile manifesto talks about things like valuing ‘individuals and interactions over processes and tools’ and ‘customer collaboration over contract negotiation’. We hold true to that original idea,” says Doug. “There’s value in plans and documentation, and we know that, but they should be taken as read. We prioritise the human, flexible and creative elements.”
Building successful software is a team effort. We're more than just coders – we're invested in your success. Our focus on discovery, launch and beyond is hard-won through (sometimes bitter) experience.
That’s why we've designed a way of working that guides you through every step of the process, from initial discovery through the build and to launch and beyond, focusing on much more than simply the code itself.
Get in touch to learn more about how we can help you bring your vision to life.
