I am in France. How do I check the work without travelling?

Through the acceptance environment, at its own address, which you open on your phone, and through the scenarios written before the code that you run yourself every fortnight; the test report, access to the Git repository and the version log complete it. The year’s two trips serve to meet your customers, not to watch the vendor.

Every two weeks, is that not too often?

It is what keeps every delivery small, hence acceptable in three days and reversible in ten minutes. A delivery every six months is big, hence impossible to accept fully and impossible to roll back. The rhythm holds if the batch is written before the code and the tests are automated.

What happens if the release breaks something?

The previous version is always ready, the database migration was done in two steps and its rollback tested in acceptance, and the rollback is one command: under ten minutes, and only the first shop or the first fraction of users saw the problem. The batch is then fixed and re-accepted before going out again.

How do I know the tests really exist?

The continuous integration test report is attached to every delivery, with the number of tests and their result, and that number must not go down; the vendor can also show, in acceptance, a deliberately wrong change refused by the machine. A vendor who can show neither has no tests.

Can we go live during Ramadan or before a holiday?

Not on the eve of a holiday, and during Ramadan only in your users’ real off-peak hours, which are not those of the rest of the year; the rule is that a release happens when someone can supervise the following hour and your users are few.

Delivering an app without breaking it in Algeria in 2027: a demo every two weeks, remote acceptance from France, automated tests, progressive release and rollback, what the client checks at every delivery

Short answer. An app is not delivered once, at the end; it is delivered every two weeks, and every delivery follows the same path: a batch written before the code, with its acceptance scenarios; automated tests delivered with every feature and replayed at every change by continuous integration on a server, which refuses the delivery before the client sees it; an acceptance environment at its own address, a copy of production with test data, that the client opens on their phone from France; a demo and written acceptance point by point; then a progressive release, with no downtime, first one shop or a fraction of users, with a one-command rollback and reversible database migrations. Code, scripts and environments are in the company’s name. Twenty-four deliveries a year, and the client knows at every moment where their app stands.

This guide is for the founder settled in France who cannot be at the vendor’s premises and wants to know what they are entitled to demand, the company in Algeria that lived through the end-of-project big-bang delivery and its three weeks of outages, and anyone reading “tests and acceptance” in a quote without knowing what it must contain. It does not cover what is written before the project, which the guide on the specification does, nor overall timelines, described in the guide on real delays; it covers the mechanics that make a delivery arrive whole, and a failed delivery cost ten minutes rather than a weekend.

What the figures say

Delivery can be measured, and the vocabulary exists. Google Cloud’s DORA research programme, which has published the reference survey on software delivery for ten years, defines five measures in its guide: three of throughput, change lead time, “the amount of time it takes for a change to go from committed to version control to deployed in production”, deployment frequency, and failed deployment recovery time; two of instability, the change fail rate, “the ratio of deployments that require immediate intervention”, and the deployment rework rate, unplanned deployments made because of a production incident. What this imposes on a client in Algeria or France: a vendor can be judged on these five figures, and a quote that does not allow them to be measured does not describe a delivery method.

The 2025 DORA report, published on 23 September 2025 from nearly 5,000 responses of professionals worldwide and more than a hundred hours of interviews, says two things that matter for 2027: 90 % of respondents use AI at work, and “unlike last year, we observe a positive relationship between AI adoption on both software delivery throughput and product performance”, but “AI adoption does continue to have a negative relationship with software delivery stability”. In other words, AI tools make more code get written faster, and that code breaks more often in production if the delivery method does not keep up; the 2024 report, according to published summaries, already saw the share of high-performing teams shrink and that of low performers grow year on year, a figure we cite second-hand. What this imposes: in 2027 the question is no longer “how long to write the feature” but “how it reaches production without breaking what worked”, and that is what this guide describes.

The rest is Algerian and appears in no report: the founder in Paris who will see the vendor’s premises twice a year, described in the guide on launching from France; the vendor who goes live by copying files to the server on a Thursday night; the acceptance done “by looking” at the developer’s screen; the database migration run in production with no way back. We have no statistics on these cases; we meet them in most of the projects we take over, and this guide is written against them.

The life of a delivery, in six moments

The method is not described by its tools but by what happens to a batch of work, from the line written in week 1 to a customer’s phone on a Tuesday in off-peak hours.

Figure 1 · Moment 05 is what replaces the trip: the client in France accepts on their phone, at an address that is not production, with scenarios written before the code. Moment 06 is what makes the delivery reversible: what goes live can be withdrawn in minutes, and the database migration too.

