How RAITHub Delivers Software: The 4-Phase Process

RAITHub delivers software in four phases: a free technical audit, a founder-reviewed architecture spec that you sign off, a build with working demos every Friday, and hardening plus handover with runbooks. Each phase ends with a written or working deliverable, and every change must pass automated tests in CI before it merges.

On the RAITHub homepage this process is summarised as "Four phases. No black boxes." This page explains what that means in practice: what happens in each phase, what you receive, what a normal week looks like, how the quality gates work, what handover includes, and what happens when something goes wrong.

How does RAITHub work?

RAITHub works in four fixed phases, and you make a clear decision at the end of each one. Nothing moves to the next phase without a deliverable you can read, run or check.

Phase	What happens	What you receive	Your decision
1. Technical Audit	A 15-minute call on scope, risks and real constraints	A written audit memo (PDF), even if you do not work together	Whether to continue, and with which engagement model
2. Architecture Spec	Schema, API contracts, infrastructure plan and risk register, reviewed by the founder	The spec and diagrams	Sign-off before any production code is written
3. Build, with weekly demos	Working software every Friday, branch previews, contract tests on every pull request	A demo and a changelog every week	Feedback and priorities for the next week
4. Hardening + Handover	Performance budgets, alerting, runbooks and an on-call playbook	Runbooks, on-call playbook, and the code and IP you already own	Go live and decide how you want to operate it

What happens in the technical audit?

The technical audit is a free 15-minute call about your scope, your risks and your real constraints. Afterwards you receive a written assessment, the audit memo, even if you decide not to hire RAITHub.

You book the call through the RAITHub contact page. The call is short on purpose. Its job is to find the few things that decide whether the project succeeds: what must be true at launch, what is risky, and what limits you actually have on time, budget and existing systems.

An NDA is signed before any detailed discussion of your product, so you can be specific without worrying about confidentiality.

The memo is useful on its own. You can give it to another vendor, use it to plan internally, or use it to judge how RAITHub thinks before you spend anything. If you decide to go ahead, it becomes the starting point for a written estimate with assumptions. How that estimate works is explained in RAITHub pricing and engagement models.

For an existing codebase in trouble, the audit goes deeper. Code Rescue starts with a 2-week diagnostic: a codebase audit, an infrastructure audit and a risk register. The code rescue playbook describes it step by step.

What is in the architecture spec?

The architecture spec defines the schema, the API contracts, the infrastructure plan and a risk register. The founder reviews it, and you sign it off before any production code is written.

• Schema. The data model. For backend work, the domain model (ERD) is signed off before code.
• API contracts. What each endpoint accepts and returns. For backend and API projects this becomes an OpenAPI spec, with contract tests and a versioning policy.
• Infrastructure plan. Where the system runs, how it is deployed and how it is observed.
• Risk register. The known risks, written down, with how each one will be handled.

Why insist on sign-off? Because changing a diagram is far cheaper than changing production code that other code already depends on. Sign-off also makes a fixed price realistic: both sides agree on what is being built before the clock starts. You receive the spec and its diagrams as a deliverable, and you keep them.

What happens during the build phase?

During the build, RAITHub ships working software every Friday and shows it to you in a demo. Every change gets a branch preview, and contract tests run on every pull request.

What does a typical RAITHub week look like?

A normal week follows the same rhythm, so you always know where the project is:

1. During the week, work arrives as pull requests. Each pull request gets a branch preview, a live copy of that change you can open and click through, and runs the test suite in CI, including contract tests.
2. Code is merged only when the gates pass. A failing test blocks the merge. Zero regressions is the standard.
3. On Friday you get a demo of working software, not slides, and a changelog of what changed.
4. Progress is reported honestly. If something slipped, you hear it at the Friday demo, with the reason, not at the end of the project.

The weekly demo is also your control point. You see real software every week, so you can change priorities early, while changes are still cheap.

How do RAITHub's quality gates work?

RAITHub's quality gates are automated tests in CI that must pass before code merges, plus founder review of the architecture. A change that breaks an existing test does not ship.

