The client owns the custom code after full payment. Handover should include the agreed files, access, documentation and a clear record of what has been delivered.
01Start with a written scope
We agree the business need, deliverables, exclusions, supported devices or systems, integrations and success criteria before starting. The scope should say what the client supplies and what OrionSuite builds.
A website project may cover page layouts and enquiry journeys; software may cover user roles, modules and reports; automation may cover triggers, conditions, approvals and failure handling. These examples do not add features to a project that has not purchased them.
02Discovery and required inputs
The project contact provides the relevant requirements, brand assets, content, sample data and access. Where existing systems are involved, we review available integration methods and constraints before promising a connection.
Use representative or anonymised information during discovery where possible. A dependency on a provider API, a paid account or authorised access should be identified early. Production access should follow an agreed method and scope.
03Design and implementation stages
The proposal defines the design or implementation stages and the reviews associated with them. We can use layouts, prototypes, staging pages or a limited working workflow to make decisions concrete before expanding the build.
Review comments should be consolidated through the nominated contact. Revision rounds included in the price must be described in the proposal. New functionality or a changed direction outside the agreed revisions becomes a written change request.
04Scheduling and dependencies
We provide a schedule appropriate to the scope and the availability of inputs. Dates should identify dependencies such as content approval, credentials, provider availability, testing and payment milestones.
If a dependency changes, we explain its effect and agree a revised plan. There is no single guaranteed turnaround for every project. Starting payment alone does not overcome an unavailable API, missing content or an unapproved business rule.
05Testing against the scope
Testing should reflect the project: responsive layouts and key journeys for a website; roles, calculations and important actions for software; triggers, approvals, retries and failure paths for automation. The proposal should identify who performs user acceptance testing.
We distinguish checks performed locally or in staging from a production acceptance test. Integrations with real provider accounts, existing business data and access permissions may need client participation. A successful build is not by itself proof that every production scenario works.
06Client review and written acceptance
We supply the agreed review version and explain how to report issues. Please identify the affected screen or workflow, expected outcome and steps to reproduce a problem. The review window is agreed for the project.
We record acceptance in writing against the stated criteria. Silence alone does not constitute acceptance under our standard approach. An item outside the scope is evaluated as a change request; a reproducible failure of an agreed feature is assessed as a defect.
07Production launch and migrations
Launch is included only where stated. Before deployment we agree the environment, account access, DNS changes, data migration, backup responsibility and any rollback arrangement needed for the specific system. Changes to an existing live system require authorisation.
AWS EC2 can host the deployment, but the instance, region, account owner, recurring costs and maintenance responsibilities should be specified. We do not assume permission to reset a live database or replace existing data simply because a development project is underway.
08Source code and ownership transfer
After full payment of the agreed project fees, the client owns the bespoke code and custom deliverables created for the engagement, with transfer documented in the agreement. We deliver the agreed repository or source archive and identify the release being handed over.
Third-party dependencies retain their original licences. Any pre-existing OrionSuite material used in the project must have been identified, including the client’s right to use it. Client ownership of custom code is distinct from ownership of AWS, a domain registrar or a commercial plugin platform.
09What the handover should include
The scope should list the handover items: source files, deployment or build instructions, relevant configuration guidance, asset files, dependency or licence notes and the operating instructions needed for the agreed use. For software or automation, this may include role configuration and a workflow summary.
Not every project includes a full training programme, extensive manuals or ongoing administration. Those items should be included explicitly if required. We identify remaining limitations and open items instead of silently treating them as accepted.
10Credentials, accounts and access removal
Client-owned accounts are preferred where practical. Credentials should be transferred through an agreed secure method; they must not be hard-coded into a source archive or published in a repository. The client should rotate temporary or shared credentials after transfer.
We agree which OrionSuite access remains necessary for the support window. Any access no longer needed should be removed. Account recovery, billing ownership and administrator permissions need to be clear before responsibility transfers.
11After handover
Unless the accepted proposal provides another period, our proposed standard includes 30 calendar days of fixes for reproducible defects in the delivered, agreed scope, beginning on the written handover date. Covered issues reported within that period can be assessed and fixed after the reporting window where necessary.
Ongoing maintenance, backups, uptime monitoring, new features and provider changes require an agreed arrangement. Read Support & Maintenance for what the support window includes and how to report an issue.
12Questions or delivery concerns
Email info@orionsuite.in with the project reference and the relevant milestone, deliverable or access question. We will use the accepted scope and review records to discuss the next step.
Where delivery cannot proceed or the engagement is cancelled, the settlement should address usable paid work, outstanding access and data responsibilities. See Payments, Cancellation & Refunds for the reconciliation process.