How we build, and what you get to keep
Your systems, your data, your keys
Most security pages are a list of logos. This one is a list of things you can check.
Everything we build is deployed on your servers, with your data on your infrastructure. That single decision answers most of what follows — we are not asking you to trust us with your data, because we never hold it.
We have delivered for more than 50 businesses, and we name none of them. Confidentiality is not something we switch on for the clients who ask.
One
You own it, and you can leave
Your code
You get the source. It runs on your domain, in your repository.
Your data
It lives in your infrastructure, under your credentials. We do not hold a copy as a condition of the software working.
Your accounts
Cloud, app stores, payment gateway — registered to you, not to us. If we vanished tomorrow, nothing of yours would stop.
Your exit
Every engagement ends with a written runbook covering deployment, backups, access and what needs watching. Moving on is a handover, not a negotiation.
We do not hold anything back as a retention strategy, because a client who stays because they cannot leave is not a reference.
- Your name stays yours
- We do not publish client names, logos or case studies. Every engagement is confidential by default, and it stays that way whether or not anyone asked — which is also why this site shows you our engineering rather than someone else's business.
- Your data never becomes our asset
- It is not used to train shared models, not aggregated into a benchmark, and not retained after an engagement ends unless you ask us to keep something.
Two
Built for India’s DPDP Act
The Digital Personal Data Protection Act is law, and its operational obligations become enforceable on 14 May 2027. We have been building to it rather than planning to retrofit it.
- Identity and consent are separate
- The record of who someone is sits in a different store from the record of what they agreed to, when, and what they have asked us to do about it. Retrofitting that separation later is expensive; we did it first.
- No personal data in URLs
- Query strings leak through referrer headers, analytics and server logs. Personal data travels in a request body or not at all.
- No personal data in logs
- Redaction by key name and by value shape, so it catches what a field name would not have warned you about.
- Deletion is a design decision
- Data minimisation and removal on withdrawal of consent are built into how the systems are structured, not handled as a support ticket.
- Consent is explicit
- Where a form collects personal data it says what is collected, why, and links to the policy — before you submit, not after.
Three
Security enforced by the build, not by intention
Policies that depend on somebody remembering hold until the first busy week. Ours are checks that stop the build.
- Secret scanning
- Every tracked file is scanned for secret-shaped strings on each commit. A planted key fails the build.
- Log safety
- Personal data never reaches a log. The logger redacts by key name and by value shape, so an email inside a free-text note is caught even though the field name gave no clue.
- Injection defences
- Raw HTML injection and the eval family are blocked at lint. Not discouraged — blocked.
- Request limits
- Payload size is checked before parsing, so an oversized body is rejected in milliseconds rather than consuming a worker.
- Rate limiting
- Every write endpoint is limited, and says so with a Retry-After on refusal.
- Input validation
- Every external input is validated against a schema at the boundary and rejected on failure, never silently coerced.
- Configuration
- Schema-validated at boot. A missing or malformed value fails loudly at start, never mysteriously at 2am.
- Accessibility
- Colour contrast is gated against every background it can land on, and layouts are measured for overflow at 320, 768 and 1440 pixels.
All of it runs in continuous integration on every push. If any check fails, nothing ships. Every response also carries a full security header set — Content-Security-Policy, Strict-Transport-Security, nosniff, a strict referrer policy, frame denial and a restrictive permissions policy.
Four
Identity, done once and done properly
Most access problems are not attacks. They are a leaver who still has a login somewhere.
- One authority
- A person is one account across every system — not one account per application that somebody has to remember to close.
- Standards, not improvisation
- OpenID Connect with PKCE, against a hardened identity core we run but never modify.
- Applications never hold the keys
- Downstream systems verify a token; they do not carry client secrets. That is what makes “change it in one place and it changes everywhere” true rather than aspirational.
- Portable by design
- The user identifier belongs to the platform, not to the identity vendor, so the vendor can be replaced without rewriting every application.
- Role-based, everywhere
- Including through the agent interface. A manager who cannot see a salary on screen cannot ask an assistant for it either.
Five
How we govern the AI we build
AI systems fail differently from ordinary software. They do not throw an error — they return a confident answer that is wrong. So they need a different kind of control, built in from the start.
- The eval is the spec
- Before we build, we take a set of your real cases where the answer is already known. That becomes the definition of correct, and every change afterwards is tested against it — so a change that would reduce accuracy fails before it ships.
- A measured number
- You get the accuracy figure on your own data, with the failure modes named, before it touches live work.
- A person approves anything expensive
- Wherever a wrong answer costs money, a human review step sits in the path. That is what separates a production system from a demo.
- Drift is monitored
- Models degrade while nobody touches them. The evaluation set runs continuously.
Six
Compliance, and where it actually sits
The usual version of this section is a row of certification logos. Ours is an explanation of why the question is mostly answered before it is asked.
- Where your data lives
- On your infrastructure, under your credentials, inside your existing security perimeter. We do not take a copy as a condition of the software working, and we do not host it for you unless you ask us to.
- What that means for compliance
- The controls that govern your data are the ones you already run — your cloud, your access policies, your audit posture, your retention rules. We build inside them rather than asking you to extend trust to somewhere new.
- What we hold today
- No certification. We would rather tell you that than imply an audit that has not happened. What we do hold is the engineering practice described above, all of it enforced by the build and open to inspection.
- If your procurement requires one
- Tell us which, and when. Certification is scoped into the engagement like any other requirement — and because the systems already run on your infrastructure, most of what an auditor asks about is answered by your side of the line, not ours.
We will not claim a certificate we do not hold. If a supplier’s security page implies an audit without naming who performed it or when, that is worth asking about — and it is a fair question to put to us too.
Reporting a security issue
If you believe you have found a vulnerability in anything we run, or anything we built for you, tell us and we will act on it.
We acknowledge within one working day and keep you updated until it is closed. We will not take legal action against anyone reporting a genuine issue in good faith.
Documents available on request
Under NDA where appropriate: a Data Processing Agreement, an architecture and data-flow overview for your engagement, our sub-processor list, and our business continuity and backup approach. Ask and you get them. A supplier who will not show you the architecture of the thing running your business is telling you something.
Next step
Ask us the hard question
The one every business should ask a software supplier and rarely does: what happens to us if you disappear? Our answer is the same every time — you have the code, the data, the accounts and the runbook. We would rather be kept because we are useful.