The answers your security
reviewer is going to ask for.

Your code lives in your repository and your credentials stay in your secret manager — we hold as little of your data as the work allows, and none of it after it ends.

// the detail

Where code lives

In a repository the client owns, wherever that is possible — your GitHub, GitLab or Azure DevOps organisation, on your billing, with your admins. Where we start a repository because you do not have one yet, ownership transfers to you at or before handover. We do not keep private forks of client work after an engagement closes.

Who has access

Only the engineers working on your build, with named individual accounts. No shared team logins, no generic "dev" account passed around. Two-factor authentication is on for every account we use for client work — source control, cloud consoles, email. When someone comes off an engagement, their access is removed rather than left dormant.

How credentials are handled

We would rather not hold your production credentials at all, and often do not need to. Where we do, they are issued to us through your secret manager or password manager, scoped to the environment we are working in, and never put in a repository, a ticket, a spreadsheet or a chat message. We ask you to rotate anything shared with us when the engagement ends.

What we do with client data

We build against test or anonymised data by default. If a feature genuinely needs production data to be built or debugged, we agree in writing what we can see, for how long, and where it sits. We do not copy client data onto personal machines, we do not use it to train models, and we never reuse one client’s data or screens as a demo for another.

The machines we work on

A small remote team in India. Client work happens on laptops with full-disk encryption, automatic screen lock and current operating systems. No shared devices, no client code on personal phones, nothing carried around on removable drives.

Subprocessors

The third parties that touch a project are named in the proposal before the work starts: source control, the cloud provider you choose, and any model or API provider a feature depends on. If a build needs a new one mid-engagement, we tell you and get agreement first rather than adding it quietly.

Three third-party scripts run on buildspacelabs.com, every one of them requested only after you opt in — decline the consent banner and none of them load at all.

What each one collects, how long it is kept and how to withdraw consent is set out in the privacy policy.

AI-assisted, human-reviewed, and you are told which is which: a named engineer reads every change and can explain it before it reaches your branch.

// the detail

Where we use it

In delivery: code generation and review assistance, test scaffolding, first drafts of documentation, and research. It takes the repetitive parts off a senior engineer. It does not choose the architecture, and it does not get to decide what is correct.

What it passes before it ships

The same gates as anything hand-written. A named engineer reads every change, it goes through pull request review, it runs against tests, and it is checked in a staging environment before release. Nothing reaches your production branch that a person on our side has not read and can explain.

What we do not put into a model

Client credentials, customer records and production data do not go into general-purpose assistants. Where a model provider is part of the product we are building for you, that provider is named in the proposal and covered by the agreement — that is a component of your system, not a tool we use on the side.

What it means for ownership

Model-assisted code is delivered to you on the same terms as everything else we write, and it lands in your repository under your ownership. We are not aware of a court treating AI-assisted authorship as a bar to that, but we are also not your counsel — if this matters to your legal team, raise it before we start and we will put the position in writing rather than leave it implied.

You are told

Clients know which parts of delivery are AI-assisted; we say so rather than waiting to be asked. If your organisation restricts AI-assisted development, tell us at the first call — we will either work to your policy or say plainly that we are not the right fit.

We work on your paper — your MSA, your NDA, your DPA, your questionnaire — and the entity facts we cannot yet state are shown as pending rather than guessed.

// the detail

Who signs

Aryan, Director, signs on our side. Priyanshu, CTO, answers the technical sections of a security questionnaire. Between the two of them, nothing needs to wait on a committee.

MSA, NDA, DPA

We sign yours. Most of what comes to us is a client’s standard paper and we work through it rather than insisting on our own. An NDA before the first detailed conversation is normal and we will not ask you to justify it. A DPA is signed where the work involves personal data.

Invoicing

Raised against the milestones set in the engagement letter. Currency, schedule and payment terms are agreed there in writing before work starts, not assumed.

Insurance

Our current cover position is stated in writing on request — we would rather show you the actual position than a line on a website. If your procurement requires a specific level of professional indemnity or cyber cover as a hard gate, raise it at the first call so we can tell you straight away whether we clear it.

Vendor security questionnaires

We complete them. Send the questionnaire and allow a working week for a considered answer. Where the honest answer is "we do not do that", it will say so.

If we disappeared on a Friday, your team could keep the system running on Monday — you already hold every account, repository and secret it depends on.

// the detail

What you hold, throughout

Source code in your organisation with full commit history. Cloud accounts in your name and on your billing. Domains and DNS on your registrar. Secrets in your manager. Nothing your product depends on runs inside an account only we can reach — that is a deliberate constraint on how we set engagements up, not a favour at the end.

What handover includes

Repository access with history intact, environment and deployment notes, the architecture and data model written down, a runbook for the things that realistically break, and a live walkthrough with whoever is going to own the system. Handover is a scheduled piece of work, not a final email.

If we stop, for any reason

You keep all of the above. There is no lock-in mechanism to unpick: no proprietary runtime, no licence we can switch off, no hosting only we can log into. We are a small team and you should assume small-team risk — which is exactly why the written record and the account ownership are set up so another team could pick the work up.

Business hours, Monday to Friday, India Standard Time — a modest promise we keep, because one we could not keep would be worse than none.

// the detail

Hours

Business hours, Monday to Friday, India Standard Time. We do not run a 24/7 desk or an on-call rotation, and we are not going to claim one. If your system needs overnight cover, that belongs with a team staffed for it, and we will help you set the handover up.

Response windows

Agreed in writing per engagement and written into the support terms, sized to what the system actually does. We do not publish a blanket service level on a marketing page — a number that applies to every client equally is a number nobody costed.

How to reach us

A shared channel with the engineers who built the system, plus email. You are not filing a ticket into a queue and waiting for a tier-one reply from someone who has never seen your codebase.