We conceived, built and still run LutinRouge.

There was no template to start from. The domain was modelled from nothing: what a contract is, how attendance relates to it, what an invoice may and may not charge for, which documents expire and what happens when they do, and who in a group operator is allowed to see whose data.

Childcare software looks simple from outside. It is a scheduling, billing and compliance system with no tolerance for being wrong, used by people who did not choose a career in software. That is decided in specification, not in code. An ambiguity left in a spec becomes a billing dispute with a parent eleven months later.

So specifications are written to be executable: precise enough that an agent can build against them without inventing behaviour, and structured enough that a human who has to sign off can actually review them. That standard is not an aesthetic preference. It is the precondition for everything in Phase 3. Agents cannot compensate for a vague requirement; they multiply it.

A Symfony back end and API carry the domain. Flutter builds both mobile applications: the one staff use on the floor and the one parents hold to follow their child's day, message the team and receive invoices. Realtime messaging connects settings and families. The infrastructure is ours to run.

Three architectural constraints shaped the rest. Per-tenant isolation, because a group operator needs shared administration and roll-up reporting that never leaks between its own settings. The largest runs roughly twenty sites from one account structure. Billing that reconciles, because invoices are computed from contracted hours against recorded attendance and a parent notices an error immediately.

And time. The platform runs from mainland France to New Caledonia, French Guiana, Martinique, Algeria, Côte d'Ivoire, Senegal and Madagascar. Eight time zones means “today” is not a fact the server can assume: it has to be resolved per setting, on every query that touches a day. That is an architectural decision made once, early, and paid for in every date-bounded feature since.

Development runs through ATLAS, the delivery system we built for our own engineering: specialised agents driven through a fixed pipeline with mandatory human gates. A human merges. Always. ATLAS never merges, never pushes to a protected branch, never force-pushes, enforced as hard denials in a permission layer rather than as instructions in a prompt.

That matters more here than on most products. Every change reaches families' contracts, invoices and children's records, so the standard is not "does it work" but "can it be defended", and LutinRouge is one tenant among several the same pipeline serves.

Integration belongs to this phase rather than a later scramble: Stripe for billing, Twilio for the messaging channels families actually use, and a document pipeline that knows what expires and when.

We run it: infrastructure, deployments, incidents. Consultancies recommend architectures they will never have to operate. When a deployment goes wrong at seven in the morning, nurseries cannot open and parents cannot see their child's day, and it is our phone that rings.

The eight-zone spread above is also an operational fact: across those settings there is no hour when the platform is idle, so there is no natural maintenance window to hide a risky change in. Deployment has to be uneventful by design, which is a constraint on how Phase 3 works rather than a matter of choosing a quiet time.

A platform serving thousands of parent accounts receives questions all day, and they arrive on whatever channel the sender already uses: email, WhatsApp, SMS, voice notes, photographs of documents. Nobody installs a support portal to ask what time the crèche opens.

Weiwei is an n8n-orchestrated agent sitting across every inbound channel, working at two tiers with two different jobs. At tier 1 it answers — functionality, navigation, opening calendars, how-to — multimodal by necessity rather than ambition. At tier 2 it stops answering and assists: with direct access to platform data, it assembles the relevant contract, attendance and invoice context and proposes an answer, so the human replies faster and gets it right first time.

The three misses were all the same failure, which is more useful than three unrelated ones: ordinary behaviour written up as a confirmed bug. So the weakness is not in answering, it is in classifying, and the fix is a guardrail rather than a better model: describe the symptom, do not assert a bug or a priority, let triage decide.

The hard part was never the language model. The two tiers need opposite dispositions from one system: conservative to the point of unhelpfulness at tier 1, where a confident wrong answer about a medical document does real damage, and expansive at tier 2, precisely because a human validates before anything reaches a family.

And the point was never deflection. One in four requests never reaching a person means the team has time to talk to clients about the things only a person can do, the first work to disappear when a queue grows.