OWNSTACK
0.0 Legal Dialectics
This protocol governs the engineering relationship between OwnStack Solutions Pvt Ltd and the Principal. Engagement implies total acceptance of the technical and fiscal constraints defined herein.
1.0 Scope of Engagement & Deliverables Definition
- • This quotation defines a specific and limited scope of services, based strictly on the requirements discussed and documented at the time of proposal.
- • Only those features, modules, workflows, and deliverables explicitly mentioned in the quotation (including annexures, technical summaries, or scope descriptions) are included.
- • Any functionality, enhancement, system behavior, integration, automation, or optimization not explicitly documented shall be considered excluded.
- • The client acknowledges that software development inherently involves assumptions based on provided inputs; changes to these assumptions may affect outcomes.
| Aspect | Clarification |
|---|---|
| Included Scope | Features, modules, pages, integrations explicitly listed |
| Excluded Scope | Any implied, assumed, or verbally discussed features |
| Design Coverage | UI/UX as per agreed direction; major redesigns excluded |
| Performance | Reasonable industry standards unless specified |
| Compatibility | Modern browsers/devices unless otherwise stated |
2.0 Change Management & Scope Expansion
- • Any modification to the agreed scope will be treated as a Change Request (CR).
- • Change Requests may arise due to evolving business needs, regulatory changes, or third-party limitations.
- • Each Change Request will be evaluated independently for effort, feasibility, and cost implications.
- • No Change Request shall be executed without explicit written approval from the client.
| Parameter | Consideration |
|---|---|
| Functional Impact | Addition or modification of features or workflows |
| Technical Impact | Database changes, architecture refactor, new integrations |
| Timeline Impact | Extension of delivery milestones |
| Commercial Impact | Revised pricing or additional charges |
| Approval Mode | Email or written confirmation mandatory |
3.0 Project Execution, Dependencies & Timelines
- • Project timelines are indicative estimates, not fixed guarantees.
- • Execution depends on client-side inputs such as content, approvals, and credentials.
- • Delays due to client dependencies will extend timelines without penalty.
- • The service provider may re-sequence tasks for operational efficiency.
| Dependency Type | Responsibility |
|---|---|
| Content (text/images/data) | Client |
| Brand assets & guidelines | Client |
| Third-party credentials & licenses | Client |
| Feedback & approvals | Client |
| Development & deployment | Service Provider |
4.0 Commercial Terms & Payment Structure
- • All pricing is project-based, derived from estimated effort and complexity.
- • This quotation remains valid only for the stated validity period.
- • Payments are milestone-driven to ensure continuity and project momentum.
| Stage | Description | Payment |
|---|---|---|
| Project Initiation | Requirement confirmation & resource allocation | Advance required |
| Design / Architecture | Wireframes, layouts, system planning | As per milestone |
| Development Phase | Core development & integrations | As per milestone |
| Final Delivery | Deployment & handover | Full settlement |
Delayed payments may result in: work suspension, resource reallocation, or revised timelines.
Payments once received are non-refundable for completed or in-progress work.
5.0 Taxation, Duties & Statutory Considerations
- • Any applicable taxes shall be applied as per prevailing laws at the time of invoicing.
- • Tax applicability may vary depending on registration status or regulatory changes.
- • No tax credit or statutory benefit is implied unless explicitly stated on the invoice.
6.0 Hosting, Infrastructure & Third-Party Services
- • Projects may depend on third-party platforms including hosting providers, APIs, or cloud services.
- • The service provider does not control third-party uptime, pricing, or policy changes.
- • Any limitation or discontinuation by third-party providers is outside the scope of liability.
- • Ongoing costs for third-party services are borne by the client unless expressly included.
| Component | Responsibility |
|---|---|
| Hosting subscription | Client |
| Domain registration | Client |
| Paid APIs / tools | Client |
| Configuration & setup | Service Provider |
| Ongoing monitoring | As per support agreement |
7.0 Intellectual Property & Usage Rights
- • Upon receipt of full payment, ownership of project-specific deliverables is transferred to the client.
- • Generic frameworks and reusable components remain the intellectual property of the service provider.
- • Client data and business logic are treated as confidential and are never reused.
8.0 Support, Maintenance & Post-Delivery Assistance
Post-delivery support is limited to bug fixes related to delivered scope.
| Support Aspect | Included | Excluded |
|---|---|---|
| Bug fixes | ✔ | — |
| Deployment stabilization | ✔ | — |
| Feature enhancements | — | ✖ |
| Platform upgrades | — | ✖ |
| Infrastructure migration | — | ✖ |
9.0 Confidentiality & Data Protection
- • All information exchanged during the engagement is treated as confidential.
- • Neither party shall disclose sensitive information without written consent.
- • Confidentiality obligations survive project completion or termination.
10.0 Limitation of Liability
- • Liability is limited strictly to the amount paid for the specific service under dispute.
- • The service provider is not liable for indirect or consequential losses including business interruption or data loss caused by third-party systems.
11.0 Suspension, Termination & Project Abandonment
| Scenario | Outcome |
|---|---|
| Payment delay beyond agreed terms | Project suspension |
| No client communication (30+ days) | Project deemed abandoned |
| Restart after abandonment | New timeline & commercials |
- • Work completed up to termination remains payable.
- • Deliverables corresponding to paid milestones will be shared.
12.0 Governing Law & Jurisdiction
- • This engagement shall be governed by the laws of India.
- • Jurisdiction shall lie exclusively with courts in Mumbai, Maharashtra.
13.0 Acceptance, Go-Live Support, AMC & Change Classification
13.1 Scope Approval & Stakeholder Sign-Off
All features mentioned in this quotation have been:
- • Reviewed
- • Discussed
- • Mutually approved
by all relevant stakeholders representing the client.
The client confirms that the approved scope accurately reflects their current business requirements and expectations.
Upon approval, the scope is finalised ("Scope Freeze"), and development proceeds accordingly.
13.2 Go-Live Support (Non-AMC Engagements)
If an AMC is NOT procured, a 15-day Go-Live Support window will be provided for:
- • Bug fixing
- • Error resolution
- • Deployment stabilization
- • Ensuring approved features are functioning as intended
This does NOT include:
- • Enhancements
- • Feature additions
- • Design changes
- • Performance optimizations
- • New integrations
Upon completion of the 15-day window, the engagement shall be deemed successfully closed.
13.3 AMC-Based Support (If Procured)
If an AMC is procured, post-deployment support continues strictly as per AMC Terms & SLA.
The AMC governs:
- • Support scope
- • Response times
- • Maintenance coverage
- • Exclusions and limitations
Any request outside the AMC scope shall be handled as a separate chargeable engagement.
13.4 Change Classification: Minor vs Major Changes
To avoid ambiguity, changes requested after scope approval are classified as follows:
Minor Changes (May Be Accommodated)
- • Small UI text changes
- • Minor layout adjustments
- • Configuration-level tweaks
- • Non-structural refinements that do not impact: Core logic, Database schema, Architecture, Timelines
Minor changes may be accommodated at the service provider's discretion.
Major Changes (Chargeable & Out of Scope)
Any change involving one or more of the following shall be considered Major and chargeable:
- • Addition of new features or workflows
- • Modification of approved business logic
- • Database or architecture changes
- • New third-party integrations
- • Revisions impacting timelines, performance, or security
- • Any requirement not documented in the original quotation
All major changes will:
- • Be treated as Change Requests (CRs)
- • Require revised commercial terms
- • Commence only after written approval
13.5 No Refund Policy
All payments made under this quotation are non-refundable.
This applies irrespective of:
- • Project phase
- • Partial usage
- • Change of business priorities
Payments are allocated against:
- • Engineering effort
- • Resource reservation
- • Time and planning investment
Refunds are explicitly excluded, except where required by applicable law.
13.6 Final Acknowledgement
The client acknowledges that:
- • The delivered solution aligns with the approved scope
- • Functionality has been reviewed and accepted during testing / go-live
- • Any future changes beyond this scope are subject to separate commercial discussion
Service Protocol & Handover Terms
The definitive technical and legal instrument governing Intellectual Sovereignty, Build-Operate-Transfer models, and infrastructure liabilities.
Legal Dialectics
Deterministic Interpretations
BOT Model Supremacy
Scope of Engagement & Deliverables Definition
- •This quotation defines a specific and limited scope of services, based strictly on the requirements discussed and documented at the time of proposal.
- •Only those features, modules, workflows, and deliverables explicitly mentioned in the quotation (including annexures, technical summaries, or scope descriptions) are included.
- •Any functionality, enhancement, system behavior, integration, automation, or optimization not explicitly documented shall be considered excluded.
- •The client acknowledges that software development inherently involves assumptions based on provided inputs; changes to these assumptions may affect outcomes.
Scope Interpretation Table
| Aspect | Clarification |
|---|---|
| Included Scope | Features, modules, pages, integrations explicitly listed in the quotation |
| Excluded Scope | Any implied, assumed, or verbally discussed features not documented |
| Design Coverage | UI/UX as per agreed direction; major redesigns excluded |
| Performance Benchmarks | Reasonable industry standards unless explicitly specified |
| Compatibility | Modern browsers/devices unless otherwise stated |
Change Management & Scope Expansion
- •Any modification to the agreed scope—functional, technical, visual, or architectural—will be treated as a Change Request (CR).
- •Change Requests may arise due to evolving business needs, regulatory changes, third-party limitations, or revised client expectations.
- •Each Change Request will be evaluated independently for effort, feasibility, impact on timelines, and cost implications.
- •No Change Request shall be executed without explicit written approval from the client.
Change Request Evaluation Matrix
| Parameter | Consideration |
|---|---|
| Functional Impact | Addition or modification of features or workflows |
| Technical Impact | Database changes, architecture refactor, new integrations |
| Timeline Impact | Extension of delivery milestones |
| Commercial Impact | Revised pricing or additional charges |
| Approval Mode | Email or written confirmation mandatory |
Project Execution, Dependencies & Timelines
- •Project timelines are indicative estimates, not fixed guarantees, and are based on assumptions of timely collaboration.
- •Execution is dependent on client-side inputs such as content, approvals, credentials, infrastructure access, and decision-making.
- •Delays attributable to client dependencies will automatically extend timelines without penalty or liability.
- •The service provider reserves the right to re-sequence tasks for technical or operational efficiency.
Dependency Responsibility Table
| Dependency Type | Responsibility |
|---|---|
| Content (text/images/data) | Client |
| Brand assets & guidelines | Client |
| Third-party credentials & licenses | Client |
| Feedback & approvals | Client |
| Development & deployment | Service Provider |
Commercial Terms & Payment Structure
- •All pricing is project-based, derived from estimated effort, complexity, risk, and resource allocation.
- •This quotation remains valid only for the stated validity period and may be revised thereafter.
- •Payments are milestone-driven to ensure continuity, priority allocation, and project momentum.
Payment Milestone Structure
| Stage | Description | Payment Expectation |
|---|---|---|
| Project Initiation | Requirement confirmation & resource allocation | Advance required |
| Design / Architecture Phase | Wireframes, layouts, system planning | As per milestone |
| Development Phase | Core development & integrations | As per milestone |
| Final Delivery / Go-Live | Deployment & handover | Full settlement |
Delayed payments may result in:
- →Temporary work suspension
- →Reallocation of assigned resources
- →Revised delivery timelines
Payments once received are non-refundable for completed or in-progress work.
Taxation, Duties & Statutory Considerations
- •Any applicable taxes, levies, or statutory charges shall be applied as per prevailing laws at the time of invoicing.
- •Tax applicability may vary depending on registration status, jurisdiction, or regulatory changes.
- •No tax credit, statutory benefit, or compliance obligation is implied unless explicitly stated on the invoice.
Hosting, Infrastructure & Third-Party Services
- •Projects may depend on third-party platforms including hosting providers, APIs, payment gateways, or cloud services.
- •The service provider does not control third-party uptime, pricing, performance, or policy changes.
- •Any limitation, outage, pricing revision, or discontinuation by third-party providers is outside the scope of liability.
- •Ongoing costs for third-party services are borne by the client unless expressly included.
Third-Party Responsibility Table
| Component | Responsibility |
|---|---|
| Hosting subscription | Client |
| Domain registration | Client |
| Paid APIs / tools | Client |
| Configuration & setup | Service Provider |
| Ongoing monitoring | As per support agreement |
Intellectual Property & Usage Rights
- •Upon receipt of full payment, ownership of project-specific deliverables is transferred to the client.
- •Generic frameworks, internal utilities, development methodologies, and reusable components remain the intellectual property of the service provider.
- •Client data, business logic, and proprietary information are treated as confidential and are never reused.
Support, Maintenance & Post-Delivery Assistance
- •Post-delivery support is limited to bug fixes related to delivered scope.
- •Support does not include enhancements, upgrades, migrations, or new development unless separately agreed.
- •Ongoing support or AMC arrangements are governed under a separate agreement.
Support Coverage Overview
| Support Aspect | Included | Excluded |
|---|---|---|
| Bug fixes | — | |
| Deployment stabilization | — | |
| Feature enhancements | — | |
| Platform upgrades | — | |
| Infrastructure migration | — |
Confidentiality & Data Protection
- •All information exchanged during the engagement is treated as confidential.
- •Neither party shall disclose sensitive information without written consent.
- •Confidentiality obligations survive project completion or termination.
Limitation of Liability
- •Liability is limited strictly to the amount paid for the specific service under dispute.
- •The service provider is not liable for indirect, incidental, or consequential losses including business interruption or data loss caused by third-party systems.
Suspension, Termination & Project Abandonment
Termination Conditions Table
| Scenario | Outcome |
|---|---|
| Payment delay beyond agreed terms | Project suspension |
| No client communication (30+ days) | Project deemed abandoned |
| Restart after abandonment | New timeline & commercials |
- →Work completed up to termination remains payable.
- →Deliverables corresponding to paid milestones will be shared.
Governing Law & Jurisdiction
- •This engagement shall be governed by the laws of India.
- •Jurisdiction shall lie exclusively with courts in Mumbai, Maharashtra.
Acceptance, Go-Live Support, AMC & Change Classification
13.1 Scope Approval & Stakeholder Sign-Off
All features, functionalities, modules, and deliverables mentioned in this quotation have been:
- •Reviewed
- •Discussed
- •Mutually approved
by all relevant stakeholders representing the client.
The client confirms that the approved scope accurately reflects their current business requirements and expectations.
Upon such approval, the project scope is considered finalised ("Scope Freeze"), and development proceeds accordingly.
Any functionality delivered is based strictly on this mutually approved scope.
13.2 Go-Live Support (Non-AMC Engagements)
If an Annual Maintenance Contract (AMC) is NOT procured, the service provider shall offer:
A 15 (fifteen) calendar day Go-Live Support window, commencing from the official production deployment date.
This support period is strictly limited to:
- •Bug fixing
- •Error resolution
- •Deployment stabilization
- •Ensuring that approved features are functioning as intended
This support does not include:
- •Enhancements
- •Feature additions
- •Design changes
- •Performance optimizations
- •New integrations
Upon completion of the 15-day window, the engagement shall be deemed successfully closed.
13.3 AMC-Based Support (If Procured)
If the client opts for an Annual Maintenance Contract (AMC):
Post-deployment support shall continue strictly as per the AMC-specific Terms & Conditions and SLA.
The AMC governs:
- •Support scope
- •Response times
- •Maintenance coverage
- •Exclusions and limitations
Any request outside the AMC scope shall be handled as a separate chargeable engagement.
13.4 Change Classification: Minor vs Major Changes
To avoid ambiguity, changes requested after scope approval are classified as follows:
Minor Changes (May Be Accommodated)
- •Small UI text changes
- •Minor layout adjustments
- •Configuration-level tweaks
- •Non-structural refinements that do not impact: Core logic, Database schema, Architecture, Timelines
Minor changes may be accommodated at the service provider's discretion, provided they do not materially affect scope or delivery.
Major Changes (Chargeable & Out of Scope)
Any change that involves one or more of the following shall be considered Major and chargeable:
- •Addition of new features or workflows
- •Modification of approved business logic
- •Database or architecture changes
- •New third-party integrations
- •Revisions impacting timelines, performance, or security
- •Any requirement not documented in the original quotation
All major changes will:
- •Be treated as Change Requests (CRs)
- •Require revised commercial terms
- •Commence only after written approval
13.5 No Refund Policy
All payments made under this quotation are non-refundable.
This applies irrespective of:
- •Project phase
- •Partial usage
- •Change of business priorities
Payments are allocated against:
- •Engineering effort
- •Resource reservation
- •Time and planning investment
Refunds are explicitly excluded, except where required by applicable law.
13.6 Final Acknowledgement
The client acknowledges that:
- •The delivered solution aligns with the approved scope
- •Functionality has been reviewed and accepted during testing / go-live
- •Any future changes beyond this scope are subject to separate commercial discussion