Delivery & Handover Policy

We do not sell any physical products on this site. So there is no courier or warehouse involved, no tracking number to follow, and no check on whether your PIN code is covered. Each service reaches you electronically, and most of the work lands directly in systems that belong to you.

• Code lands in your repository on its own branch and passes through your own review steps.
• We provision infrastructure inside your cloud account, described as code that lives in your repository.
• Any pipelines, dashboards, registries or test suites are created within your organisation and billed to you.
• We email documents and design files to you, and they also sit alongside the order inside your dashboard.

As a result, if you part ways with us after handover, there is nothing to move or rebuild, and we hold no licences on your behalf.

What you pay at checkout is the complete price. No rush fees, per-seat charges or expenses appear at handover.

Every service page gives a timeline in working days. The clock only starts once each of these conditions is met:

1. your payment is confirmed by the payment gateway;
2. you have submitted a complete project brief;
3. you have granted the access named on the service page, and it works.

Once work gets going, we confirm your delivery date. Working days run Monday to Saturday, not counting any public holiday our registered office observes.

Where a brief has gaps, we send you targeted questions instead of guessing, and we make it plain that the clock is not yet running.

To help with planning, the ranges shown here come from the timelines on our live service pages. Your order is bound by the timeline on the specific service page you purchased.

Ordering more than one unit of a service lengthens the timeline in proportion. Please check the overall date with us before paying.

Handover is a clearly defined moment. A service is finished once you have received both items below.

• The deliverables. We commit code to its own branch within your repository and open a pull request that targets your default branch, following the conventions and checks you already use. Infrastructure is defined in that same repository and applied from there to your cloud account. Merging is your decision; we only merge into your main branch if you ask. Other outputs, whether documents, reports or designs, come in the format the service page specifies.
• Handover notes in writing. These explain what we built and the reasons behind it, the architecture and main decisions, the steps for running and deploying the work, where secrets and configuration live, how to respond to the most probable failures, which third-party dependencies are involved and under what licences, and any known limitations along with recommended next steps.

If the service page mentions a walkthrough session, we book it into the handover, and share the recording with you if one is made.

Your dashboard links all handover material from the order, so nothing relies on one email. We aim for your team to be able to carry the work forward without having to ring us.

Whenever we are blocked, the clock stops and the delivery date shifts by the same amount, at no additional cost to you. Typical causes are:

• access we asked for has not arrived, has lapsed, or does not carry the permissions needed;
• an environment described to us is missing, faulty or unreachable;
• items on our list, whether content, design files, credentials or test data, are still outstanding;
• we need a decision or sign-off from you and cannot sensibly go ahead on a guess;
• a review request has sat unanswered for over 7 working days;
• an outside party is causing the hold-up, such as a vendor approval, domain transfer, app-store review or cloud quota increase;
• you want work put on hold for a while, whatever the reason.

If the clock stops, you hear from us that working day, with what we need from you, and we issue a new date once it is sorted. Should we still be waiting 30 days after our request, our Terms of Service suspension clause comes into effect.

If we are the reason a service runs late, we will let you know ahead of the due date rather than afterwards, explaining why and giving a new date.

• Where we warned you in advance, work carries on to the new date, or you may cancel and get back the refund due for the stage reached.
• Where no warning reached you before the date, you are entitled to a full refund under our Refund & Cancellation Policy.
• Our Terms of Service cover delays from genuine force majeure events, and you will still hear from us.

A service counts as delivered when you have received every deliverable listed for it, handed over as section 5 explains. After that:

• Within 7 working days, you can let us know in writing if anything inside the scope is absent or materially incorrect. We correct it free of charge under the same service.
• If that period passes with nothing raised, or you start using the work in production, we treat the service as accepted.
• Accepting the work leaves any revision window intact, and the 15-day defect remedy described in the Terms of Service also stays in place.

We judge acceptance against the agreed scope. Work that does what the service page promises has been delivered; wanting it to behave differently makes it a change request, priced on its own.

If a service page offers a revision round, you can use it inside the window shown there, or within 15 days after handover when no window is given.

• Gather all revision requests into a single list, please.
• Revisions correct and fine-tune the delivered work within the agreed scope.
• Any change to the brief counts as a change request. We price it on its own and begin only after your written approval.
• Once your list arrives, we slot the revisions in within 5 working days.

We reply to questions within our working hours. If you expect to need regular help rather than the odd answer, a monthly managed-support service could be a better fit, and we will point that out.

At handover, please revoke the access we had to your systems. Should you prefer us to retain read-only access for a limited time during the support period, let us know and we will confirm it in writing.

Because everything is delivered online, we have no service area limits. Clients throughout India are welcome, and those abroad by arrangement. We ask for your PIN code only so the GST invoice is correct, never to check whether delivery is possible. We work and write documentation in English.

• Grant access at the lowest permission level the work requires, using your own single sign-on if you have it.
• Keep credentials out of email and chat messages. Share them through a secrets manager, or add the assigned team members yourself.
• Set access to expire, and remove it at handover.
• We would rather work with synthetic, masked or anonymised data. If production data truly cannot be avoided, it should be specifically identified, approved in writing and available only for a limited time.

Clients based outside India are invoiced differently and GST may be treated differently. Let us know your place of registration before buying, so we can explain how your invoice will be issued.