The most common causes of blown budgets and missed launches.
We get called into broken projects regularly. A company commissioned a website, an app or a business system six months ago. The launch date has been pushed three times. The developer is non-responsive. The original brief no longer resembles the work in progress. The relationship has broken down.
The post-mortem on these situations almost always reveals the same set of problems, and almost none of them are technical.
The real cause
Bad technology projects are usually documentation failures. Not dishonesty, not incompetence, though those exist, but a failure to write things down clearly before work began.
When scope is defined verbally, in email threads or in a brief that gets updated without a change log, there’s no shared ground truth. The client remembers one version of the project. The developer remembers another. Both are acting in good faith on different information.
By the time this becomes visible, usually when the first round of work is reviewed, both sides have already invested significant time and money. Walking back to the beginning is expensive. Continuing on misaligned assumptions costs more.
“A project without a written specification is a project that will be renegotiated at the worst possible moment.”
The five failure patterns we see most often
01. Requirements written as features, not outcomes
‘We want a homepage, an about page, a services page and a contact form’ is a feature list. It tells a developer what to build but nothing about why, for whom or what success looks like. A brief written in outcomes, ‘we need new clients to understand our service offering and contact us within three pages,’ gives everyone a shared definition of done.
02. Scope that grows without being recorded
Every project has changes. A new page gets added. A section gets redesigned. An integration gets requested. When these are handled informally, ‘just add that, no problem,’ they accumulate into weeks of unplanned work with no adjustment to timeline or budget.
A formal change log prevents this. Every change request goes in writing, every change gets a cost and timeline estimate, every approval is recorded.
03. No milestones with defined acceptance criteria
Milestone payments tied to ‘completion of phase’ mean almost nothing without a definition of what completion looks like. What’s being reviewed? Who can approve? What’s blocking versus minor?
Clear acceptance criteria at each milestone mean disputes get resolved with reference to a document, not by whoever argues loudest.
04. Communication that lives outside the project
WhatsApp messages, verbal conversations and email threads that don’t make it into the project management system are decisions waiting to be forgotten. If it isn’t recorded, it didn’t happen.
05. No one accountable for delivery
On smaller projects, there’s often an assumption that the developer will manage the project as well as build the product. These are different jobs. A good developer isn’t always a good project manager. Running both without clear structures, defined ceremonies or documentation produces work that’s technically competent but consistently late.
What our project management approach looks like
Every project we run, whether we’re building the product or managing a third-party build, starts with three documents:
- CLAUDE.md: the architecture and governance document, defining the tech stack, file structure, design decisions and developer guide
- TASKS.md: the phased build plan, with every feature, every phase and every dependency in sequence
- Client specification: the client-facing document defining scope, content requirements, design references and delivery timeline
These exist before any code is written. They’re not post-hoc records of decisions already made; they’re the decisions. Writing them forces clarity that verbal agreements never produce.
We run builds in structured sprints using ClickUp, with weekly status updates, a formal change request process and a defined QA procedure before any phase is marked complete.
This costs more time at the start. It saves significantly more time over the course of the project.
If your project is already in trouble
If you’re reading this because a project has stalled, the immediate steps are:
- Get everything out of messaging apps and email threads into a single project document
- Define what ‘done’ looks like for the current phase, in writing, agreed by both sides
- Establish a weekly status update cadence; even a brief async written update is better than silence
- Agree on a formal process for scope changes before any new requests are made
If the relationship with the current developer has broken down entirely, we can assess the existing work and advise on next steps, whether that’s salvage, rebuild or handover to a new team.
Want GressTech to review your site, stack or security posture?
Start a project at gresstechsolutions.com or write to info@gresstechsolutions.com