Pilot to productionمن التجربة إلى الإطلاق

A pilot is a limited launch to a small number of real customers before the product opens to everyone. Its purpose is not testing the code. It is finding what never occurred to you, once real money moves.

A small launch reduces the area of failure, but you still need an answer for every riyal that moves.

Why not launch to everyone on day one?

A fair question, especially when the product is ready and has been tested internally. Why slow down deliberately?

Because the most dangerous failures in financial products only appear at scale.

Picture a transfer app that ran faultlessly with two hundred staff inside the company. Then it opens to a hundred thousand. Suddenly things appear that were not possible before: two users transferring to the same account in the same instant, a message queue running ten seconds behind so retries fire automatically, and an identity provider starting to reject requests past a limit nobody mentioned in the contract.

None of those was discoverable with two hundred users.

There is a second and more important reason: you cannot un-launch. A game with a bug is pulled and apologised for. If a thousand customers were debited twice, the harm has happened, and you are now in a correction and compensation process and possibly a report to the regulator. The problem stopped being technical.

So a gradual launch is not hesitancy. It is the only way to keep the price of a mistake bearable. Fifty affected customers you can phone personally beats fifty thousand and reading about yourself in the news.

Define the pilot

A pilot has a known group, duration, volume, and objectives. It might serve 100 employees at one company for four weeks with a SAR 1,000 daily transfer limit. Opening to everyone and calling it beta is not a pilot.

Choose customers who represent real use but can be contacted after an error. Employees alone know too much and tolerate defects. Include varied devices, banks, and income patterns within licensed boundaries.

State what you need to learn: identity completion, payment success, settlement timing, or support handling. Each objective should lead to a decision before expansion.

Put it behind a switch and limits

A feature flag (مفتاح الميزة) enables a product for selected customers without a deployment. Protect it with permissions and an audit record.

Set limits on value, count, countries, and customer types so maximum impact is known. Agree them with risk, compliance, and treasury. Add limits inside services, providers, and the ledger so one failed control cannot open everything.

Write the stop condition first

An invested team cannot judge calmly during launch. Define a number, time window, and action. Stop if payment failure exceeds 0.5 percent for ten minutes or if one unexplained reconciliation difference appears.

Give each condition a timely data source and an owner with authority. Also define expansion: perhaps seven stable days, complete reconciliation, and no unresolved critical complaint.

Rehearse rollback (التراجع)

A rollback restores the previous release or disables the feature. Execute it in a production-like environment and verify database, messages, and timing.

Old code may not understand new data. Queued work may restart the unwanted behaviour. The plan must cover applications, data, scheduled jobs, queues, and integrations.

Name the decision-maker, operator, and communicator before pressure arrives.

Code rolls back; money does not

Rollback cannot cancel a completed payment or fee. A faulty release may send two transfers before old code returns. Both remain in the bank and ledger.

Separate technical recovery from financial remediation. Define how to identify affected operations, stop settlement where possible, return funds, approve compensation, and communicate accurately.

Reconcile daily during the pilot, or more often. Small volume lets staff inspect every exception. A company unable to explain ten payments cannot explain ten thousand.

Prepare support and operations

The product is not live merely because servers work. Support needs statuses, messages, and authority boundaries. Operations needs pending queues and provider escalation.

Prepare first-day scenarios: debit without confirmation, pending identity, delayed transfer, and cancellation request. Give each an answer, owner, and response time.

Tell partners the date, volume, and emergency channel. A bank may block an unexpected increase or an identity provider may lack an on-call contact.

Monitor the complete journey

Watch onboarding, activation, payment, settlement, reconciliation, and complaints. API success does not prove money arrived.

Pair every growth measure with a guardrail: approvals with fraud, faster signup with later decline, and usage with reconciliation differences. Record every limit, message, and rule change during the pilot.

Expand in stages

Do not jump from 100 customers to one million. Increase within support, reconciliation, and capital capacity, then wait through a complete settlement cycle.

Reassess controls at each stage. Manual review may work for 100 operations and collapse at 10,000. Automate before volume outruns the control.

Production is ready when operation becomes routine rather than heroic. The team knows when to stop, has practised rollback, can remediate moved money, and owns every exception.