The two-week batch is written before the first commit: what will be demoed in a fortnight, in verifiable sentences, with an acceptance scenario for each feature, who does what and what must be seen, validated by the client; it is the same principle the guide on the specification applies to the whole project, brought down to two weeks. Development with tests delivers each feature with its automated tests, unit tests for business rules, integration tests for APIs, end-to-end tests on phones for journeys; a change that fails an existing test does not enter the delivery, and the machine says so, not the client. Review and integration: a second developer reviews every change, and continuous integration builds, tests and deploys to the acceptance environment at every change, from a server, never from someone’s laptop.

The acceptance environment is a copy of production, at its own address, with test data and the same connectors in sandbox mode, that the client opens on their phone from France; what works there will work in production, because it is the same build. Demo and acceptance are the moment that replaces the trip: the client runs the scenarios written in week 1, on the acceptance environment, guided by a short video from the vendor, and accepts or refuses in writing, point by point; what is refused is fixed or moves to the next batch, in writing. Progressive release happens with no downtime, in off-peak hours, first for one shop or a fraction of users, with someone supervising the following hour; if an error or a slowdown rises, rollback is one command, and the database migration, done in two steps, rolls back with it. The version log gets its number and its list of changes, and the next batch is already written.

Delivering an app, in five layers

Behind the six moments, five layers, and the one quotes forget is the fourth.

Figure 2 · The lower-middle layer is the one quotes forget: everyone promises tests, few describe how a delivery rolls back. A vendor who goes live by copying files on a Friday night has built an app, not a delivery.

Requirements and scenarios: the written batch, the acceptance scenarios and the acceptance criteria, drafted before the code; the delivery is accepted or refused against them, and without them acceptance is an impression. Code and tests: unit tests for every business rule, integration tests for every API and connector, end-to-end tests on phones for every journey, and abuse tests, the ones that attempt the cross-tenant leak described in the guide on multi-tenant SaaS or the SMS pumping described in the guide on authentication. Integration and environments: continuous integration that builds and tests every change on a server, a repository in the company’s name, and three environments, acceptance, pre-production, production, each at its own address.

Release is the layer that makes a failed delivery cost ten minutes: zero-downtime, progressive deployment, reversible migrations done in two steps, add before and remove after, and a one-command rollback tested in acceptance before every go-live; it is also what allows updating a hundred customers at once without cutting one off. Supervision and feedback: errors, slowness, alerts, user feedback and version log, what says within the hour whether the delivery broke something, through the same counters the dashboard guide describes for the owner. The tools behind these layers are the ones the DevOps guide names; this guide says what the client sees of them.

«A delivery is a process repeated twenty-four times a year, not an end-of-project event.»

A worked example

An example over one year, with mechanics that do not depend on the assumptions: a commerce app, a founder in France, a team in Algeria.

Figure 3 · The number of rollbacks is an assumption; their duration and the absence of outage are not. Without progressive release, every delivery is a bet on all users at once; with it, a failed delivery touches one shop for ten minutes.

Twenty-four deliveries in a year, one every two weeks, each demoed on the acceptance environment and accepted from France before going live; the first usable version arrived in week 6, not month 6, and the founder made two trips in the year instead of six. Two rollbacks: a slowdown on the stock page after a migration, withdrawn in eight minutes, and a misunderstood discount rule, withdrawn in six, then rewritten into the next batch with its corrected scenario; that is our assumption on frequency, to be measured at home, and what matters is that neither was seen by more than one shop.

Under ten minutes between the signal and the return to the previous version, migration included, is the mechanics, not luck: the previous version is always ready, the migration was done in two steps and its rollback tested in acceptance, and the rollback command is the same at every delivery. Zero visible outage: zero-downtime deployment, in off-peak hours, first one shop for an hour, then all. What the example shows: with the big-bang delivery, the twenty-four batches would have been a single go-live day, every scenario to accept at the same time, and a rollback impossible because the previous version would have had nothing in common with the new one. The assumptions to check at home: how many scenarios per batch, how much time the client really has to accept, and which hour is off-peak for your users; the project’s first week answers them.

Six things the client checks at every delivery, from France

Six checks that require neither being on site nor reading code, and that a client can demand at every delivery.

Figure 4 · None of these six checks requires being at the vendor’s premises or knowing how to read code. A client in France who does them every two weeks knows, at any moment, where their app stands; the one waiting for the big delivery finds out at the end.

