The 10 Fundamentals
MOHARA's 10 Fundamentals of Repeatable Quality are how good software stops depending on who happens to be in the room. Each is broken into rituals, each ritual is scored against evidence on every project, and quarterly audits moderate the scoring in both directions. Quality here is measured, not asserted.
They started as eight. They grew to ten because Design earned its own fundamental rather than sitting inside engineering, and because AI adoption needed governing like everything else rather than happening around the edges.
The ten fundamentals
| Fundamental | What it does | |
|---|---|---|
| F1 | Agile Thinking | Identify the risks and assumptions early, including the business model and the stage of business, then work in small increments that let you verify them rather than committing to a plan reality will break. |
| F2 | Product Thinking | Understand the business, the users and the stage before designing anything, so the build solves the right problem to the right degree. |
| F3 | Shared Understanding | The client, the product team and the delivery team hold the same picture of why we are building, what we are building, and how we will know it worked. |
| F4 | GitHub Issues as Micro-Contracts | Every unit of work is a GitHub issue stating exactly what is required and how it is judged done, with GitHub as the single source of truth. |
| F5 | Four Lines of Defence | Quality is everyone's job: work is confirmed by the person delivering it, technically reviewed, QA reviewed, regression tested, and root-caused when it goes wrong. |
| F6 | Project Set Up | Start with zero whitespace. Where nobody has defined what happens, uncertainty grows and becomes risk, so foundations are set deliberately at the start rather than assembled while running. |
| F7 | Engineering Rituals | The recurring habits, from planning to review to release, that keep delivery predictable regardless of who is on the team. |
| F8 | Security and Maintenance | Keep products secure and healthy over time: dependencies updated, vulnerabilities addressed, production monitored rather than left to drift. |
| F9 | Design Rituals | Design has its own quality bar: the right tooling, working design systems, clear channels between design, engineering and client, more than one set of eyes before anything ships, and QA that checks what reached the user matches what was designed. |
| F10 | AI Adoption | AI tooling is governed like everything else, used to accelerate the work while humans stay accountable, with all code reviewed, tested and approved before it ships. |
Three worth explaining in full
Four Lines of Defence (F5)
The first fundamental MOHARA ever wrote, and the simplest. Quality is everyone's responsibility, and improves when more people look at a problem. Work is agreed, confirmed or pushed back by the person delivering it, technically reviewed, QA reviewed, regression tested, and root-caused when something goes wrong.
The metaphor in the original document is a castle with many outer walls: a failure at any one point does not mean the castle falls.
Issues as micro-contracts (F4)
A GitHub issue is a contract on the smallest unit of work: both the person delivering it and the people who need it know exactly what is required. The aim is to remove whitespace, the gaps where nobody has defined what happens.
Issue bodies are now AI-generated from the PRD and reviewed by an engineer or engagement lead, who checks the classification and the acceptance criteria rather than accepting the output.
AI Adoption (F10)
AI tooling is a core part of how projects are delivered, so it is governed like everything else rather than left to individual preference. The client-facing commitment, published close to verbatim:
We use AI tools to accelerate and improve parts of our software development process. This might include generating ideas, suggesting code, debugging, or spotting errors. AI is never the sole decision-maker. All code is reviewed, tested, and approved by our human developers before it is used in any product.
AI suggestions are treated like input from any other tool: useful, but never a replacement for our own expertise and judgement. Our standards for accuracy, quality, and security will not change.
We also do not allow AI providers to train their models on any of your source code.
Whitespace
Whitespace is where nobody has defined what is happening. What is a user story, what is the budget, what is the meeting schedule, who decides.
Whitespace breeds uncertainty. Uncertainty breeds risk. A great deal of what the fundamentals do is remove whitespace before it turns into something more expensive.
How quality is actually measured
Every fundamental is broken into rituals. Every ritual is scored 0, 0.5 or 1 against evidence, per project, continuously rather than in the run-up to a review.
Two things make the scoring meaningful rather than decorative:
Not every project should score full marks. Different teams, goals and maturities call for different benchmarks. Part of the exercise is recognising where excellence is warranted and where good enough is genuinely good enough. A score is only worth anything if it reflects the truth rather than what people think others want to see.
Quarterly audits moderate it. The Head of Engagement runs audits that sit with the team, review recent decisions, and check that documentation matches how the project actually runs day to day. They challenge generous self-assessment, and they equally challenge teams marking themselves too harshly. The purpose is consistency across projects, not catching people out.
Because this scoring has run continuously for years, it is a live quality system rather than a metric assembled for a website.
Quality evidence: the rework measurement
The strongest quality evidence comes from 18 months of QA records on a client engagement, covering three separate applications with three separate QA processes: 8,234 QA-analysed tickets, a 14-month baseline and a 4-month recent period, drawn from records between January 2025 and July 2026. It is described as a client engagement, never named, exactly as the delivery research withholds its client names. Three independent QA processes make it a stronger sample than the speed research, not a weaker one.
The headline: rework fell by roughly two thirds, and has stayed down.
| Measure | Baseline | Recent | Change |
|---|---|---|---|
| QA pushback rate (tickets returned from QA) | 17.95% | 7.05% | −61% |
| Severe rework (tickets bounced 3+ times) | 1.86% | 0.20% | −89% |
| Rework cycles per 100 tickets shipped | 25.0 | 8.7 | −65% |
| Releases shipping clean (zero QA pushbacks) | 24.6% | 61.2% | 2.5× |
Why this is not a team slowing down to be careful
This is the objection that matters, and the data answers it directly. Monthly ticket volume rose from 412 to 617, roughly 50%, while the pushback rate was falling. The team grew from 6.4 to 8.8 developers and throughput per developer still edged up slightly, where adding people usually costs per-head output for a quarter or two. Median release size held at 20 to 29 tickets, so this is a genuine per-ticket quality change rather than an artefact of shipping smaller, safer batches.
More work, more people, larger releases, and less of it coming back.
Stated conservatively
Every month from April 2026 onward sits at or below the lowest single month of the entire preceding year. This is a level shift that has held for four months, not one good month. One application logged four consecutive months of exactly zero pushbacks, which is as likely to be field abandonment as perfection. Excluding it entirely, the fall is 16.8% to 7.9%, a 53% improvement. The claim survives either way, and saying so is the point.
What we do not claim
The data does not support attributing this improvement to MO_AI, and we do not. Across 91 governance rows mentioning AI, not one names a developer-facing AI tool; the only dated developer-facing AI event in the corpus lands after the improvement had already begun; and a repository migration arrives in the same commits. The honest statement is the one we make:
Rework fell by roughly two thirds and has stayed down for four months, coinciding with the team's adoption of AI-assisted development.
Coinciding with, not caused by. Section 05 earns its credibility by publishing what its own research excluded, and quality evidence on the same site holds to the same standard.
Where AI sits inside the fundamentals
AI does not replace the fundamentals. It operates inside them, and increasingly helps deliver them.
- Problem and research: condensing research, pulling themes from notes, synthesising context alongside traditional discovery.
- Requirements: turning intent into structured, reviewable PRDs faster.
- Issue generation: drafting issues from a PRD, which an engineer refines for accuracy, sequencing and testable criteria.
- Implementation: agents executing substantial units of work under an engineer's direction, against a reviewed plan.
- Review: automated reviewers adding a consistent first pass, with humans keeping judgement.
- Autonomous upkeep: small patches, dependency updates, production-error triage.
The principle throughout: AI raises the floor and the pace. Humans keep the ceiling, which is the judgement about whether the work is actually any good. Design settles behaviour before any of this begins. See how we decide what to build.
Common questions
What are MOHARA's 10 Fundamentals of Repeatable Quality?
Agile Thinking, Product Thinking, Shared Understanding, GitHub Issues as Micro-Contracts, Four Lines of Defence, Project Set Up, Engineering Rituals, Security and Maintenance, Design Rituals, and AI Adoption. Each is a non-negotiable applied to every project and broken into scored rituals.
How does MOHARA measure quality?
Every fundamental is broken into rituals, and every ritual is scored 0, 0.5 or 1 against evidence, per project and continuously. Quarterly audits run by the Head of Engagement moderate the scores for consistency across projects.
Does AI replace MOHARA's quality process?
No. AI operates inside the fundamentals and increasingly helps deliver them, but humans keep the judgement about whether the work is actually good. All code is reviewed, tested and approved by human engineers before it ships.
Where these fundamentals are applied to your product by our team.
Explore Built By