Tests Avant Lancement pour un Logiciel Sur Mesure : Pourquoi les Dernières Semaines Doivent Être Consacrées aux Tests, Pas à de Nouvelles Fonctionnalités

Pre-Launch Testing for Custom Software Is Not the Same Job as Building It

Pre-launch testing for a custom software platform means something narrower than "QA": it means proving, before real customers touch the system, that the handful of flows where money moves, a commitment gets made, or a confirmation gets sent will not silently fail. Most custom builds do not fail at launch because a button is the wrong shade of green. They fail because a payment retried twice, a booking looked confirmed on screen but never reached the backend, or a receipt email landed nowhere. Those are not edge cases a QA pass finds by accident. They are the specific, small set of flows that deserve the last weeks before launch, on purpose, instead of one more feature.

The instinct on almost every custom build runs the other way. There is a deadline, a stakeholder who wants one more capability before "go live," and a team that has spent months in build mode and does not naturally downshift into break-it mode. The result is a platform that demos well on the day of the walkthrough and behaves unpredictably the first week real users, real cards, and real inboxes touch it.

None of those three numbers is about a platform that never launched. They are about platforms that did launch, with a payment step, a checkout step, or a data-quality problem that nobody hardened before real traffic arrived. The cost of poor software quality in the US reached an estimated $2.41 trillion in 2022, with roughly $1.52 trillion of that sitting in accumulated technical debt, according to the Consortium for Information and Software Quality's 2022 report. That is not a hypothetical. It is what happens across an economy's worth of software that shipped before its critical paths were proven.

The Feature Freeze: Why the Last Weeks Should Add Zero Scope

A feature freeze means exactly what it sounds like: for a defined window before launch, the team stops adding anything new and puts every hour into proving what already exists works under real conditions. On a project we're currently taking through this phase, a marketplace-style platform moving from prototype toward its first real users, the team set August aside as exactly that: no new capabilities, full ownership of end-to-end testing, and a single goal, reaching "user-ready" reliability before the platform opens to its first cohort in September.

The freeze is not a testing tip. It is a sequencing decision, and it is the one most teams skip under deadline pressure, because adding a feature feels like progress and testing an existing one feels like standing still. That instinct is backwards. A feature nobody has stress-tested is not a finished feature; it is an unverified claim about what the software does, and every additional claim added during the freeze window is one more thing that has to be tested from scratch on top of everything already queued.

The discipline that makes a freeze work is ownership, not just a calendar block. On the project above, the delivery team took direct ownership of testing and of aligning the build against the working prototype, rather than leaving verification to whoever happened to be free, with a technical lead available for anything that needed deeper diagnosis. A freeze without a named owner turns into a freeze in name only, because "everyone tests it" is functionally the same as no one does.

Critical Path vs. Everything Else: A Framework for Triage

Not every flow in a custom platform deserves the same scrutiny before launch, and treating all of them equally is how testing time gets spent on the wrong things. The useful split is not "important" versus "unimportant" screens. It is critical path versus everything else, and critical path has a specific, checkable definition: any flow where a failure breaks a promise the business already made to a person, rather than just degrading their experience of using the product.

Three questions identify a critical-path flow. Does money move, or get promised to move, in this step? Does the user make a commitment here, a booking, an order, a signed agreement, that they will reasonably expect the business to honor? And does a confirmation, a receipt, an email, a calendar invite, need to reach them proving that commitment was recorded? A flow that answers yes to any of those three is critical path. A flow that answers no to all three, a profile page rendering slightly wrong, a filter that's missing one option, a dashboard chart with an off color, is a real bug worth fixing, but it is not the bug that costs a business its first users' trust.

On the marketplace project, that triage produced a short, explicit list, not a vague sense of "test everything hard": the buyer request flow, including the calendar-based scheduling step; payment processing; and the transactional email layer confirming both. Backend data integrity underneath all three was treated as its own item, because a flow that looks correct on screen while writing bad data underneath is arguably worse than one that visibly fails, since nobody notices until a customer disputes something weeks later.

What to Actually Test in Each Critical Flow

Naming the critical path is the easy part. What actually gets tested inside each one is where most teams under-scope, because the obvious happy-path test, "does the payment go through," passes on the first try and creates false confidence.

Payment Processing

The happy path, a valid card charged once for the correct amount, has to work, but it is the least informative test in the set, because it is also the path every demo already ran successfully a dozen times. What actually breaks in production: a user who double-clicks "pay" and gets charged twice because the request wasn't idempotent; a webhook confirming payment that arrives late or out of order relative to the page redirect, leaving the platform's internal state briefly, or permanently, wrong about whether the payment succeeded; a card that's declined mid-flow, leaving a half-created order in the database instead of a cleanly rejected one; a currency or rounding mismatch between what the user saw and what got charged.

Scheduling and Calendar Commitments

A booking flow's real failure mode is rarely "the calendar doesn't load." It is the calendar showing a slot as available that a concurrent request already claimed, producing a double-booking neither party discovers until one of them shows up. Testing this means deliberately running two booking attempts against the same slot at close to the same time and confirming the system rejects one of them cleanly, not just testing the flow in isolation with no contention.

Transactional Email

The test that matters is not "does the email get sent." It is "does the email arrive, in the right inbox, in a reasonable time, and does it match what actually happened." An email queue that silently drops messages under load, a confirmation that goes out with yesterday's data because of a caching bug, or a message that lands in spam because a sending domain was never properly authenticated all pass a naive "email sent successfully" check while failing the only thing that check exists to verify.

Backend Data Integrity