The acceptance scenario passes: every scenario written in week 1 is run end to end by the client themselves, on the acceptance environment, from their phone, with a short video from the vendor as a guide; acceptance is written point by point, and a refusal names the failing scenario. Automated tests exist: the continuous integration test report is attached to every delivery, and the number of tests must not go down from one delivery to the next; a vendor who cannot show this report has no tests. The code is in your repository: code, deployment scripts and documentation are in a Git repository in the company’s name, and the delivery is a version tag in that repository, not a file sent over; that is the protection the guide on the app stuck with a vanished developer recommends.

The migration rolls back: the vendor shows, stopwatch in hand, the rollback of a database change on the acceptance environment, without data loss. It works on a real phone: on entry-level Androids, in Arabic and French, on a throttled network, with a capture attached; the acceptance environment opened on the client’s phone in France does not replace this test, because their phone and network are not their users’, as the guide on PWA and native recalls. The version log is kept: every delivery has a number, a list of changes and a date, readable by the client; it is what lets you say “since 1.14, stock is wrong” and return to 1.13 knowingly.

Six situations that break a delivery

Six situations we see on the projects we take over, and what the method does against each.

Figure 5 · The six situations share one remedy: a delivery is a repeatable process, not an event. A vendor who has delivered every two weeks for a year has already met all six; the one preparing their big delivery will meet them all on the same day.

“Works on my machine”: the demo runs on the developer’s laptop, with their database, their files and their connection; online, nothing works the same. Demo and acceptance only on the acceptance environment built by continuous integration, never on a laptop. The big-bang delivery: six months of work delivered at once, everything to accept at the same time, everything breaking at the same time, and no rollback possible; one batch every two weeks, demoed and released, with the first usable version in week 6. The migration that does not roll back: the database change is made in production, the delivery fails, and there is no way back without losing data; two-step migrations, add before, remove after, and every migration with its rollback tested in acceptance.

Acceptance without scenarios: the client “has a look” and says it is fine, and three weeks later the feature is not the one expected; scenarios written before the code, run point by point, written refusal with the failing scenario. Thursday night: release before the weekend, nobody watching, and customers discover the outage on Saturday morning; release in off-peak hours, on a weekday, with someone supervising the following hour, and never on the eve of a holiday nor during Ramadan without planning it. Manual tests only: every new feature breaks an old one nobody re-ran; automated tests on every business rule, replayed at every change, and the machine refuses before the client. All six share one remedy: delivery is a process repeated twenty-four times a year, not an event.

«What goes live must be withdrawable in ten minutes, migration included; otherwise it is not a delivery, it is a bet.»

Seen elsewhere: DORA, and what transposes

Two public texts say the essentials. The DORA metrics guide gives the vocabulary: change lead time, deployment frequency, recovery time, change fail rate, rework rate; what transposes is that these five figures are asked of a vendor the way references are asked, and that a team delivering every two weeks for a year can give them, while a team preparing its big-bang delivery has none. The 2025 report says AI speeds up writing code and weakens delivery when the method does not keep up; what transposes is that automated tests, continuous integration and rollback matter more in 2027 than in 2024, because code arrives faster and must be held more firmly.

What does not transpose as is: DORA measures teams that sometimes deploy several times a day, for global products; a commerce app in Algeria does not need to deploy ten times a day, it needs to deploy every two weeks without breaking, and a client in France who can check it. What these texts do not say: which hour is off-peak for your users, how many scenarios fit in a batch, and who, on your side, has three days to accept; the project’s first week answers that.

The rules of a delivery that holds

Six rules, written in the first week and reread at every delivery. The batch is written before the code, with its acceptance scenarios validated by the client; what is not written will not be accepted. Every feature arrives with its tests, and a failing test blocks the delivery, by the machine, before the client. Acceptance happens only on the acceptance environment, built by continuous integration, never on a laptop nor in production. Nothing goes to production without written acceptance, point by point, and what is refused moves to the next batch, in writing. Every release is progressive and reversible: off-peak hours, one shop first, one-command rollback, two-step migrations, never on the eve of a holiday. Code, scripts, environments and accounts are in the company’s name, and the delivery is a tag in its repository.

A seventh rule concerns the quote: “tests and acceptance” is not a method, it is a sentence; the method reads “a batch demoed every two weeks on an acceptance environment accessible to the client; automated tests delivered with every feature, report attached; written acceptance before any release; progressive release with rollback in under fifteen minutes, migration included, demonstrated at every delivery; repository and environments in the client’s name”, and it is checked from the first delivery. A quote that prices “acceptance” as a final three-week phase has priced the big-bang delivery, with what it costs afterwards, described in the guide on keeping an app alive.

Six projects, what is delivered and what is accepted

Six projects we often deliver, and for each what a two-week batch contains and what the client accepts.

