The Business Owner's Guide to Building Digital Projects
At AwakenHub, we care about what really happens behind the scenes of building something new. The messy middle. The near misses. The “I just need an app” moments that turn out to be a lot more complicated than they first appear.
In our recent online masterclass, we sat down with Martin Naughton, Managing Director of Galvia Digital, for a straight talking session on how business owners can build better tech, without blowing the budget or losing control of their projects.
With more than 25 years' experience as a solutions architect, working with everyone from early stage founders to global corporates, Martin has seen the same problems show up again and again. What followed was a candid, practical conversation about what really goes wrong with digital projects, and how to avoid it.
Why digital projects really fail
Martin did not start with the success stories. He started with the statistics.
Between 70 and 95 per cent of digital transformation projects fail to meet their intended goals. Even in well resourced, well known organisations.
Often, he explained, the problem is not the code, but everything around it.
“It is not the tech that is the problem, it is the system you have designed around it.”
From unclear scope and vague briefs to poor data management, siloed systems and bad estimates, he walked through the familiar issues that quietly undermine projects, long before a single user logs in.
His message was clear. If you do not fix the foundations, no amount of clever technology will save you.
From “I just need an app” to “what problem are you solving”
Martin hears the same opening line from companies of all sizes.
“I just need an app.”
He likens it to saying “I just need a house” or “I just need a car”. It sounds simple. In reality, it is anything but.
Again and again, he sees founders jumping straight to the solution, without slowing down to define the problem or the user. That is where neglected market research and “build it for everyone” thinking creep in.
His approach is surprisingly old fashioned. Pick up the phone.
He shared stories of founders who thought they knew their market, then completely reframed their product after a series of honest conversations with potential customers. Some discovered a much clearer niche. Others discovered there was no real need at all and pivoted before spending tens of thousands on development.
“The market tells you if your idea is good, not the technology.”
For Martin, tech first thinking is the wrong way round. You start with the problem, the user and the evidence, then choose the technology.
Scope, must haves and the danger of vague briefs
If there was one theme Martin kept returning to, it was scope.
He sees founders who “have it all in their head”, but nothing written down. Developers taking requirements over the phone. Projects changing direction mid build because nothing was agreed upfront.
“You would not build a house like that. You would not phone a builder and just talk it through.”
Instead, he encourages business owners to get everything out of their heads and into a document. It does not have to be perfect. In fact, he often asks founders to write the “worst requirements document” they can, simply to get started.
Once it is on the page, you can:
Spot contradictions
Separate must haves from nice to haves
See where the gaps are
Nice to haves, he reminded us, are like a jacuzzi in a house. Lovely, but not what sells it. The must haves are what actually solve the problem and make the product worth paying for.
Vague briefs, on the other hand, are expensive. If you are vague, your developer will make assumptions. They have deadlines to meet. If you do not tell them what is required, they will decide for you.
Stakeholder mapping and the people you forgot about
One of the most insightful parts of the session was Martin’s focus on stakeholder mapping.
Most founders think about their end user. Fewer think about everyone else who touches or is affected by the system.
Martin walked through the wider cast of characters: admin teams, accountants, logistics partners, specialist clinicians, buyers and budget holders. All of them have needs, pain points and power.
Ignore them, and you risk low adoption, internal workarounds and quiet resistance that can sink even the best designed product.
“Everybody affected should have a voice. Early input means fewer redesigns and higher adoption later.”
By mapping out who is involved, how they buy and what they need, you can design something that fits the real world, not just the ideal user journey on a whiteboard.
Blueprints, designs and snag lists
Martin’s house analogy cropped up throughout the masterclass, especially when he talked about documentation and design.
In his world, a credible software project comes with:
System blueprints that show how everything connects
ERDs (entity relationship diagrams) for the database
Architecture diagrams that give any new developer a clear overview
Without these, he warned, you are relying on “tribal knowledge” inside one developer’s head. If they leave, you may find yourself starting from scratch.
“If you do not have the server details, the code and the documentation, you actually have nothing.”
He also highlighted the role of tools like Figma and Draw.io in reducing change later. Just as an architect will show you drawings of the inside of your house, preliminary designs and clickable prototypes mean everyone can see and agree what is being built before development begins.
On testing, he compared user acceptance testing to the snag list you walk through at the end of a house build, checking every door, socket and window.
Many founders think they have tested their app, he said, until someone sits beside them and starts pressing everything they never touch.
Owning your project
Perhaps the most sobering story Martin shared was of a founder whose freelance developer was moving abroad. The founder wanted Galvia Digital to take over.
When Martin asked where the system was hosted, where the code lived, and where the documentation was, the answer was the same each time. “I do not know.”
“At the end of that conversation, I had to say to him, you actually have nothing.”
For Martin, ownership is non negotiable. As a founder, you are responsible for:
Getting everything in writing
Making sure documents and diagrams are created
Insisting on a proper handover at the end of a project
When things go well, everyone wants to claim they were part of it. When things go badly, it can quickly become nobody’s job. His advice was simple. If you are building a product, you have to be the owner.
Advice for founders
Throughout the masterclass, Martin’s advice was rooted in experience, not theory. His guidance for founders, especially those without a tech background, can be summed up in a few key points:
Start with the problem, not the product
Do your market research early, and talk to real users
Write things down, even if it is messy at first
Separate must haves from nice to haves
Map your stakeholders, not just your end users
Ask for blueprints, diagrams and documentation
Never finish a project without a proper handover
Above all, he came back to one core idea. Successful digital projects are built on clarity.
If you are a founder feeling unsure about where to start with tech, or you have already had one project go wrong and want to do it differently next time, this conversation is well worth a watch.
🎥 Replay available for AwakenHub members
🔓 Not a member yet Join Here to access our full library of replays and upcoming skills building events.
#AwakenHub #BuildBetterTech #GalviaDigital #WomenInBusiness #DigitalProjects #FounderStories #SkillsForScale
