Service Delivery & Fulfilment Policy

1.1This service delivery and fulfilment policy is issued by STARECOM ("we", "us"), the operator of starecom.net and the provider of the services described on it.

1.2We supply digital services and digital deliverables. We do not sell, ship or deliver physical goods of any kind. Nothing is posted, couriered or freighted, so there are no shipping charges, no delivery addresses and no customs or import duties.

1.3This document is the services equivalent of a shipping policy: it says what you receive, how it reaches you, when the clock starts, how long things take, and what happens if we cannot deliver.

1.4It should be read with the Terms of Use & Service Agreement and the Refund & Cancellation Policy.

2.1The precise deliverables for your engagement are listed in your scope document, which is the authoritative statement. This clause describes the usual forms they take.

• A working system on a staging URL — available from the first milestone and accessible to you throughout the build, not only at the end.
• A live deployment to the production environment, on your infrastructure or on infrastructure we manage for you.
• Source code and assets, delivered into a repository in your ownership or as a downloadable archive.
• Credentials transfer — servers, domains, registrars, third-party accounts and API keys, handed over through a secure channel and never by plain email.
• A documentation and handover pack, described in clause 7.
• Written reports — architecture notes, security review findings, and the monthly report on managed operations agreements.

2.2Deliverables transfer to your ownership on payment in full for the relevant milestone, under clause 6 of the Terms of Use.

3.1Continuously, not in one drop. Work is delivered milestone by milestone to a staging URL you can open at any point. You are never waiting until the end to see whether the thing works.

3.2Progress is reported in writing at the interval set out in your scope document — weekly on project work.

3.3Each milestone is delivered with a written note saying what it contains, what changed, and what we need from you next.

3.4Go-live is a scheduled, agreed event with a rollback plan, not a surprise. Where the change is significant we agree a window in advance.

3.5Credentials and secrets are transferred through a secure channel agreed with you. We never send a password or key in plain text over email or chat.

3.6Delivery is complete for a milestone when the deliverables are available to you on staging or in production and the milestone note has been sent.

4.1The delivery clock starts when both of these are true: (a) you have accepted the scope document in writing, and (b) the deposit has cleared into our account. Not when the quote is sent, and not when the deposit is initiated.

4.2Where the scope document identifies inputs we need from you to begin — access, credentials, content, a decision — the clock starts when the last of those is received, and we will tell you when that is.

4.3Cleared payment means funds actually settled. Bank transfers can take several working days depending on route and currency, which is outside our control.

5.1These are indicative ranges, not promises. Your scope document contains the milestone plan and any dates that are binding. Anything not written into that document is an estimate given in good faith.

5.2Ranges assume the inputs in clause 6 arrive on time. They are elapsed time, not effort.

6.1Delivery is a joint exercise. We will tell you at scoping exactly what we need from you and when — typically content and copy, brand assets, access to existing systems, third-party account credentials, and decisions or approvals at defined points.

6.2If an input is late, the milestone that depends on it moves by at least the length of the delay. It is rarely one-for-one: our team is scheduled in blocks, and a week's delay can mean waiting for the next available block.

6.3We will tell you in writing as soon as a dependency is at risk of moving a date, along with the revised date, so there are no silent slips.

6.4Where a delay is sustained — no substantive response for 30 days — we may pause the engagement and reschedule it to the next available slot. Costs already incurred remain payable, and clause 3 of the Refund & Cancellation Policy applies to anything you cancel.

6.5Where the delay is ours, we tell you, we explain why, and we do not charge you for the delay.

7.1When a milestone is delivered you have 7 days to review it against the scope document and either accept it or tell us in writing what does not meet the scope.

7.2Anything within scope that we got wrong is corrected at no charge, and the review window restarts for the corrected part. Anything outside the scope is quoted as a change under clause 3.4 of the Terms of Use.

7.3If we hear nothing within the review window, the milestone is treated as accepted and becomes invoiceable. We will send a reminder before that happens rather than letting it pass silently.

7.4Acceptance of a milestone does not waive your rights in respect of defects that could not reasonably have been found during review.

8.1Every engagement ends with a handover pack, whether we go on to operate the system or you take it in-house. It contains:

• architecture notes — what the system is, what it talks to, and where everything lives;
• the repository, or a source archive, with the build and dependency instructions;
• environment and configuration documentation, with secrets transferred securely and separately;
• deployment and rollback procedures, written so a competent engineer who has never seen the system can follow them;
• a runbook covering routine maintenance, backups and restore, certificate renewal, and the known failure modes;
• a list of third-party components and their licences;
• the security review findings and what was done about them;
• a register of accounts and credentials, and confirmation of what has been transferred to you.

8.2A project you cannot take elsewhere is not finished work. The handover pack exists so that leaving us is a decision rather than a hostage situation.

9.1Defects within scope reported during the review window are corrected at no charge (clause 7).

9.2After the review window, corrective and enhancement work is quoted separately unless you hold a support retainer or managed operations agreement, in which case it is handled within your agreed capacity and response window.

9.3Response windows for retainers and managed operations are stated in your agreement and in your written brief.

10.1If it becomes clear that we cannot deliver what was agreed — because the scope was wrong, because a third-party dependency has changed, or because of anything on our side — we tell you as soon as we know, not at the deadline.

10.2We will then set out the options in writing: a revised scope and quote, delivery of a reduced but coherent scope, or termination.

10.3If we cannot deliver and no alternative is agreed, you pay only for accepted milestones and everything else is refunded, under clause 3.4 of the Refund & Cancellation Policy.

10.4Where the failure is ours, we will also help you transfer the work to another supplier at no charge, including the handover pack for whatever exists.

10.5Events outside reasonable control are dealt with under clause 14 of the Terms of Use.

11.1Questions about delivery on a live engagement go to your usual contact, or to .

11.2If delivery has gone wrong and you are not satisfied with the answer, use the Complaints & Dispute Resolution procedure, which sets out acknowledgement and resolution windows and the escalation route.