The offline field app, described in the dedicated guide. Acceptance in airplane mode on a real phone: enter, cut the network, turn it back on, check nothing is lost or duplicated; release shop by shop.
The portal or marketplace. Acceptance of ordering and payment journeys in sandbox, from France; release in off-peak hours with a fraction of visitors first.
The AI agent on WhatsApp, described in the dedicated guide. Acceptance on a test number with written conversation scenarios, handover to a human included; release for a batch of customers first.
The integration with accounting, described in the dedicated guide. Acceptance by the accountant on test entries; first flow two weeks in parallel with manual entry before it stops.
The multi-tenant SaaS. Acceptance on a test tenant, cross-tenant leak test attached to every delivery; release in waves of customers, reversible migrations demonstrated.
The owner’s dashboard. Acceptance of the ten figures against the accountant’s over a month; release without touching the tills, with the Monday report kept until acceptance.

The two-week batch, day by day

The calendar is that of a fourteen-day batch, repeated twenty-four times a year, three days of which belong to the client.

Figure 6 · Fourteen days, and the same cycle repeats twenty-four times a year. Days 9 to 11 belong to the client in France: three days to accept on their phone, without a trip. What is not accepted by day 12 does not go to production; it is rewritten into the next batch.

Day 0 to 1 writes the batch and its acceptance scenarios, validated by the client before the first commit; it is the day that decides whether acceptance will be a check or an impression. Days 1 to 8 develop, every feature with its tests, continuous integration building and testing at every change and updating the acceptance environment daily, so the client can look before the end if they wish. Day 8 to 9 is review and freeze: review by a second developer, no new feature after day 9, only fixes. Days 9 to 11 belong to the client: three days to run the scenarios from France, on their phone, and accept or refuse in writing, point by point.

Day 11 to 12 fixes the refused points and has them re-accepted; what does not fit the deadline moves to the next batch, in writing, and does not go to production. Day 12 to 13 is the progressive release, in off-peak hours, one shop or a fraction first, with rollback ready and someone supervising. Day 13 to 14 supervises the version, collects feedback, updates the version log and writes the next batch. Over the year, this cycle is what replaces four of the founder’s six trips described in the guide on launching from France: the two that remain serve to meet customers, not to check on the vendor.

What makes a delivery fail

The projects we take over almost always failed at delivery for one of these reasons.

The big-bang delivery. Six months with nothing going live, then everything at once; everything breaks, and nothing rolls back.
The demo on the developer’s laptop. What the client saw exists nowhere else.
No automated tests. Every delivery breaks an old feature; the client becomes the tester, remotely, without scenarios.
The irreversible migration. The database changed, the delivery failed, and the only way out is to fix in production, at night.
The Thursday-night release. Nobody watching, and customers discover the outage on Saturday.
The repository at the vendor’s. The delivery is a file sent over; the day the vendor stops answering, the previous version is lost.
The client who does not have three days. Acceptance is signed without being done; the refusal comes a month later, when the next batch has already built on it.

Frequently asked questions

The questions we receive from founders settled in France, managers in Algeria and teams taking over a project.

I am in France. How do I check the work without travelling?: Through the acceptance environment, at its own address, which you open on your phone, and through the scenarios written before the code that you run yourself every fortnight; the test report, access to the Git repository and the version log complete it. The year’s two trips serve to meet your customers, not to watch the vendor.
Every two weeks, is that not too often?: It is what keeps every delivery small, hence acceptable in three days and reversible in ten minutes. A delivery every six months is big, hence impossible to accept fully and impossible to roll back. The rhythm holds if the batch is written before the code and the tests are automated.
What happens if the release breaks something?: The previous version is always ready, the database migration was done in two steps and its rollback tested in acceptance, and the rollback is one command: under ten minutes, and only the first shop or the first fraction of users saw the problem. The batch is then fixed and re-accepted before going out again.
How do I know the tests really exist?: The continuous integration test report is attached to every delivery, with the number of tests and their result, and that number must not go down; the vendor can also show, in acceptance, a deliberately wrong change refused by the machine. A vendor who can show neither has no tests.
Can we go live during Ramadan or before a holiday?: Not on the eve of a holiday, and during Ramadan only in your users’ real off-peak hours, which are not those of the rest of the year; the rule is that a release happens when someone can supervise the following hour and your users are few.
What must the quote contain on this point?: A batch demoed every two weeks on an acceptance environment accessible to the client; automated tests delivered with every feature and their report; written acceptance before any release; progressive release with demonstrated rollback; repository and environments in your company’s name. A quote that prices acceptance as a final three-week phase describes the big-bang delivery.