The full test pyramid, as RAITHub builds it in QA and reliability work, has five layers: type-checks, then unit, integration, contract and end-to-end tests. Performance budgets (LCP, INP and P95 latency) can also be gated in CI, so a slow change fails the build the same way a broken one does. Tools include Playwright, k6 and Sentry.

The results are measurable on the platforms RAITHub built:

• The PropDesk property-management platform: 1,024 automated tests across 130+ API endpoints and 60+ pages.
• The TheSkinProof marketplace (the founder's own venture, built and run by RAITHub): 750+ automated tests across 217 API endpoints and 5 role-based portals.
• The Sundor Skin wholesale platform: 530+ automated tests across 146 PostgreSQL tables and 189 SQL functions.
• The RAITHub website itself: 400+ automated tests in CI as of September 2026.

Gates also include human review. Before the RAITHub website launched, it went through a security review and a code review. Those reviews found a real bug, an admin partial-update bug. It was fixed, and regression tests were added so it cannot quietly return, before the release went out. That is the gate doing its job. The method in more depth is in QA-first development: how RAITHub tests.

What does RAITHub's handover include?

Handover includes performance budgets, alerting, runbooks and an on-call playbook, so your team can operate the software without RAITHub. You already own the code and IP by then.

• Performance budgets, so you know when the product is getting slower.
• Alerting, so problems reach a person before they reach many users.
• Runbooks: written, step-by-step instructions for routine operations and common failures.
• An on-call playbook: what to do, in order, when something breaks.
• The code and IP. Full IP ownership is assigned to you through a present-assignment clause, so you own the codebase throughout, not only at the end.

"We don't disappear at launch" is the rule on the homepage. After launch you can continue with a dedicated team or QA and reliability work on a month-to-month basis, or run everything yourself using the runbooks.

What happens if something goes wrong?

Problems are surfaced early, in writing, and handled according to whose fault they are. The process is designed so that nothing goes wrong silently.

Situation	What RAITHub does
A bug is found	It is fixed and a regression test is added, so the same bug cannot return without failing CI.
A fixed-scope project overruns through RAITHub's fault	RAITHub absorbs the overrun. You do not pay for RAITHub's estimation mistakes.
You want to change the scope	The written assumptions show exactly what changed, so the decision is made openly, before the work.
A known risk becomes real	It was already in the risk register from the architecture spec, with a plan, and it is reported at the next Friday demo.
Something breaks in production after launch	Alerting flags it, and the on-call playbook and runbooks set out the response steps.
You want to stop working together	Dedicated-team work is month-to-month with a short notice period. You own the IP and code, and the runbooks let the next team continue.

Is RAITHub's process right for every project?

No. It suits teams that want visibility and a signed-off plan. It is a poor fit if you want production code started before anything is agreed, or testing removed to go faster.

The process also does not make RAITHub a certified vendor: it is not SOC 2 or ISO 27001 certified, as the security page explains. For the full company summary, read what RAITHub is.

Last reviewed: 28 September 2026

Frequently asked questions

What are RAITHub's four delivery phases?

Technical Audit, Architecture Spec, Build with weekly demos, and Hardening plus Handover. Each phase ends with a deliverable: an audit memo, a spec with diagrams, a weekly demo and changelog, and runbooks with an on-call playbook.

Is the RAITHub technical audit really free?

Yes. The 15-minute technical audit call is free, and you receive a written audit memo (PDF) even if you decide not to work with RAITHub.

How often will I see progress?

Every week. RAITHub demos working software every Friday and sends a changelog. Every pull request also has a branch preview you can open.

When does RAITHub start writing code?

After you sign off the architecture spec. The schema, API contracts, infrastructure plan and risk register are agreed before any production code is written.

How does RAITHub prevent regressions?

Every change runs the automated test suite in CI, including contract tests, and cannot merge if a test fails. Bugs that are found get a regression test so they cannot return unnoticed.

What do I get at handover?

Performance budgets, alerting, runbooks and an on-call playbook. You already own the code and IP through a present-assignment clause.

What if a fixed-price project runs late?

If the overrun is RAITHub's fault, RAITHub absorbs the cost. If you change the scope, the written assumptions show what changed so you can decide openly.