Delivery & Handover

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

• Code is pushed to your repository, on a branch, through your review process.
• Infrastructure is provisioned in your cloud account, defined in code that lives in your repository.
• Pipelines, dashboards, registries and test suites are built under your organisation, with your billing attached.
• Documents, design files and recordings arrive by email and appear on the order in your dashboard.

That is deliberate. If you never speak to us again after handover, nothing has to be migrated, re-provisioned or rebuilt, and no licence sits in our name.

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

Each engagement page states its turnaround in working days. That clock begins 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 actually been granted and works.

Engineers are assigned and work begins within 3 working days of that point, and you get a firm delivery date on the first day rather than an estimate that firms up later. A working day means Monday to Saturday, excluding public holidays observed at our registered office.

If the brief arrives incomplete, we come back with specific questions rather than start guessing. The clock has not started at that point, and we will say so plainly rather than let you think it has.

These are the ranges our own delivery history supports. They are here so you can plan; the figure that actually binds us is the one printed on the engagement page you bought.

Buying several units of the same engagement lengthens the turnaround proportionally, and we tell you the combined date before you pay rather than after.

Handover is a defined event, not a gradual fade-out. It has three parts, and an engagement is not finished until all three exist.

• The work, in your repositories. Commits pushed to a branch in your repository and opened as a pull request against your default branch, following your commit conventions and passing your checks. Infrastructure is applied to your cloud 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 written handover document. One document, in the repository, covering what was built and why, the architecture and the decisions behind it, how to run and deploy it, environment variables and secrets and where they live, the runbook for the things most likely to break, every third-party dependency with its licence, and an honest list of known gaps and what we would do next.
• The walkthrough recording. A screen recording in which the engineer who built it walks your team through the code and the runbook. It is yours to keep, re-watch and show to whoever joins later. Where the engagement page includes a live session instead, it is recorded and handed over as well.

Alongside those, the order page in your dashboard carries the handover pack and the same links, so nothing depends on one person keeping an email.

The test we hold ourselves to is simple: your own engineers should be able to pick the work up without calling us. If they cannot, the sprint is not finished.

A fixed date depends on both sides moving, so the clock pauses while we are genuinely blocked. The delivery date then moves by the length of the pause, and nothing extra is charged.

• Access we asked for has not been granted, has expired, or does not carry the permissions the work needs.
• An environment we were told about does not exist, is broken, or cannot be reached from outside your network.
• Test data, credentials, design files or content we listed have not arrived.
• A decision or an approval is sitting 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 — a cloud quota increase, a vendor approval, a domain transfer, an app-store review.
• You have asked us to hold, for any reason at all.

When the clock pauses we tell you the same day, name what we are waiting for, and give the revised date once it clears. We will chase a couple of times, politely. If we are still waiting 30 days after asking, the suspension clause in the terms applies.

Occasionally a sprint slips at our end. The rule we hold to is that you hear it before the date, not after it, with the reason and a revised date, from the person doing the work.

• Told before the date: the sprint continues on the revised date, or you cancel and take a refund at the stage reached.
• Not told before the date: the refund policy gives you the whole fee back. That is a commitment rather than a gesture, and it exists to make the warning worth giving.
• Delays caused by a genuine force majeure event are handled under the terms instead, and you still get told.

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

• You have 7 working days to tell us in writing that something in the scope is missing or materially wrong. Raise it and we fix it, at no charge, as part of the same engagement.
• Say nothing inside that window, or put the work into production use, and the engagement is treated as accepted.
• Acceptance does not shorten the revision window in section 9, and it does not touch the 15-day defect remedy in the terms.

Acceptance is about the scope, not about 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, and we will price it honestly.

Every engagement includes one revision round, available for the window printed on its page — 15 days from handover unless that page says otherwise.

• Send it as one consolidated list. A trickle of individual notes takes longer for everyone.
• A revision refines what was delivered against the agreed scope: corrections, adjustments, tightening.
• Anything that changes the brief is a change request. We quote it separately and start nothing until you agree in writing.
• Revision work is scheduled inside 5 working days of receiving your list, and it does not queue behind new orders.

Handover is not the end of the conversation, and we do not charge for the first stretch of it.

Questions are answered during Mon-Sat, 09:30-19:00 IST, usually a good deal faster than that. If what you need is ongoing rather than occasional, a monthly managed-support sprint is the honest answer, and we will say so rather than quietly absorb the work.

Our access to your systems is revoked at handover as a matter of course. If you would rather we kept a time-boxed read-only account for the support window, say so and we will document it.

Delivery is remote, so there is no serviceable area. We work with teams across India and with clients abroad, overlapping with European and US mornings by arrangement. Your PIN code is collected only to raise a correct GST invoice, never to decide whether we can deliver to you. Everything is written and delivered in English.

• Access is requested at the narrowest permission level the work needs, through your own single sign-on wherever you have it.
• Credentials are never accepted over chat or email. Use a secrets manager, or invite the named engineers directly.
• Sessions are logged, time-boxed 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.

Overseas invoicing and GST treatment differ. Tell us where you are registered before you buy and we will confirm how it will be raised.