Proposal engine as a separate deployment
Client-facing proposal tooling runs on its own subdomain and repository, not inside the marketing site.
ADR-010 — Proposal engine as a separate deployment
Context#
ADR-006 established async-first sales as the default motion: a written proposal plus a recorded walkthrough, rather than a live call. That motion depends on producing proposals repeatably. Done by hand, each one takes about an hour and the quality varies with how tired the operator is.
A system was needed to generate them. The question was where it should live.
orvenath.com is a statically generated marketing site with no database, no authentication, and no user input. Adding an authenticated admin surface, a Postgres connection, and client data to it would mean:
- A public marketing site that now has a login page and a live database attached
- Client contact details and commercial figures sharing a deployment with the public brand
- Every marketing copy change redeploying the system that holds active client proposals
- One
robots.txttrying to serve two opposite goals — the marketing site wants indexing, proposals must never be indexed
Decision#
Build the proposal engine as a separate private repository, deployed independently to proposals.orvenath.com.
The entire subdomain is excluded from indexing at three levels: robots.txt disallowing all paths, noindex, nofollow root metadata, and an X-Robots-Tag response header. Client proposals are confidential documents and must never be discoverable.
Branding follows the division rules in Divisions:
| Surface | Presentation |
|---|---|
| Admin interface | Unbranded internal tooling |
| Proposal PDF | Orvenath Studio as contracting party |
| Client share page | Orvenath Studio, parent in footer |
| Domain | Parent — orvenath.com is the legal entity |
This is one of the narrow cases where a subdomain is correct rather than a path. The general rule against subdomains concerns division marketing pages splitting search authority. This is separate infrastructure with its own authentication surface that we actively want de-indexed — the opposite situation.
Consequences#
- Marketing site stays static, fast, and free of authentication surface
- Client data isolated from the public brand deployment
- Two repositories to maintain rather than one
- Design system duplicated across both; drift is now possible and must be watched
- Independent deploy cadence — proposals can ship without touching the site
Notes#
Design system duplication is accepted for now. If it drifts noticeably, the fix is extracting a shared component package, not merging the deployments.