Custom Domains: The Hidden Engineering Quarter

A founder's account reveals the extensive, non-obvious engineering effort required for custom domain implementation, a feature often underestimated by SaaS builders.

Jonathan Geiger told a friend that adding custom domains to a SaaS product would take "two weeks." That friend, Geiger reports, was still working on it two months later. This underestimation, a mistake Geiger claims he made himself three years prior, highlights the hidden engineering burden of a feature often perceived as a simple customer convenience.

Multi-tenant TLS and ACME Flows

The initial hurdle involves multi-tenant TLS termination, requiring a unique certificate for each customer hostname. This process quickly encounters Let's Encrypt rate limits, which Jonathan_Geiger specifies as 50 new certificates per registered domain per week, 5 duplicate certificates per week, and 300 pending authorizations. Exceeding these limits can halt customer onboarding for days, directly impacting growth. To manage this, an ACME on-demand flow is necessary. This system issues certificates not in advance, but upon the first Server Name Indication (SNI) hit. This approach requires a real-time check with the control plane to validate the hostname before Let's Encrypt issues the certificate, a critical step to prevent an attacker from exhausting rate limits through malicious requests.

DNS Validation and Certificate Renewal

Once a customer provides a hostname, the system must issue a CNAME record and continuously poll DNS until it resolves. Jonathan_Geiger notes a common pitfall: Cloudflare caches NXDOMAIN responses for 30 minutes, creating a discrepancy with public resolvers and leading to debugging delays during setup. ACME certificates expire every 90 days, necessitating a robust, automated renewal worker. This worker requires retry logic, exponential backoff mechanisms, and per-customer failure alerts, as Jonathan_Geiger emphasizes that renewals will inevitably fail for some customers, requiring specific attention.

Detecting DNS Drift and Edge Routing

A significant operational challenge is DNS drift, where a customer might enable a service like Cloudflare proxying 60 days after initial setup. This action can silently break certificate renewal, leading to certificate expiration and service disruption. Detection often occurs only when customers report 404 errors to support. Furthermore, every customer request must pass through an edge router. This router looks up which tenant owns the incoming hostname and then reverse-proxies the request to the correct backend. This additional hop introduces a critical latency budget that must be managed for performance across all customer interactions.

Scaling Monitoring Operations

At small scales, such as 50 customers, a simple cron job can check each domain's status. However, scaling to 5,000 customers renders this manual approach unfeasible. Jonathan_Geiger describes building a dedicated monitoring fleet with sampling techniques, alert ladders (e.g., escalating notifications 30, 7, and 1 day before expiry), and automated DNS drift detection. This operational overhead extends to dedicated internal communication channels, such as a Slack channel named #domains-on-fire, established to manage the inevitable failures and alerts. Jonathan_Geiger states that these components collectively represent "a quarter of engineering, then ongoing care forever," underscoring the long-term resource commitment.

The core lesson from Jonathan_Geiger's experience is that a seemingly simple feature can consume significant engineering resources. While his detailed breakdown serves as a comprehensive guide for those committed to building this in-house, the primary modification for most founders today would be to outsource this infrastructure. Jonathan_Geiger himself eventually built Domainee.dev to solve this recurring problem, indicating that a dedicated solution can abstract away the complexity.

For a founder launching a new SaaS product, allocating a "quarter of engineering" to custom domain management is a substantial opportunity cost. This time could instead be spent on core product features, sales, or customer acquisition. Relying on a specialized service mitigates the risk of hitting Let's Encrypt rate limits, simplifies DNS validation and renewal, and offloads the burden of building and maintaining a monitoring fleet. The cost of such a service must be weighed against the ongoing engineering time, the potential for customer churn due to outages, and the distraction from building the core business. This shift from build to buy is particularly relevant for bootstrapped or early-stage startups where engineering bandwidth is limited.

The promise of custom domains as a standard SaaS feature belies an intricate backend. Jonathan_Geiger's account underscores that what appears to be a minor addition can become a foundational platform engineering project, demanding continuous attention and resources. Founders must recognize that the user-facing simplicity of a feature often masks substantial infrastructure complexity. The decision to build or buy such components dictates not only initial development timelines but also long-term operational overhead and strategic focus.

The investor read

The detailed account of custom domain implementation highlights a persistent, under-addressed infrastructure burden within the SaaS ecosystem. This problem represents a clear market opportunity for specialized platform-as-a-service (PaaS) providers that abstract away complex certificate management, DNS orchestration, and edge routing. Investors should note the recurring "build vs. buy" decision for features like custom domains; companies that choose to build in-house incur significant, ongoing engineering costs that detract from core product development and market expansion. Solutions like Domainee.dev (built by Jonathan_Geiger) or similar offerings from Cloudflare or Netlify indicate a maturing infrastructure layer. The ability to offload such non-differentiating, complex features can be a competitive advantage for lean SaaS startups, allowing them to accelerate time-to-market and focus capital on customer acquisition or unique IP.