Our proposed standard includes a 30-day defect-reporting window after written handover. Managed hosting, ongoing monitoring and new features require their own agreed scope.
01Included defect-support window
Unless the accepted proposal specifies otherwise, the standard starting point is 30 calendar days from the written handover date for reporting reproducible defects in the agreed deliverables. A defect is a feature that does not work as the accepted scope describes.
There is no extra development charge for a covered defect attributable to our delivered work. A report received within the window remains eligible for assessment even if resolving it takes longer. This arrangement does not restrict a remedy required by applicable law.
02What a covered report looks like
A website example is an agreed form or layout that fails under the supported conditions. A software example is an agreed calculation or authorised action that behaves incorrectly. An automation example is an approved rule that is implemented incorrectly.
Please provide the affected version, expected result, actual result and steps to reproduce the issue. If it cannot yet be reproduced, we will discuss the information needed to investigate rather than promise a fix without understanding the cause.
03Changes and work outside the window
New pages, modules, changed business rules, redesign requests, extra integrations, content updates and training beyond the scope are enhancements rather than defect fixes. We can quote for them separately.
A change made by the client or another developer may need a separate investigation. Provider API changes, expired subscriptions, hosting-resource issues and new browser or platform behaviour after delivery are assessed on their cause and the agreed maintenance coverage; they are not automatically charged or automatically covered.
04How to report an issue
Email info@orionsuite.in with the project name, affected URL or workflow, the version or deployment if known and the impact on users. Include screenshots or a short recording only where they do not expose private records, secrets or credentials.
Do not send passwords or full production databases by email. We agree any temporary access or diagnostic data required. Identify whether the issue blocks work, affects some users or has a practical workaround so it can be triaged.
05Acknowledgement and resolution
Support availability, response targets and escalation contacts should be agreed in the proposal or maintenance plan. This website does not promise 24/7 coverage, a fixed response time or a guaranteed resolution time for every incident.
We assess impact, reproducibility, access and dependencies before proposing a resolution plan. Provider intervention or client approval may be needed. If a service-level agreement is required, its coverage, exclusions and measurements must be agreed before relying on it.
06Ongoing maintenance options
An agreed maintenance plan can cover dependency updates, security patches, content changes, monitoring, backup checks or a defined amount of enhancement work. The plan should state its frequency, permitted actions, price and reporting.
Ongoing work is not automatically included because the application is hosted on EC2 or because a 30-day defect window was provided. Renewals or recurring payments require an expressly agreed arrangement; there is no automatic maintenance subscription under these standard terms.
07Hosting and provider responsibilities
An AWS EC2 deployment needs a named party responsible for the instance, operating system, application, billing, domains, certificates and access. Provider infrastructure responsibilities are different from the customer’s application and configuration responsibilities.
Where OrionSuite manages these tasks, the maintenance scope should say which tasks and access are included. Where the client manages them, handover should make that clear. The selected account, region and hosting plan determine costs and some operational capabilities.
08Backups, restores and live changes
Backup frequency, retention, storage location, restore testing and responsibility should be agreed for the deployment. A backup that exists has not necessarily been tested for recovery. We do not claim a universal backup schedule across projects.
A restore, migration or update affecting live data needs an agreed plan and authorisation. We should not overwrite a production database or remove client data as a routine troubleshooting step. The scope must identify any scheduled maintenance window or expected interruption.
09Client-owned code and third-party work
After full payment, the client owns the custom code as set out in the agreement and may choose who maintains it. Third-party components continue under their licences. Code ownership does not require purchasing ongoing support from OrionSuite.
Where another party changes the system, we may need to review that version before diagnosing it. We will distinguish a change-related issue from a defect in our delivery. Access to the current source and deployment may be necessary for accurate investigation.
10Ending a maintenance arrangement
A maintenance agreement should state the duration, cancellation notice, renewal process and handover responsibilities. When it ends, identify who will manage hosting, billing, monitoring, backups and outstanding incidents.
Any retained access should be reviewed and removed when no longer authorised. Cancellation and refunds for prepaid unused maintenance are assessed under the relevant agreement and applicable law rather than assumed to be non-refundable.
11Support questions
Email info@orionsuite.in to report a defect, discuss a maintenance plan or clarify operational responsibilities. For a new feature, explain the business result you need so we can scope the change.
Read Project Delivery & Handover for source files and ownership, and Payments, Cancellation & Refunds for commercial reconciliation. Project-specific written terms take priority over conflicting standard commercial details, subject to applicable law.