Service Delivery Policy

1. Digital delivery only — nothing is shipped

Canopus IT Solutions Private Limited sells professional services and the software that results from them. There is no physical product, no packaging and no shipment of any kind. We do not post discs, drives, printed manuals or hardware, and we run no warehousing or courier arrangement. No shipping charge, customs duty or delivery address is ever collected or required.

Delivery happens over the internet, into infrastructure you control: your Git hosting, your cloud account, your project tracker, your email. Where a client's security policy requires a different transfer mechanism, we agree it in writing in the statement of work before the engagement starts.

2. What you actually receive

A completed build engagement hands over the following. Every item is listed in your statement of work, so "delivered" is a checklist rather than an opinion.

• Source code — in your own Git repository, with the full commit history, not a zip file at the end
• A running deployment — in your own cloud account, in the region you choose, under credentials held by your named administrator
• Infrastructure as code — the environment definitions, pipelines, database schemas and migrations that reproduce the system
• Documentation — a README, an environment and runbook document, architecture decision records, and an API reference where the system exposes one
• A dependency and licence inventory, so your counsel reviews what is in the build rather than discovering it later
• Design files — flows, wireframes and prototypes produced during the engagement
• A live handover session, recorded, walking your engineers through the architecture, the deploy path and the failure modes

Marketing engagements deliver differently: campaign assets, tracking configuration inside your own ad and analytics accounts, and a reporting cadence agreed at kick-off. We work inside your accounts rather than ours, so nothing has to be migrated back if we stop.

3. When delivery is complete and title passes

Code reaches you continuously, not at the end: repository access from the first sprint, a working deployment on staging from the first release. Nothing is held back for a reveal.

Full intellectual property transfers to you on final payment — an assignment, not a licence, covering source code, designs, schemas, infrastructure definitions and documentation. Before final payment you may run the work in test and staging; production use ahead of payment is not licensed. On an early exit, IP in everything invoiced and paid still assigns to you whatever the reason, and the handover pack arrives within 10 business days of the effective date. The full position is in section 7 of our terms of service.

4. Indicative timelines

These are the windows we quote before a specification exists. They describe comparable work we have delivered; only a date inside a signed statement of work is a commitment.

Scroll the table sideways for the full detail.

Regulated domains — hospital systems, payments infrastructure, anything carrying formal audit evidence — land at the top of these ranges or beyond them, because review and evidence work is real work. We say so during scoping rather than afterwards. Billing and notice for each commercial model are compared on engagement models.

5. Acceptance and the review window

Each deliverable goes to a staging environment and is tested against the acceptance criteria written into the statement of work. You have ten working days to review it, unless your statement of work sets a different window. With no written response inside that period, the deliverable is treated as accepted so the schedule can move on.

Rejection is measured against those written criteria. Where a deliverable misses them, we fix and resubmit at no charge, and the review window restarts on the resubmitted version. Where the feedback describes something the criteria never included, it returns as a written change request with cost and schedule impact — a line drawn at kick-off, so it is not argued about at handover.

6. What we need from you, and what happens to the date

A delivery date assumes both sides move. From you we need a named decision-maker who can approve scope and releases, access to systems and third-party accounts within the timescales agreed at kick-off, test data, and approvals inside the review windows.

When those do not arrive, we do not absorb the delay quietly and then deliver late. The blocker appears in the weekly report the day it starts, and schedule dates move by at least the length of the delay, because reserved engineering time cannot be recovered afterwards. A dedicated team keeps billing while it waits, because those engineers are held for you and cannot be reassigned at short notice. Time-and-materials work bills only the hours actually worked, so a blocker on your side costs you schedule rather than money. Past ten working days we pause in writing and re-plan with you. If either side would rather stop than re-plan, the ordinary 30 days' notice applies in both directions, and the money position is in our refund policy.

7. Defects after acceptance versus new work

A 30-day defect window runs from go-live. Anything traceable to our build — a bug against the agreed criteria, a broken integration we wrote, a deployment step that fails — is fixed at no charge inside it, and we triage the report the same business day.

Three things sit outside that window and are quoted before work starts: behaviour that was never in the specification; failures caused by changes made after handover by you, another supplier or a third-party provider; and enhancements. Beyond the 30 days, and outside a maintenance agreement, fixes are chargeable. We tell you in writing which category a report falls into and why, rather than reclassifying quietly to raise an invoice.

8. Post-launch support — what is and is not included

An annual maintenance contract is a separate agreement, billed monthly. It covers monitoring and alert response, severity-tiered incident handling with defined response times, security patching and dependency upgrades, backup verification, and an agreed monthly allowance of enhancement work. Each month you receive a report of incidents raised, patches applied and changes shipped.

It does not cover work beyond the monthly allowance, which is quoted before it starts; third-party costs such as cloud hosting, licences and paid APIs, which stay in your own accounts and your own name; a new product line or a redesign, which is a fresh statement of work; or code another supplier has since changed, until we have reviewed what changed. Without a maintenance agreement there is no standing support commitment once the defect window closes — we say that at handover rather than implying open-ended cover.

9. How you see progress while it is being built

Most delivery failures are reporting failures first. The cadence here is fixed rather than left to goodwill:

• Two-week sprints, with a working demo at the end of every one. Slippage surfaces in a fortnight, not at a deadline
• A weekly written report — what shipped, what is next, what is blocked and who owns the blocker
• A named delivery lead who stays with the engagement, plus direct access to the engineers in a shared channel. You do not route questions through an account manager
• Your tracker, your board — Jira, Linear or whatever you already run, so progress is visible without having to ask for it
• A staging environment you can open at any time, from the first release onwards

We do not report progress as a percentage complete. It is the least reliable number in software delivery, and a running demo answers the same question honestly.

10. Questions about a delivery

Anything about a date, a handover or an acceptance decision: email [email protected] or call +91 817 979 7732. An engineer replies within one business day; on a live engagement your delivery lead answers directly. For a new enquiry, use the form on our contact page.

This policy sits alongside our terms of service, which govern scope, change control and IP. Where a signed statement of work or your organisation's own master services agreement sets different delivery, acceptance or support terms, that document wins.