Thesis: Most software projects fail before anyone writes production code — because scope, ownership, and evidence were never governed, and the first commit only amplifies decisions already made badly.
The myth of “we just need to develop”
A founder once told us their ERP replacement was “ninety percent a development problem.” Six months later, the team had not merged a single feature branch. The blocker was not talent or tooling. Three departments each believed they owned the chart of accounts. Procurement had already signed a data migration vendor against architecture assumptions nobody had written down. The board wanted a go-live date; nobody could name the acceptance criteria that would make “live” mean anything other than hope.
That story is ordinary. Stakeholders describe failure as a coding crisis — missed sprints, the wrong framework, insufficient senior engineers — when the fracture happened earlier, in rooms where no repository existed. WebDraco treats that pre-code phase as governance territory, not project-management theatre. Code is an amplifier. It makes good decisions compound and bad ones expensive at scale.
Why this matters before the first commit
Ignoring pre-code governance costs time, money, and organisational trust. Teams that rush to “start building” often discover — mid-sprint — that “done” means different things to finance, operations, and compliance. Rework is not a development inefficiency alone; it is the bill for decisions taken without a record, an owner, or a verification path.
For European organisations running regulated or multi-entity operations, the cost is sharper. Entity isolation, audit trails, and configurable mappings are not implementation details you “add later.” They are architectural commitments. When those commitments are argued verbally and coded opportunistically, you do not get agility. You get a system that passes demos and fails scrutiny — the moment someone asks how a number was produced or who approved a structural change.
The recurring mistake: shipping intent without structure
The most common error we see across mid-market programmes is conflating activity with progress. Backlogs fill. Ceremonies multiply. Repositories exist. Yet three structural gaps remain:
- Scope without boundaries — every stakeholder’s wish list becomes implicit requirements.
- Ownership without authority — roles are named, but no one can pause work when evidence is missing.
- Opinion without evidence — architecture choices are defended by seniority, not by tests, traces, or explicit trade-off logs.
An anonymised illustration: a distribution company began a warehouse module while sales still debated whether pricing rules belonged in ERP or a peripheral service. Development chose a pragmatic split to unblock the sprint. Finance discovered the split twelve weeks later during month-end close — when reconciliations no longer tied to the general ledger without manual journals. Nobody had “failed at coding.” They had failed to govern a boundary decision before it became code.
Early signals you are already behind
Several patterns predict pre-code failure long before velocity charts turn red:
- Decisions live in chat threads or slide decks, not in durable records linked to work items.
- “Governance” means more meetings, not clearer gates with verify steps.
- Architecture diagrams are marketing artefacts — they do not constrain pull requests.
- Risk is discussed qualitatively; nobody names what evidence would falsify the plan.
- A software partner is treated as an agency that “delivers features” rather than a factory accountable for system integrity.
We call the accumulated gap governance debt — analogous to technical debt, but upstream. Like technical debt, it accrues interest. Unlike technical debt, refactoring it after go-live often means renegotiating contracts, retraining users, and explaining to auditors why controls were retrofitted instead of designed.
What changes with explicit governance
Explicit governance does not mean heavyweight process for its own sake. It means making a small set of decisions legible and testable before implementation absorbs them:
- Boundaries — what is in scope for this release, what is explicitly out, and what triggers a formal change path.
- Owners — who can accept residual risk for each boundary; who can halt a line when verification fails.
- Evidence — what artefact proves a claim (test, migration result, reconciliation, signed acceptance marker).
WebDraco’s programmes apply Proof of Useful Governance (PoUG) here: governance is useful only if it closes uncertainty that would otherwise force rework or silent risk acceptance. A governance ritual that produces slides but not decisions is activity. A gate that records “PASS” without eliminating a branch of work is theatre.
When these elements exist, development speed often increases — because engineers are not re-deriving policy from hallway conversations. They implement against constraints that survived contact with finance, operations, and security. That is the difference between a feature factory and a software factory.
WDSF: factory, not agency
The WebDraco Software Factory (WDSF) is not a branding label for custom development. It is an operating model: build software as a governed system with observable modes — observe when risk is unknown, change when intervention is warranted, release when acceptance is explicit and evidenced. How those three modes work in practice — and why a single governance template fails — is set out in The Three Governance Modes: Observe, Change and Release. Agencies optimise for throughput of screens. Factories optimise for correctness, control, and long-term responsibility — the same language we use for ERP and governance platforms serving European operators.
That distinction matters when you select a partner. An agency asks what you want built. A factory asks what must remain true after build — across entities, audits, upgrades, and staff turnover — and works backward to architecture, migrations, and gates. Pre-code governance is where that backward pass happens. Skipping it turns your programme into a bet that talented developers will infer organisational truth from tickets.
A practical check you can run this week
Pick one decision your programme already “made” — hosting region, data ownership, integration style, CoA mapping approach, or release cadence. Ask five people independently: Who owns this decision, what evidence supports it, and what would cause us to reopen it? If answers diverge, you have found governance debt worth paying down before the next sprint, not after the next demo.
Log the outcome. Assign a single owner. Set a date to either ratify the decision with evidence or escalate it through a formal change path. One hour of alignment here often saves weeks of branch thrash — not because alignment is magic, but because code remembers what meetings forget.
Limits
This article describes governance concepts and practices. It is not legal or regulatory advice. Implementation depends on your context, sector, and qualified review. No governance model eliminates delivery risk; it improves the odds that risk is visible before it is compiled.
Conclusion
Software projects fail before code when teams treat development as the starting line instead of the amplification stage. Governing scope, ownership, and evidence first is how serious programmes protect time, trust, and system integrity — and how a software factory earns the name.
Explore how WebDraco applies governance from day one — see our ecosystem or start a conversation about your next programme.