This is the layer that determines whether the first three actually matter, because a payment, a booking, and a confirmation email can each individually "succeed" while writing inconsistent records underneath, a payment marked complete against a booking that was later cancelled, or a confirmation sent for a slot that a database race condition quietly reassigned. Testing this means reconciling the record a user would see against the record the backend actually holds, deliberately, after the flows above have been run under contention, not just checking that each API call returned a 200.

Why This Gets Skipped, and Who Should Own It

Critical-path testing gets skipped for an ordinary reason: it is invisible when it goes well and only becomes visible, urgently, the first time a real customer hits the gap. Nobody budgets extra time for the demo that already worked. The cost asymmetry is what makes it easy to underinvest in. Every day the untested flow behaves correctly costs nothing extra. The first day it doesn't, the cost lands all at once, as a charged-twice customer, a no-show at a double-booked slot, or a support inbox full of "did my payment go through?" messages with no clean way to answer.

Who owns this work matters as much as whether it happens. Leaving critical-path testing entirely to the client, or to whichever stakeholder is closest to launch pressure, tends to produce testing that covers the flows someone remembered to check, not the flows most likely to fail under real contention. The delivery team building the system is the one positioned to design tests that deliberately create the conditions, concurrent requests, slow networks, declined cards, that a walkthrough never reproduces. That does not mean the client has no role. It means the split works best when the delivery team owns the technical hardening and the client owns validating that the tested behavior actually matches what the business needs the flow to do.

Italian SMEs building their first digital sales or booking channel are, more often than not, doing this for the first time, which is exactly why the gap matters here specifically. As of 2025, only 14.7% of Italian enterprises with 10 or more employees conducted online sales at all, according to Istat's "Imprese e ICT" report published in December 2025. For a business crossing that line for the first time, a critical-path failure in the first month is not a minor incident to absorb and learn from. It is frequently the only data point early customers ever get about whether the new channel can be trusted, and it shapes word of mouth in a market where that first impression travels fast.

A Pre-Launch Checklist for SMEs Evaluating a Delivery Partner

An SME commissioning a custom platform is rarely in a position to audit the code directly. What it can do is ask specific, checkable questions before the final weeks of a project, rather than trusting a general assurance that "we test everything."

• Ask for the critical-path list, by name. A partner who can immediately name the two or three flows where money, commitments, and confirmations intersect has already done the triage. A partner who says "we test the whole platform thoroughly" without naming anything specific hasn't.
• Ask how concurrency gets tested, not just correctness. "Does the payment work" and "does the payment still work when two people try to book the same slot at once" are different questions, and only the second one predicts real-launch behavior.
• Ask who owns the freeze. A named owner for the pre-launch testing phase, distinct from "the whole team," is the difference between a real freeze and a soft deadline that quietly slips back into feature work.
• Ask what happens when a test fails. A partner with a clear answer, a fix, a re-test, a documented resolution, is different from one whose answer is "that hasn't come up yet" this close to launch.
• Ask to see the confirmation, not just the transaction. A payment that clears and an email confirming it are two separate systems that both have to work; ask specifically whether both were tested together, under the same conditions, not just independently.

The same evaluation discipline applies more broadly to choosing any implementation partner, not just for the testing phase specifically; our guide on how to evaluate an AI implementation partner covers the questions worth asking earlier in the relationship, before a project ever reaches its final weeks. And the same principle that makes critical-path testing effective, mapping what the process actually does rather than what it's assumed to do, is the same discipline covered in why the documented process is rarely the real one: a test plan built from an idealized flow diagram misses exactly the contention and edge cases that a test plan built from watching the system actually run under load will catch. Getting from a working prototype to something production-ready is also its own discipline worth planning for explicitly, which our piece on scaling a startup's architecture from prototype to production covers from the infrastructure side, as a companion to the testing discipline covered here.

Frequently Asked Questions

How long should a feature freeze last before launch?

It depends on how many critical-path flows the platform has and how much contention testing each one needs, but a useful floor is long enough to run each flow under deliberately adverse conditions, concurrent requests, declined payments, slow networks, and fix what breaks, then re-test. For a platform with a handful of critical flows, that is commonly measured in weeks, not days; treating it as a one-day pass before launch almost always means the contention cases never get exercised at all.

What's the difference between QA and critical-path testing?

QA, as most teams practice it, checks whether features work as specified across the whole platform, including screens and flows with no financial or commitment consequence if they're slightly wrong. Critical-path testing is a deliberately narrower, deeper pass on the small number of flows where a failure breaks a promise to a customer rather than just degrading their experience, and it specifically tries to create the contention conditions, concurrent access, network failure, partial completion, that a general QA pass doesn't reliably reproduce.

Can a small team really own end-to-end testing themselves, or do they need a dedicated QA hire?

Team size matters less than whether testing has a named owner and a defined scope. A small delivery team that has explicitly triaged its critical path and blocked real time against it can cover the flows that matter without a dedicated QA hire; a larger team with no owner and no triage can still ship an undertested critical path, because "everyone's responsibility" tends to mean the contention cases nobody thought to check simply don't get checked by anyone.

Why test transactional email as carefully as payments?

Because a customer's only proof that a commitment was recorded is often the confirmation they receive, not anything visible inside the platform itself. A payment that clears silently, with no confirmation reaching the customer, produces the exact same support burden as a payment that failed: a customer who cannot tell whether it worked and has no record to point to if it didn't.

What's the single most common critical-path failure you see in first launches?

A race condition around a shared resource, most often a booking slot or an inventory count, that two requests can both claim successfully because the check-and-reserve logic wasn't tested under concurrent access. It passes every single-user test cleanly and only shows up the moment two real customers act at close to the same time, which is exactly the condition a launch, by definition, introduces for the first time.