When a recall is announced, the website has to already exist. The announcement date is set by regulators, lawyers, and press schedules, and it does not move because a build is running late. That constraint shapes every engineering decision on these projects.
This is how we get a recall portal fully live in production, on the client domain, in under 24 hours. Under 24 hours means taking real consumer traffic, not a staging link. The condition is that the client supplies recall copy, affected-product data, and DNS access at intake.
We do not start from zero
The single reason the window is achievable is that the hard parts are already built and already tested. Lookup, multi-stage forms, upload handling, notifications, the admin side, and the entire security layer exist as a hardened foundation. Each recall configures and extends it.
What actually varies between recalls is smaller than it looks: the identifier scheme, the affected-product dataset, the remedy flow, the copy, the languages, and the markets. That is a configuration problem, not a greenfield build, and treating it as a greenfield build is why templated agency projects take three weeks.
The lookup is the whole product
Everything else on a recall portal is supporting cast. If the lookup is wrong, consumers who are affected conclude they are not, and that is a safety failure rather than a UX one.
Identifier schemes differ more than people expect. A VIN has a check digit, so a typo can be caught before it returns a false negative. A serial number usually has a format but no checksum, so the best you can do is validate shape and offer correction. A lot code often maps to a production window rather than a discrete value, which makes the lookup a range query. Getting this wrong is the most consequential mistake available on the project.
The result design matters as much as the matching. There are three outcomes, not two, and the third is the one that decides your contact centre volume.
- Affected: state it plainly and move straight into the remedy flow.
- Not affected: state it plainly, and say what to do if they still have concerns.
- Cannot determine: the identifier was not recognised, or the data is incomplete. This needs its own path, usually guided identification with reference photography showing where the code is printed, and a fallback that lets the consumer upload a photo.
Most recall sites collapse the third case into "not affected". Every consumer in that bucket then phones you, and some of them are affected.
Enumeration is the threat that is specific to recalls
A lookup endpoint is an oracle. Ask it about an identifier and it tells you whether that identifier is in the affected set. That is the entire purpose of the page, and it is also the vulnerability.
Undefended, an attacker walks the identifier space and reconstructs the affected-product list. For VINs that is close to a list of identifiable vehicles and, by extension, owners. For consumer products it is commercially sensitive volume data that competitors and journalists both want. This was an explicit requirement on the automotive recall we built.
Defence is layered, because every single measure on its own is defeatable.
- Rate limits on several dimensions at once: per IP, per session, per identifier, and per endpoint. A per-IP limit alone is defeated by any distributed scraper.
- Exponential backoff, so sustained probing becomes progressively more expensive.
- Response shaping, so a hit and a miss are indistinguishable in timing and payload size. Otherwise the timing difference alone leaks the answer.
- Sequential-pattern detection. Enumeration does not look like human behaviour, and consecutive or structured identifier probing is a strong signal on its own.
- Bot challenges that escalate only for suspicious sessions, so real consumers are never made to prove they are human.
The announcement spike and the attack look similar
The highest-traffic hour of the entire programme is the hour after the announcement, and it is also the hour an outage does the most reputational damage. At the edge, a legitimate flood of consumers and a volumetric attack have a similar shape.
So the rules have to shed one while passing the other. We run DDoS mitigation and a WAF in front of the origin, with a managed ruleset plus rules written for this specific portal covering injection, cross-site scripting, path traversal, and abuse patterns particular to lookup and claim endpoints. Static content is served from the edge, the dynamic surface is deliberately small, and we load test against the spike the announcement will actually create before anything goes live.
Two deployments, not one server with a language switcher
A recall that crosses the Atlantic is not one recall. The regulator differs, the remedy differs, the languages differ, and the rules on where consumer personal data may be stored differ.
We deploy per region on independent infrastructure, with storage, processing, backups, and logs pinned to that region, so EU consumer data never transits US systems. This is straightforward to do on day one and genuinely painful to retrofit once a portal is live and holding real records. Both regions go live in the same window.
The portal runs on the client domain or a dedicated recall subdomain, with TLS issued and auto-renewing. Consumers acting on a safety notice are already primed to suspect a scam, and an unfamiliar third-party URL measurably depresses response rates.
Where AI actually saves hours, and where it does not
AI is a real part of how we hit the window, and it is worth being precise about which parts, because the honest answer is narrower than most claims.
It is genuinely fast at the mechanical work: form scaffolding from a field specification, validation rules, locale files, first-pass translations for review, realistic test data across the identifier space, and content variants per market. That work is high-volume, low-judgement, and easy to verify, which is exactly the profile where it pays. It is also useful for a review pass across accessibility, copy consistency, and validation coverage, which catches the class of mistake a compressed timeline normally introduces.
What it does not do is decide the security model. The lookup matching logic, the enumeration threat model, the WAF rules, the encryption boundaries, and the data residency design are engineered and signed off by people. Generated code does not reach production unreviewed.
“A recall portal is not the place to find out that nobody read the generated code.”
The 24 hours, in order
- Hour 0, intake: recall scope, affected-product identifiers, remedy type, regulator, target markets, and the domain.
- Hours 1 to 6, build: lookup logic against the affected-product data, registration form, remedy flow, and copy in every language the recall covers.
- Hours 6 to 14, harden: WAF rules, rate limits, enumeration defence, bot filtering, and a load test against the expected spike.
- Hours 14 to 20, review: legal, brand, and regulatory sign-off on a live staging URL, with revisions turned around in the same session.
- Under hour 24, live: DNS cutover, TLS issued, monitoring and alerting armed, real traffic.
The review window is the one clients underestimate. The build is rarely the constraint. Getting legal, brand, and regulatory to agree on wording is, which is why we put a live staging URL in front of them at hour 14 rather than a document.
What happens after launch
Recalls expand. New models come into scope, a second market opens, the remedy changes, or a supplier discloses a wider batch range. Because the portal is configuration over a tested foundation, an expansion goes live in hours rather than becoming a new project at the worst possible moment.
The other half of the work is data: registration volume, remedy mix, geography, completion rates, and where consumers drop out of the funnel, flowing into the client’s own systems under encryption and into the effectiveness reporting the regulator will ask for.
More detail on the full capability set is on our product recall portal development page, and the two engagements referenced here are written up as the automotive recall portal case study and the medical device recall patient portal case study.