I’ve been around digital projects for over 20 years. After a while, you start recognising the early warning signs.
Not the obvious ones, like slipped timelines or the stakeholder meeting where everyone suddenly has strong opinions about the logo.
The quieter signs. The ones that appear before the project has really started.
A client arrives with a clear request:
“We need a new website.”
“We need a customer portal.”
“We need to modernise this system.”
And sometimes they do. But that request is usually just the visible part of a bigger business problem.
The website might not be converting because the value proposition is unclear. The portal might be an attempt to fix a process nobody has properly mapped. The app might be a response to internal pressure, not actual customer demand.
This is where things go wrong. The team has skill. The platform is fine. The problem is that everyone started talking about the thing before they understood the reason for it.
The danger of starting with the specification
Specifications are useful. At some point you need scope, requirements, workflows, acceptance criteria. All of it.
But a specification is only as good as the thinking behind it.
If the strategic foundation is weak, a detailed spec creates a false sense of confidence. Everyone knows what is being built. Nobody has fully agreed on why it matters.
That is how you end up with projects that technically succeed and commercially disappoint.
The website goes live. The portal works. The forms submit. The dashboard shows the right numbers. Six months later, the business is quietly underwhelmed.
Lead quality hasn’t improved. Customers are still confused. The sales team still has workarounds. The marketing team can’t move quickly.
The deliverable was delivered. It just hasn’t delivered value.
The technical trap
One of the easiest mistakes in digital is confusing delivery with progress.
A project can have weekly calls, wireframes, Trello boards, Jira tickets, a staging site, scrums, sprints, and still be heading in the wrong direction.
The trap is when success gets defined by output. Did we build the agreed features? Did we launch on time? Did the system function as specified?
Those things matter. But they are not the same as business success.
Better questions: Did we remove a real commercial barrier? Did we make the business easier to buy from? Did we reduce wasted time internally? Did we build something the organisation can actually grow on?
Technology is only valuable if it serves an outcome. Otherwise it is a well-made cost centre.
The conversation before the build
The best projects start with a slower, more awkward conversation. Good questions that make people stop and think.
Why are we doing this now? What happens if nothing changes? Who is this really for? What is the current journey costing us? Which parts of the existing system are genuinely broken, and which are just unpopular?
These conversations are not a delay. They are part of the work, and often the most valuable part.
Once the commercial problem is clear, the technical decisions get much easier. You can tell which features matter and which are noise. You can challenge assumptions without it feeling like obstruction.
A strong strategy does not slow a project down. It makes it less wasteful.
From deliverable to asset
There is a real difference between a digital deliverable and a digital asset.
A deliverable is something you can point at. An asset earns its keep. It supports growth, gives the business better data, helps the right customers take the right actions, and can evolve as the organisation changes.
This is where the upfront thinking pays for itself.
If the goal is better lead quality, you make different decisions about content, forms, CRM integration, and conversion tracking. If the goal is operational efficiency, you spend more time understanding internal workflows before designing any screens.
Same broad project. Very different approach.
That is why “we need a new website” is not good enough. A new website to do what?
Where projects quietly become expensive
The most expensive digital mistakes rarely look expensive at the start.
They look like small compromises. “We’ll sort the content later.” “SEO can be phase two.” “The integration only needs to be basic for now.” “Let’s just mirror the existing structure.”
Each one might seem reasonable in isolation. Sometimes it is. But enough of them together and you end up with a platform that launches cleanly and then becomes difficult to grow, measure, or manage.
That is when the hidden cost appears. Not in the original invoice, but in the next 18 months of workarounds, patches, and internal conversations that start with: “Unfortunately, the system wasn’t really designed for that.”
Most organisations don’t set out to build digital debt. They accumulate it by avoiding the harder conversations early.
Why integrated thinking matters
Digital projects are rarely just technical. Even when they look it on the surface, there are usually several disciplines involved: strategy, UX, design, development, SEO, content, analytics, conversion.
If those are treated as separate stages, the work gets fragmented. The UX team designs a user journey before the content strategy is clear. Designers create layouts before anyone has considered search intent. Analytics gets left to the last minute, so nobody can properly measure what matters.
An integrated approach is not about making the process more complicated. It is about getting the right perspectives in early enough to influence the outcome.
That is where most of the real value gets created. Not in a big dramatic moment, but in small, well-timed decisions.
Launch is only the first version
Before launch, a digital project is a set of educated assumptions. Hopefully good ones, but assumptions all the same.
After launch, reality takes over.
Users miss things you thought were obvious. They abandon journeys for reasons nobody spotted in the workshop. They convert from pages that were never treated as priorities.
That is why measurement matters. Not vanity reporting or dashboards full of numbers nobody acts on. Proper measurement connected to business outcomes: lead quality, revenue, retention, quote requests, reduced support load.
A digital asset should improve over time. If it is treated as finished on launch day, it almost certainly won’t.
What we do at Mogul
We build public-facing digital assets: websites, e-commerce platforms, API integrations. But the build is not where the conversation starts.
It starts with understanding what your organisation is trying to achieve and what is currently getting in the way.
Sometimes that means challenging your brief. Sometimes simplifying it. Sometimes confirming the instinct was right, but reshaping the approach so the investment has a better chance of returning something real.
The work comes back to a few things: understand the problem before defining the solution, align technical decisions with commercial objectives, bring the right disciplines together early, and measure what actually matters. Treat launch as the beginning of a long process of improvement, not the finish line.
None of that is especially fashionable. It is just what experience teaches you.
The bottom line
Most digital projects don’t fail because nobody cared. They fail because the team got pulled into execution before the business had enough clarity.
The smarter move is to start further upstream, before the specification, before the platform debate. Before the stakeholder wish list becomes the project plan.
Ask what the investment needs to achieve. Ask who it is really for. Ask what makes the project worth doing.
Then build it.
That is how a digital project becomes more than a deliverable. It becomes an asset.
And the question is not whether you can afford to spend time on strategy. It is whether you can afford to skip it.
Thinking about a new digital project? Let’s talk through the problem before jumping into the spec.
