A product engineering studio.
We work the way good product teams work. Spec before code. Schema before screens. Observability and audit on day one, not retrofitted in month six.
Three phases, three gates, one spine.
Every engagement runs this shape. Phases move left to right and only advance through a gate — a named artifact you have seen and agreed to. The spine underneath is not a phase; it is work that happens in all of them. Two weeks, four to twelve, one — then sixty days of warranty.
No code starts until the spec, schema sketch, threat model and success metrics are written down and you have agreed to them. If discovery says the project shouldn’t happen, that is a valid outcome and you keep the document.
Migrations reversible and running in CI, authorisation enforced at the database, audit and observability live, tests green. A build that only works on a laptop has not passed this gate.
Your engineers have run the system without us in the room — deploy, rollback, restore, and the three things most likely to page someone at 2am. Handover ends when they can, not when we say so.
- Event sourcing in audit-heavy domains. Every mutation is an event with full context — IP, user agent, session, before / after.
- RLS over middleware. Authorisation lives in the database where it can’t be bypassed. The app is a UI on top, not a gatekeeper.
- Type-safe APIs. If the schema is right, half the bugs never exist.
- Schema-as-truth. Migrations live in code, run in CI, are reversible. There is no “production drift” on our watch.
- Idempotency by default. Replaying a webhook should not double-charge anyone.
- Observability from day one. Logs, traces, error budgets — not bolted on when production breaks.
- Hand you a Figma and disappear. Anything we design we also ship.
- Sell you AI you don’t need. The default is “do you actually need a model here?”
- Lock you into us. Documentation, runbooks and tests on handover — or you have us by the throat, which is fine, but not how we build.
We work in the way that fits the engagement.
Openly, and yours at the end
We work openly with the client throughout and hand over the system when we’re done — source, schema, runbooks and tests.
Under your name, if that is the arrangement
We can work as a white-label delivery team, a co-delivery partner, or a specialist engineering team alongside yours — under NDA and agreed commercial terms.
We treat DPDP and the GDPR as schema decisions, not as a policy page.
Neither law issues a certificate, so nobody can hand you one. What we can tell you is how the obligations show up in systems we have already built — because erasure, consent and residency are decided in the data model long before they are written into a policy.
Fixed when the system is created
Nidara holds its data in India as a decision made at creation, because residency is not a setting you change later. On Go2Green, Aadhaar e‑KYC payloads and the payment ledger never leave the client’s own network — the automation runs self-hosted beside the database rather than in somebody’s cloud in another jurisdiction.
Versioned, and frozen at signing
Consent text is held as a version and fixed at the moment it was signed, with legal hold and recorded refusals, because consent that silently follows a template revision is not consent to what was signed. On a UK platform we capture child-data consent at the point of booking, with version, address and timestamp.
A transaction, not an excavation
If personal data is scattered through denormalised copies and export files, honouring a deletion request is an archaeology project. If it has one home that everything else references, erasure is a single transaction. That is a schema choice, and it is made on day one or not at all.
On a client engagement you are the Data Fiduciary under the DPDP Act, or the controller under the UK and EU GDPR, and we are the processor. We work to your documented instructions under a written agreement, and we can provide data processing terms meeting Article 28. We tell you before adding a sub-processor, we notify you without undue delay if we become aware of a breach so your own clock is not already running out, and we return or delete the data at the end. We do not use your data to improve our products and we do not train models on it.
India’s DPDP Rules were notified in November 2025, and most of the operational obligations — notice, erasure, breach reporting, rights handling and transfers — commence in May 2027.
A system being designed now will be live by then. Building for it costs very little today and is expensive to retrofit afterwards.
Start with a scoping audit.
Two weeks. We come back with a spec, schema sketch, threat model and success metrics. Applies against the full engagement if you continue.
Book a scoping audit