# 0002. Single-brand deployment

- **Status:** Accepted
- **Date:** 2025-06-28

## Context

The codebase this project started from serves nine brands from one deployment, selecting the brand from the
HTTP host and scoping almost every table by an `instanceId`. Raktar24 is one business with one domain.

## Decision

**Drop the multi-instance machinery entirely.** No `Instance` model, no `instanceId` columns, no host-based
resolution. `WebApplication` resolves the language from the request path and nothing else.

## Alternatives

- **Keep the `Instance` layer with a single row.** Rejected: every query would carry a scope that never
  varies, every new model an `instanceId` column, and every developer would have to learn a concept the
  business does not have.
- **Keep it for the ERP side** (one instance per renting-out company). Rejected: `Company` already models
  that, at the row level, without touching the request lifecycle.

## Consequences

- Simpler queries, simpler models, one fewer required column on every table.
- **Serving a second brand would be a significant change**, not a configuration one. If that ever comes up,
  the sibling project's implementation is the reference.
- Per-company variation is handled by `Company` and `CompanyStorageType` as data, not by deployment topology.
- Documentation and patterns copied from the sibling project must be checked for instance-scoping assumptions
  before being applied here.