Build vs buy

Custom domains are not just a CNAME.

The first successful request proves the path. Production requires a durable domain model, ownership checks, certificate operations, strict routing, lifecycle statuses and failure recovery.

This guide compares responsibilities, not headline feature checklists.

Customer experienceYour productDomain lifecycle modelResource + status APIDNS ownershipChecks + retriesCertificate lifecycleIssuance + renewalEdge routingHostname allowlist + origin
Frame the decision

Choose what your team should operate for years.

Building can be rational when custom-domain infrastructure is strategically differentiating and an existing edge team already owns its failure modes. Buying is rational when the customer experience matters more than the certificate pipeline beneath it.

Building deserves consideration when…

  • You already operate a programmable edge and ACME pipeline.
  • Domain infrastructure is a core product differentiator.
  • A named team owns renewals, abuse controls and incident response.
  • Your requirements cannot fit a managed HTTPS routing boundary.

A managed layer deserves consideration when…

  • You want to ship the product workflow without creating an edge team.
  • Customers need precise states rather than internal infrastructure detail.
  • Your application already exposes a stable public HTTPS destination.
  • You prefer an API and event contract over proxy configuration.
Operational surface

Compare the work that remains after launch.

“Included” means subdomain.to owns that infrastructure responsibility. Your product responsibilities remain explicit.

CapabilityBuild internallyWith subdomain.to
Domain resource and state modelDesign, migrate and maintain itUse the API resource
DNS ownership verificationOperate polling and retry workersRead the verification state
Certificate issuance and renewalOperate ACME, storage and renewal recoveryManaged lifecycle
Hostname allowlist and HTTPS routingProgram and audit the edgeRegistered hosts routed to your destination
Creation and deletion webhooksBuild delivery, signing and replay behaviorConsume hostname.created and hostname.deleting
Customer onboarding and authorizationYour product owns itYour product still owns it
Tenant isolation inside the applicationYour application owns itYour application still owns it
If you build

The work is a loop, not a launch checklist.

Each domain continues to change after activation. Model pending_dns → validating → provisioning → active, the exception states misconfigured, failed, suspended and deleting, plus separate DNS, certificate and routing statuses.

Infrastructure lifecycleportal.acme.eu
01 · Resource contract

Every hostname starts with an owner.

business_key
tenant_42 · portal
status
pending_dns
02 · DNS ownership

Activation waits for a precise DNS answer.

CNAMEportal.acme.euin.subdomain.to
dns_status
validating
next check
provider-aware retry
03 · Certificate

Issuance is a durable operation, not a request.

certificate
provisioning
renewal
scheduled
04 · Edge inventory

Only the accepted hostname reaches the origin.

route
registered host only
unknown host
HTTP 421
05 · Observable system

Support sees the layer that needs action.

DNSverifiedTLSissuedRoutelive
webhook
hostname.created
overall
active
06 · Safe teardown

Deletion removes the route before it becomes stale.

status
deleting
final state
resources removed
What buying does not outsource

Keep the product boundary honest.

A managed domain layer removes infrastructure work. It does not make customer authorization, tenant isolation or origin reliability someone else’s product decision.

You still ownsubdomain.to owns
Who may claim a hostnameHow DNS ownership is verified
The customer-facing setup flowCertificate issuance and renewal
Tenant resolution and authorizationRegistered-host edge routing
Your application’s availabilityCustomer-domain status API and created/deleting webhooks
Editable TCO worksheet

Compare your assumptions, not a marketing benchmark.

Enter your own loaded rate, engineering effort and operating costs. The calculation stays in this browser and starts at zero; subdomain.to does not infer a saving.

Shared assumptions
Build internally · year one
Managed layer · year one

Build = rate × (setup + 12 × monthly operations + incidents) + annual infrastructure

Managed = rate × (integration + 12 × monthly operations) + annual subscription

Use one currency consistently. This worksheet applies no exchange rate, tax, inflation or discount rate.

Build · year one€0
Managed · year one€0

Both scenarios currently total €0. Enter your assumptions to compare them.

Migration path

Move the lifecycle without moving every domain at once.

A controlled migration separates inventory, DNS change and traffic validation. Preserve a rollback path until the new route is confirmed.

  1. InventoryExport active hostnames, tenant owners and current origin behavior.
  2. RegisterCreate corresponding domain resources and store their identifiers.
  3. PilotMove a non-critical hostname and validate tenant resolution, TLS and events.
  4. BatchChange DNS in controlled groups while monitoring both old and new paths.
  5. RetireRemove the internal pipeline only after renewals and deletion flows are covered.
Decision questions

Pressure-test both options.

Is an internal reverse proxy enough?

It can route traffic, but it does not by itself provide domain ownership verification, certificate lifecycle management, a customer-facing state model or safe inventory synchronization.

When is building clearly the better option?

When your differentiated requirements cannot fit the managed boundary and a team is already accountable for edge, PKI and ongoing incidents — not only the initial implementation.

Does buying remove all engineering work?

No. You still integrate the API, design onboarding, authorize domain changes, resolve tenants and keep the HTTPS destination reliable.

How should cost be compared?

Compare the managed service with the full ownership surface: implementation, on-call responsibility, certificate and DNS failure recovery, customer support tooling and future migrations.

Make the boundary explicit

Review the assumptions with the team that will own incidents.

Bring the worksheet, your origin constraints and the failure modes your product cannot outsource.

  • No invented industry benchmark
  • One-year comparison from your own inputs
  • Architecture fit reviewed before migration