Delivery & Handover Policy

No product sold on this site is physical. There is no warehouse, courier, tracking number or PIN-code serviceability check. Every service reaches you electronically, and most of it lands in systems you already own.

• Code goes to your repository, on a branch, through your review process.
• Infrastructure is provisioned in your cloud account and defined in code that lives in your repository.
• Pipelines, dashboards, registries and test suites are created under your organisation and billed to you.
• Documents and design files are emailed to you and attached to the order in your dashboard.

As a result, nothing needs migrating or rebuilding if you stop working with us after handover, and no licence sits in our name.

What you pay at checkout is the whole amount. Nothing is added at handover: no rush fee, no per-seat charge and no expenses.

Every service page gives its timeline in working days. The timeline begins only once all three of these conditions are met:

1. the payment gateway has confirmed your payment;
2. your project brief has been fully submitted;
3. the access listed on the service page has been granted and is working.

We confirm a delivery date when work starts. A working day is Monday to Saturday, other than public holidays observed at our registered office.

If the brief is incomplete, we will reply with specific questions instead of making assumptions, and we will make it clear that the timeline has not started yet.

To help you plan, the ranges below are drawn from the timelines published on our current service pages. The timeline that governs your order is the one shown on the service page you purchased.

Purchasing several units of one service lengthens the timeline in proportion. Please ask us for the combined date before paying.

Handover is a clearly defined event. A service is complete once both of the following have been supplied.

• The work itself. For code, commits are pushed to a branch in your repository and raised as a pull request against your default branch, in line with your conventions and checks; infrastructure is applied to your cloud account from code in that same repository. You review and merge — we will not merge into your main branch unless you ask us to. Other deliverables, such as designs, reports or documents, are supplied in the format the service page specifies.
• Written handover notes. A document explaining what was built and why, the architecture and key decisions, how to run and deploy it, where configuration and secrets live, what to do when the most likely failures occur, third-party dependencies and their licences, and known limitations with suggested next steps.

If a service page includes a walkthrough session, it is booked as part of handover and, if recorded, the recording is shared with you.

The handover material is also linked from the order in your dashboard, so you are never reliant on a single email. We aim for your own team to be able to take the work forward without needing to call us.

Whenever we are blocked, the timeline pauses and the delivery date shifts by the length of that pause, at no additional charge. Typical causes include:

• access we asked for has not been granted, has expired, or lacks the permissions the work requires;
• an environment described to us does not exist, is broken, or is unreachable;
• test data, credentials, design files or content we listed have not been received;
• a decision or approval sits with you and we cannot reasonably continue on an assumption;
• a review request has remained open for more than 7 working days;
• a third party is causing a hold-up, for instance a cloud quota increase, vendor approval, domain transfer or app-store review;
• you have asked us to pause, for whatever reason.

If the timeline pauses, we let you know on the same working day, explain what we are waiting for, and give a revised date once the issue is resolved. If we are still waiting 30 days after our request, the suspension clause in our Terms of Service applies.

If a service runs late because of us, you will hear before the date, not after it, along with the reason and a revised date.

• If we warned you before the date, the service carries on to the revised date, or you may cancel and receive a refund for the stage reached.
• If we did not warn you before the date, you are entitled to a full refund under our Refund & Cancellation Policy.
• Delays caused by a genuine force majeure event are dealt with under our Terms of Service, and we will still keep you informed.

A service counts as delivered once every deliverable on its page has been handed over in the way described in section 5. From then on:

• You have 7 working days to notify us in writing that something within the scope is missing or materially incorrect. We will put it right free of charge as part of the same service.
• If you raise nothing in that time, or you start using the work in production, the service is deemed accepted.
• Acceptance does not reduce any revision window, nor the 15-day defect remedy in our Terms of Service.

Acceptance is judged against the scope. If the work does what the service page describes, it has been delivered; if you want it to do something else, that is a change request, which we will quote separately.

If a service page includes a revision round, you can use it within the window stated on that page, or within 15 days of handover where the page gives no window.

• Please gather your revision requests into a single consolidated list.
• A revision fine-tunes what was delivered against the agreed scope, through corrections and adjustments.
• Anything that alters the brief is a change request. We quote it separately and begin nothing until you approve it in writing.
• Revision work is scheduled within 5 working days of your list reaching us.

We answer questions during our business hours. If you need continuing rather than occasional help, a monthly managed-support service may be a better fit, and we will tell you so.

Our access to your systems should be removed at handover. If you want us to retain time-limited, read-only access for the support period, let us know and we will confirm it in writing.

Because delivery is remote, there is no serviceable area. We work with clients throughout India and, by arrangement, overseas. We ask for your PIN code so we can issue a correct GST invoice, not to decide whether we can deliver to you. All work and documentation is provided in English.

• Access should be granted at the lowest permission level the work requires, using your own single sign-on where it exists.
• Please avoid sending credentials by chat or email. Use a secrets manager, or invite the assigned people directly.
• Access should be limited in time and revoked at handover.
• Our preference is for anonymised, masked or synthetic data. If access to production data cannot be avoided, it should be named, agreed in writing and limited in time.

Invoicing and GST treatment are different for clients based outside India. Let us know where you are registered before buying and we will confirm how the invoice will be issued.