We built a page builder by accident, while fixing something else. Notes on why it did not become a second reliability story, and where the actual engineering was.
Not every advertiser's leads come from a Facebook form. Some run a landing page — built in Tilda, WordPress, hand-coded — with their own form, and that form needs to feed the same CRM, the same Telegram alert, the same retry logic as everything else. We already had that pipeline for ad leads: webhook capture, a durability boundary before acknowledgement, retry classification, per-destination delivery. The question that led here: if a page owner has to submit through our webhook anyway to get those guarantees, why not let them build the page here too, instead of wiring up a separate tool?
Not a general website builder — a landing page for one job: capture a lead and hand it to the same pipeline. Pages are stored as a block model (a JSON structure describing sections, not a rich rendering framework) and published as static HTML. Static is the deliberate choice: fewer moving parts, and a page that loads instantly on the kind of mobile connection our actual users' customers browse on.
A submission on that page does not go through a different pipeline than a Facebook lead does. It calls the same lead-ingestion path, with a stable per-site identifier so retries and duplicate detection behave identically to everything else. Building this as a fork of the reliability logic would have meant maintaining two versions of "how do we guarantee a lead is not silently lost" — we built it as one path with two front doors instead. The Lead Ads reliability page covers what that path actually guarantees; a site lead gets it automatically.
Publishing under our own domain is easy. Letting a customer use their own —
landing.theirbrand.com — is where the actual engineering was,
because now you own a promise you do not fully control: their DNS has to point
correctly, a certificate has to exist and stay valid, and any failure in either
shows up to their customers as a broken page, not as an abstract
platform issue.
A single wildcard certificate covers every page on our own shared subdomain space. We do not trust that it is valid just because it was issued — a monitor opens a real TLS connection to a live hostname under it on a schedule and reads the certificate back, checking days-until-expiry against an actual handshake rather than against a renewal log that could itself be wrong.
A customer's own domain has its own certificate lifecycle, entirely separate from ours. The same connect-and-read check runs against every active custom domain, because "our cert is fine" tells you nothing about the ten other domains pointed at the platform by customers who are not thinking about TLS at all — and will not be, until their page goes down.
No visual drag-and-drop editor with arbitrary layout freedom — that is a different, much larger product to build and maintain well. No CMS-style content versioning. The block model is intentionally constrained: enough to build a genuinely good landing page for a lead-gen offer, not enough to become a general website builder competing with tools whose entire business is that problem.
The reason is that it never introduced a second reliability story. Every guarantee a Facebook lead gets — durability before acknowledgement, retry classification, honest delivery status — a landing-page lead gets automatically, because it is the same code path with a different front door. If we had built the page tool as a bolt-on with its own submission handling, we would now be maintaining two answers to "did this lead actually arrive," and one of them would eventually be wrong.
All of this runs in production at Targenix — free Facebook and Instagram lead automation for Uzbekistan, including a landing-page builder with custom-domain hosting, at no cost.