Principles

A small set of rules we lean on when there is a real product decision to make. Not aspirational; they are how decisions actually get made today.

1 · The page is the dashboard

The product is honest about what it shows. The dashboard does not have decorative animations, marketing copy, or whimsical empty states. A thermometer reading is a number with a unit; an alarm is an event with a timestamp; a chart is a chart. We took inspiration from cockpit instruments, refrigeration panels, and Bloomberg terminals — places where the operator's life or money depends on the display being unambiguous.

The corollary: when we cannot show something honestly, we do not show it. A "trend arrow" requires a trend; one reading is not a trend. We omit it.

2 · No vendor lock-in we cannot justify

Customer data should be portable. The export ZIP works. The audit trail is externally verifiable. The HTTP API is bidirectional — read everything you wrote.

We will introduce vendor-locked features only when the alternative is operationally untenable. The MQTT bridge using our own broker addresses is one example; the alternative (per-tenant DNS) is more expensive than worth.

3 · Honest about our limits

We will not market ourselves as something we are not. We do not ship calibration certificates; we do not have SOC 2; we are not GxP. Customers ask, we say so, we point them to vendors who do.

A near-miss looks like victory in marketing. We are not playing that game.

4 · Boring infrastructure

Postgres + TimescaleDB. Caddy. Postmark. Hetzner. EMQX. There is no microservice mesh, no Kubernetes, no service-discovery layer. The boring choices are correct for the customer base. We will move if the load requires it; the load does not require it.

5 · Audit trail first

Every customer-facing piece of state has an audit entry. Every change is reversible (by adding a correction row, not by editing history). The cost of this discipline is paid by us in development time; it is the product feature that earns customer trust.

6 · One operator can run a site

The product must be operable by a single café manager, with no training and no special vocabulary. The dashboard's primary verbs are "acknowledge", "render report", "rotate token". A senior systems engineer should not be required.

The corollary: when we have a complex feature it is in the API, not in the dashboard.

7 · Slow rollouts

We do not run experiments on customer accounts. There are no A/B tests of ingest behaviour. There are no "rollout buckets" for features that affect compliance evidence. When we ship a change to the alarm engine, it ships for everyone after testing — not for 35 % of accounts.

8 · EU sovereignty by default

Our data lives in Germany. Our company is in Slovakia. Our backups are in Germany. We will deploy in a non-EU region when a customer asks and pays for it; we will not move existing customers without permission.

9 · Pricing pre-set

We do not negotiate Solo-tier pricing. €29 / month / site is €29 / month / site regardless of whether you are a single café or a hospital. Volume discounts kick in at the second site (€19 / month) and are not negotiable beyond that. This is a small SaaS; the pricing is the pricing.

Enterprise tier is custom because Enterprise is custom. Solo and Team will never be.

10 · The product is the documentation is the product

If a feature is not documented, it does not exist for support purposes. If a feature changes, the docs change in the same deploy. If the docs lie, customers do not trust the product; hence this site, hence the labour of writing it.

The corollary: we will not over-promise on the docs. If a feature is "coming Q3", we say so. If a feature is dropped from the roadmap, we say so.

— These principles are not law. When one of them is wrong, we will change it openly, not silently.