Skip to content
07.4Capability — Product engineering

Built to be handed over.

Every product has a second audience: whoever maintains it after us. That is the constraint that decides the stack, the types, the tests and the migrations — not a preference for any of them. A member’s app and the console your team runs the day from are one system, and both are handed over with the reasoning written down.

Scope a build
What it looks like

One system, two surfaces

One systemmember app · web consolerelease 2.11.0 · handed over
Member app — iOS and Android
Signed inM-2081

حصصك هذا الأسبوع

الاشتراك فعال حتى ١٤ ديسمبر

  • تدريب لياقة — الثلاثاء ٢٠:٠٠

    مؤكد · الملعب الشمالي

  • مباراة داخلية — الخميس ٢١:٠٠

    قائمة انتظار · ترتيبك الأول

  • تقييم بدني — السبت ١٨:٣٠

    مؤكد · مع الكابتن سامي

  • تدريب حراس — الأربعاء ١٩:٠٠

    متاح · مقترح لك

احجز حصة

Back office — web
MembersSessionsAttendanceInvoices24 active
  • Faisal Al-HarbiM-2081Season · three nightsRenews 14 Dec
  • Nawaf Al-OtaibiM-2044Season · two nightsRenews 02 Jan
  • Ziyad Al-QahtaniM-1997MonthlyLapsed 28 Nov
  • Turki Al-DossariM-2103TrialConverts 09 Dec

4 of 24 shown · M-2081 appears on both surfaces

Press Try now to drive it yourself
احجز حصةألغِ الحجزجدّد اشتراكيMark attendance
Carried out

— nothing driven yet

On the member app

— the week as it stands

In the back office

— 24 members active

What travels with the repository
Type checker

strict · 0 errors

Tests

412 passing

Migrations

37 · all reversible

Accessibility

AA · keyboard pass

Documentation

runbook · decision log

The same product on two surfaces. On the left, a member app in Arabic showing the member’s sessions for the week, the state of their subscription, and a button to book another. On the right, the web back office the academy operates it from: a toolbar, and a table of member records with plan and renewal date, including the same member, M-2081, whose app screen is drawn beside it. After pressing Try now the reader drives it, choosing an action a member would tap on the phone or one the office would carry out in the console; each one changes both panels at once, and the strip beneath names what changed on each. Along the bottom, the facts a handover carries — a strict type checker with no errors, 412 passing tests, 37 reversible migrations, an accessibility pass, and documentation including a runbook and a decision log.

Both panels are drawn in code in this palette — the same product on a member's phone and in the back office it is operated from. Press Try now and take an action on either side: it lands on both, which is the argument. No client screen is reproduced, no member record is real, and the build facts along the bottom state what a handover contains rather than measure one project.

How it runs

Six steps, and the last one is yours

01

Model

What a record is, what may be true of it, and what the database itself refuses to store.

02

Type

Types are written before the screens, so an impossible state is a compile error rather than a support ticket.

03

Build

Two surfaces from one set of rules: the application a member uses and the console your team works in.

04

Test

Unit tests on the rules, integration tests on the boundaries, and end-to-end runs through anything that touches money.

05

Migrate

Every schema change is a numbered, reversible migration, applied the same way in every environment.

06

Hand over

The repository, the runbook, and a decision log that says why each choice was made and what it rules out.

What you get

Enough to build it again without us

Mobile applicationiOS and Android, in your own developer accounts
Web consoleThe back office the business actually runs the day from
RepositoryIn your organisation, with its full history from the first commit
Test suiteRun on every change, before anything is allowed to merge
MigrationsNumbered, reversible, and the same in every environment
DocumentationArchitecture, runbook, and a decision log with the reasoning
What it connects to

Into the systems around it

Systems of recordMembers, schedules, catalogue — whatever the business already keeps
PaymentsSubscriptions, one-off charges, and the receipts that follow them
IdentityYour directory or sign-in provider, not a second password to remember
NotificationsPush, email and WhatsApp, from events the system already emits
AnalyticsProduct events landing where the business reads its numbers
SupportSo a report from inside the application arrives with its context attached
Custom, not configured

Yours to take anywhere.

The repository sits in your organisation from the first commit, and the stack is chosen for what the product has to do and for whoever will maintain it — not for what we happen to enjoy writing. The test of a handover is whether a team that has never met us can pick the work up, so that is the standard the documentation is written to.

Owning the code is not the same as never maintaining it. Dependencies age, platforms change their rules, and someone has to be answerable for that — we write down who, and on what terms, before the build starts.

Next

Ask what happens if we leave.

It decides how a product is built, and it is the easiest question to answer too late. Tell us what you are building and who will be running it a year from now, and we will scope it to that.

info@studiomedi.comContact