Security & Data
Where data lives, how it travels, who can reach it, and what gets logged.
Who owns the data in a system you build for us?
You do. We process it to run the service you hired us for and for nothing else. It is not pooled with another customer's data, not sold, and not used to advertise to your users. If the relationship ends, the data is yours to take with you.
How is data protected while it travels?
Connections run over HTTP/3, and the domain is on the browsers' preloaded HSTS list — so a browser refuses to talk to it unencrypted even on the very first visit, before any redirect could be intercepted. The key exchange is post-quantum: X25519 combined with ML-KEM-768, chosen so that traffic captured today still resists decryption once quantum computers are able to attack it.
How are passwords, keys and API credentials stored?
Never in source code — that is enforced by the build, not by discipline: code containing a hard-coded secret is rejected before it can be merged. Secrets live encrypted in a settings store and are decrypted at runtime only where they are actually needed, which also means rotating a key is one change in one place instead of a search across a codebase.
What gets logged, and can you tell who changed something?
Yes. Application events, errors and administrative actions are written to the database rather than to text files scattered over servers, so they can actually be searched. Administrative changes record who acted, what was changed and when. A question like "who changed this price last month" has an answer instead of a guess.
How do you handle cookies and consent?
Non-essential cookies are set only after the visitor agrees, the choice is recorded, and every site we build has a page where it can be changed or withdrawn later. Declining is one click, not a hunt through a settings menu — and a visitor who declines still gets a working site.