Delivery & Handover

Nothing sold on this site is a physical good. There is no warehouse, courier, tracking number or PIN-code serviceability check. Every engagement is delivered electronically, and most of it is delivered into systems you already own rather than sent to you as files.

• Code is pushed to your repository, on a branch, through your review process.
• Infrastructure is set up in your cloud account, defined in code kept in your repository.
• Pipelines, dashboards and test suites are built under your organisation, with your billing attached.
• Documents, design files and any recordings arrive by email and are linked from the order in your dashboard.

This is deliberate. If you never work with us again after handover, nothing needs to be migrated or rebuilt, and no licence sits in our name.

The amount at checkout is the whole amount. Nothing is added at handover: no rush fee, per-seat charge or expenses line.

Each engagement page states its timeline in working days. The clock starts only when all three of these are true:

1. The payment gateway has confirmed your payment.
2. Your technical brief has been submitted in full.
3. The access listed under what we need from you has been granted and works.

At that point we confirm a delivery date. A working day means Monday to Saturday, excluding public holidays.

If the brief arrives incomplete, we come back with specific questions rather than guess. The clock has not started at that point, and we will tell you so plainly.

These ranges are taken from the timelines published on our current engagement pages, to help you plan. The figure that binds us is the one printed on the page of the engagement you buy.

Buying several units of the same engagement lengthens the timeline, and we tell you the combined date before work begins.

Handover is a defined event, not a gradual fade-out. An engagement is finished when everything its page lists has been handed over.

• The work, in your systems. Commits are pushed to a branch in your repository and opened for review against your default branch, following your conventions. Infrastructure is applied to your account from code in the same repository. You review and merge; we do not merge to your main branch unless you ask us to.
• The documentation the engagement lists. Depending on the engagement, this can include a README, runbooks, architecture notes, a record of decisions and known gaps, and the third-party components used.
• Any session or recording the engagement lists. Where the page includes a walkthrough or training session, it is part of handover.

The order in your dashboard carries the same links, so nothing depends on a single email.

The standard we aim for is simple: your own team should be able to take the work forward without needing us.

A fixed date depends on both sides, so the clock pauses while we are genuinely blocked. The delivery date moves by the length of the pause, at no extra charge.

• Access we asked for has not been granted, has expired or lacks the permissions the work needs.
• An environment we were told about does not exist, is broken or cannot be reached.
• Test data, credentials, design files or content we listed have not arrived.
• A decision or approval is waiting with you and we cannot sensibly proceed on an assumption.
• A review request has been open for more than 7 working days.
• A third party is holding things up, such as a quota increase, vendor approval, domain transfer or app-store review.
• You have asked us to hold, for any reason.

When the clock pauses, we tell you what we are waiting for, and give a revised date once it clears. If we are still waiting 30 days after asking, the suspension clause in the terms applies.

If a delay is on our side, you hear about it before the date, not after, with the reason and a revised date.

• Told before the date: the work continues to the revised date, or you cancel and take a refund for the stage reached.
• Not told before the date: the refund policy gives you the whole fee back.
• Delays caused by a genuine force majeure event are handled under the terms, and you are still told.

An engagement is delivered when every deliverable on its page has been handed over as described in section 5. From then:

• You have 7 working days to tell us in writing that something in the scope is missing or materially wrong. We put it right at no charge, as part of the same engagement.
• If you raise nothing in that time, or put the work into production use, the engagement is treated as accepted.
• Acceptance does not shorten any revision round or support window on the engagement page, or the defect remedy in the terms.

Acceptance is about scope, not taste. If the work does what the engagement page said, it is delivered. If you want it to do something else, that is a change request, which we quote separately.

Some engagements include a revision round, a support window or a period of fixes after handover. Where they do, the engagement page states what is included and for how long.

• Send revisions as one consolidated list; it is quicker for everyone.
• A revision refines what was delivered against the agreed scope.
• Anything that changes the brief is a change request. We quote it separately and start nothing until you agree in writing.

Handover is not the end of the conversation.

• Anything missing from the scope and reported within 7 working days is put right at no charge.
• Material defects in our own work are corrected at no charge under the defect remedy in the terms.
• If the engagement includes a support window or revision round, it runs as its page describes.
• After that, further work is a new engagement, or a piece of work quoted and agreed in writing first.

Questions can be sent through our contact page at any time. If what you need is ongoing rather than occasional, a monthly managed-support engagement is likely the right fit, and we will say so.

Our access to your systems is revoked at handover as standard. If you would like us to keep time-limited read-only access during a support window, tell us and we will document it.

Delivery is remote, so there is no serviceable area. Your PIN code is collected only to raise a correct GST invoice, never to decide whether we can deliver to you. All work and documentation is in English, and engagements are governed by the laws of India.

• We ask for access at the narrowest permission level the work needs, through your own single sign-on wherever available.
• Please do not send credentials over chat or email. Use a secrets manager, or invite the named people directly.
• Access is time-limited and revoked at handover.
• We prefer anonymised, masked or synthetic data. Where production access is genuinely unavoidable, it is named, agreed in writing and time-limited.

Invoicing and GST treatment differ for organisations registered outside India. Tell us where you are registered before you buy, and we will confirm how the invoice will be raised.