Designing Ledgerlane's URLs before the database
For Ledgerlane, the URL plan was not a finishing detail. I treated it as an early piece of product architecture: decide where each version of the product lives before deciding how its data is allowed to move.
The map
The project now has a clear purpose for each environment:
- a public marketing site;
- a production workspace, connected to real data for approved users;
- a public demonstration with fictional, browser-local records; and
- a private testing environment with synthetic data and restricted access.
This separation shapes development. A feature can be tested in an environment designed for it, while a public demo stays safe to share and production remains focused on the real workflow. More importantly, it makes the data boundary visible in the product architecture instead of relying on a developer remembering which settings are safe.
Why decide this before the database grows
URL design affects authentication, storage, deployment credentials, browser sessions, security rules, and the data a user expects to see. If those boundaries are vague at the start, it is easy to make convenient shortcuts later: point a demo at a real backend, reuse a production storage bucket for testing, or let one deployment credential reach every environment.
Those shortcuts create bugs that are difficult to spot from the interface alone. They can also turn a database change into a risky deployment problem. By giving each environment its own Firebase project, Auth directory, Firestore database, Storage bucket, and deployment credential, Ledgerlane makes the intended boundaries explicit before the data model becomes harder to change.
What this makes easier — and what it costs
The structure gives future work a safer path. A new feature can be exercised with synthetic records in staging, demonstrated without exposing workspace data, and released only after the correct production checks pass. Environment markers in the build, explicit deployment targets, and custom-domain checks make it harder to accidentally ship the wrong artifact to the wrong place.
The drawback is operational weight. More environments mean more Firebase configuration, DNS records, service accounts, security rules, and release checks to maintain. Browser storage and sign-in sessions are origin-specific too, so changing a hostname does not carry a user session or demo records across automatically. This is not complexity to add casually; it is complexity accepted because the product handles business records.
The decisions so far
The key decisions have been to keep marketing separate from the application, make the demo browser-only and deny all Firebase reads and writes, reserve the private test environment for approved internal testers, and keep production for the allowlisted workspace. Deployments do not use a default Firebase project: the build and deployment scripts validate the artifact, target site, rule paths, and service-account project before publishing.
We have also kept public releases deliberate. Internal staging can deploy from the staging branch, while demo, production, and marketing releases are manual and restricted to main. Before a release, the project records the previous Hosting version, runs checks against the Firebase origin and custom domain, and keeps rollback scoped to the affected site and its reviewed rules.
The result is not just a neat list of subdomains. It is a set of guardrails for the database and deployment decisions that come next.