Skip to content
Debbie
Back to Project Delivery
Real founder-led project

Perah Studio Delivery System

Turning founder-held delivery knowledge into a usable operating system.

Role
Founder / Project Lead
Duration
2026 operational improvement
Project context
Perah Studio · independent design practice

Built from Deborah’s real studio practice. Version 1.0 was formalised in 2026 and tested retrospectively; live effectiveness is not yet measured.

At a glance

14
Canonical delivery stages
3
Proportionate delivery tiers
10
Real retrospective events mapped
7
Hypothetical failure tests
01

The brief

Perah Studio had real delivery experience but much of the operating knowledge still lived with me. I audited the surviving evidence from the studio’s own website, reconstructed what could honestly be supported and formalised a lightweight delivery system for future branding, UX/UI and website work.

Version 1.0 was created after the historical website delivery. I tested it retrospectively against ten confirmed website events and challenged it with seven hypothetical failure scenarios; I do not imply that the website was originally delivered through this later system.

02

The starting point

The studio needed repeatability without a miniature corporate PMO. The evidence also varied in strength, so I classified claims, removed unsupported outcome language and used the website only as a representative internal product—not as a client commission.

14
canonical stages
3
delivery tiers
10
real events mapped
7
failure tests
29
active system artefacts
03

What I was responsible for

  • I created and run Perah Studio and designed, built, tested and deployed its website as an internal studio product.
  • I audited repository evidence, first-person context and gaps, then controlled which claims were safe to publish.
  • I designed the 14-stage lifecycle, delivery tiers, central Control Centre, client guidance, gates, QA and handover controls.
  • I ran the retrospective tabletop, designed seven failure tests and changed the system where testing exposed unnecessary weight or a continuity gap.
  • I closed Version 1.0 with a 30/60/90-day validation plan rather than inventing retrospective performance gains.
  • Evidence audit
  • Process design
  • Governance
  • QA
  • Tabletop testing
  • Measurement
04

How I structured the project

  1. 31 Jul–3 Aug 2026

    Historical website delivery

    Real internal product delivered before Version 1.0 existed.

    Stage 1 of 7

  2. Evidence phase

    Audit

    Inventory sources, classify claims and record gaps and chronology.

    Stage 2 of 7

  3. Current state

    Reconstruct

    Map supported practice, friction and the strongest website delivery events.

    Stage 3 of 7

  4. System design

    Formalise

    Create the lifecycle, tiers, controls, client pack and Delivery Control Centre.

    Stage 4 of 7

  5. Evaluation

    Tabletop test

    Map ten real website events to the new controls without claiming historical use.

    Stage 5 of 7

  6. Evaluation

    Failure test

    Challenge seven scenarios and expose the collaborator-continuity gap.

    Stage 6 of 7

  7. 23 Sep 2026

    Version 1.0

    Refine, approve for future use and transfer live validation to operations.

    Stage 7 of 7
05

The hard part

The useful system was smaller than the first one.

My first concept separated actions, risks, decisions, changes and approvals into several logs. The retrospective website test showed that this would be disproportionate for a solo internal product and likely to create lightly maintained records rather than stronger control.

I consolidated the working view into one Delivery Control Centre, made QA modular and kept separate records only when complexity or risk justified them. The failure tests then exposed a different gap: collaborator ownership meant little without repository access, documentation and transfer responsibility.

06

Key decisions

Decision 01

Use one central control view

Context
The draft system had separate logs for every control type.
Options
Keep a template-heavy model, or consolidate routine control while retaining escalation routes.
Decision
I made the Delivery Control Centre the maintained source for scope, milestones, RAID, decisions, changes and status.
Why
One accurate page is stronger than several stale logs for a Focused or solo project.
Consequence
Expanded registers open only where project complexity or risk requires them.

Decision 02

Tier by material complexity, not price

Context
A small studio needs controls that scale without invented historic pricing thresholds.
Options
Use one process for everything, use monetary bands, or classify by the highest material delivery factor.
Decision
I created Focused, Standard and Extended tiers based on breadth, stakeholders, technical exposure, dependencies and launch risk.
Why
The control level should follow the delivery risk rather than the fee alone.
Consequence
A landing page can stay light while a custom integration gains stronger evidence and continuity controls.

Decision 03

Make functionality tell the truth

Context
The historical Doorbell looked like a send action but actually created an email draft.
Options
Leave the implication, remove the feature, or disclose the real behaviour and provide fallback.
Decision
I made truthful functionality a release control: live, intentionally disabled, clearly disclosed or removed.
Why
Visual polish should not imply a capability that the product does not have.
Consequence
The principle now appears in QA and launch readiness for future work.

Decision 04

Do not backfill benefits

Context
Version 1.0 had been formalised and tabletop-tested but not yet used across enough live projects.
Options
Infer improvement from the design, retrofit historic metrics, or define future measurement.
Decision
I closed the project with a 30/60/90-day validation plan and no performance claim.
Why
A well-designed operating system is not evidence that it has shortened delivery or improved profitability.
Consequence
Version 1.1 depends on observed live friction and measures, not retrospective optimism.
07

Project control

  • Fourteen canonical stages run from enquiry through optional ongoing support, each with inputs, outputs, responsibility, decision and exit criteria.
  • Three tiers—Focused, Standard and Extended—scale control by the highest material delivery factor.
  • Feedback, revision, change request and defect have separate meanings so new scope cannot quietly consume revision allowance.
  • The launch gate combines scope, content, QA, access, residuals, recovery and approval into GO, GO WITH CONDITIONS or HOLD.
08

Testing and assurance

I mapped ten confirmed website events to Version 1.0, then used seven explicitly hypothetical failures to test whether the system produced an owner, decision route, schedule consequence and clear communication without unnecessary ceremony.

  • Ten real events mapped to appropriate controls in the retrospective tabletop.
  • Seven hypothetical failure tests passed; one prompted a collaborator-continuity refinement.
  • The historical 20-category launch audit informed modular QA rather than becoming mandatory everywhere.
  • Live effectiveness is not yet measured and no historical use of Version 1.0 is claimed.
09

Version 1.0 became an operating product in its own right

The final system includes the lifecycle, qualification and tiering, scope and requirements controls, responsibility and content-readiness tools, design-to-build and launch gates, modular QA, truthful-functionality control, handover and closure, service variants and the central Control Centre.

The operating artefacts are new 2026 controls. The historical Perah website provides evidence and test material, but the system’s effectiveness will be established only through future live use.

10

What happened

Real 2026 operational-improvement result

Complete

Version 1.0

Ten confirmed website events

Pass with refinements

Retrospective tabletop

Hypothetical tests · one refinement incorporated

7 scenarios

Failure testing

Future 30/60/90-day validation

Not yet measured

Live effectiveness

11 · Evidence gallery

These are readable web-native representations of the source artefacts—not fake software screenshots. Open any item for a larger view and its source reference.

12

What I learned

Governance should reduce ambiguity, not advertise complexity. The right amount of evidence changes with risk, but responsibility, scope, quality and release decisions must remain visible.

The system is ready to use, not proven to improve performance. The next version depends on live evidence about approval time, content delay, revisions, defects, handover and recurring friction.

Previous case ParentLinkBack to DeliveryNext caseClinicFlow