Delivery & Handover Policy

We do not sell any physical goods on this site. That means no warehouse, courier, tracking number or PIN-code delivery check. Every service is delivered electronically, and most of the work lands directly in systems you already own.

• Code goes to your repository, on a branch, and passes through your review process.
• Infrastructure is created in your cloud account, with its definition stored as code in your repository.
• Pipelines, dashboards, registries and test suites are set up within 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 has to be moved or rebuilt if you stop using us after handover, and no licence sits in our name.

What you pay at checkout is the total. Nothing is added at handover: no urgency charge, per-user fee or expenses.

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

1. our payment gateway has confirmed your payment;
2. you have submitted your full project brief;
3. the access listed on the service page has been given and is working.

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

If your brief is incomplete, we will send you specific questions instead of guessing, and we will make it clear that the timeline has not started yet.

The ranges shown here come from the timelines on our current service pages and are meant to help you plan. The timeline that applies to your order is the one shown on the service page you ordered from.

Ordering more than one unit of the same service lengthens the timeline in proportion. Ask us for the combined date before paying.

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

• The work. 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 only merge into your main branch if you ask us to. Other deliverables, such as designs, reports or documents, are supplied in the format described on the service page.
• Written handover notes. A document explaining what was built and why, the architecture and main decisions, how to run and deploy it, where configuration and secrets live, what to do when the most likely failures happen, third-party dependencies and their licences, and known limitations with suggested next steps.

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

Handover material is also linked from the order in your dashboard, so you are not relying on a single email. We aim for your own team to be able to carry the work forward without having to ring us.

The timeline stops while we are unable to proceed, and the delivery date moves back by the length of the pause without extra cost. Typical reasons are:

• access we asked for has not been given, has expired, or does not have the permissions the work requires;
• an environment we were told about does not exist, is not working, or cannot be reached;
• test data, credentials, design files or content we asked for have not been received;
• a decision or approval is with you and we cannot sensibly continue on an assumption;
• a review request has been waiting for more than 7 working days;
• a third party is causing a hold-up — for example a cloud quota increase, supplier approval, domain transfer or app-store review;
• you have asked us to pause, whatever the reason.

When the clock stops, we let you know on the same working day, explain what we need, and give a new date once it is sorted. If we are still waiting 30 days after asking, the suspension clause in our Terms of Service applies.

If a service runs late because of us, we will tell you ahead of the date, not after it, with the reason and a new date.

• If we warned you before the date, the service carries on to the new date — or you can cancel and receive a refund based on 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 due to a genuine force majeure event are dealt with under our Terms of Service, and we will still keep you informed.

A service is delivered once every deliverable on its page has been handed over in the way described in section 5. After that:

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

We judge acceptance against the scope. If the work does what the service page says, it has been delivered; if you now want it to do something else, that is a change request, which we quote for separately.

If a service page includes a revision round, you can use it within the window shown on that page — or within 15 days of handover if no window is shown.

• Please put all your revision points into a single list.
• A revision adjusts what was delivered to fit the agreed scope: corrections and adjustments.
• Anything that alters the brief is a change request. We quote it separately and do nothing on it until you approve in writing.
• We schedule revision work within 5 working days of receiving your list.

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

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

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

• Please grant access with the lowest level of permission the work needs, using your own single sign-on where you have it.
• Do not send credentials by chat or email. Use a secrets manager, or invite the assigned people directly.
• Access should have an expiry and be removed at handover.
• We would rather work with anonymised, masked or synthetic data. If access to production data cannot be avoided, it should be clearly identified, agreed in writing and time-limited.

Invoicing and GST work differently for clients outside India. Let us know where you are registered before you order and we will confirm how the invoice will be issued.