Client Ownership & Responsibility
This page defines what clients own and are responsible for. These boundaries are fundamental to our model.
Core Principle
Clients own their systems, data, and decisions. We enable and advise; we do not own or operate.
Ownership Model
Client Ownership
Systems
Clients own and control:
- All installed software — The platforms we help implement belong to the client
- All configurations — Every setting, customization, and integration
- All credentials — Administrative access is the client's, not ours
- Source code access — For any customizations or extensions
- Technical decisions — Final authority on technical choices rests with the client
"We will never hold your systems hostage. You own everything we help you create, and you can operate without us at any time."
Data
Clients own and control:
- All business data — Every record, document, and file
- User data — Customer and employee information
- Configuration data — System settings and preferences
- Integration data — Data flowing between systems
- Backups — Responsibility for backup and recovery is the client's
"Your data belongs to you. We may access it during our work with your permission, but we do not store, retain, or claim any rights to it."
Infrastructure
Clients are responsible for:
- Hosting environment — Servers, cloud resources, or on-premises hardware
- Network — Connectivity, security, and access control
- Backups and disaster recovery — Protecting against data loss
- Security — Securing systems against unauthorized access
- Performance — Ensuring adequate resources for system operation
"We do not provide hosting or infrastructure. You must arrange and operate your own environment. We can advise on requirements, but operation is your responsibility."
Client Responsibilities
During Engagement
| Responsibility | What It Means |
|---|---|
| Provide access | Give us the access we need to do our work |
| Provide stakeholders | Make decision-makers and subject matter experts available |
| Make decisions | We advise; you decide |
| Validate work | Review and confirm our deliverables |
| Communicate constraints | Tell us about limitations and requirements |
After Engagement
| Responsibility | What It Means |
|---|---|
| Operate systems | Run and maintain systems day-to-day |
| Apply updates | Keep software current and patched |
| Manage users | Handle user provisioning and access |
| Monitor systems | Watch for problems and performance issues |
| Handle incidents | Respond to and resolve operational issues |
| Maintain documentation | Keep system documentation current |
Our Role vs. Client Role
| Activity | Our Role | Client Role |
|---|---|---|
| System selection | Advise and evaluate | Decide and own |
| Implementation | Guide and review | Execute and own |
| Configuration | Recommend and verify | Execute and maintain |
| Operations | Not involved | Full responsibility |
| Maintenance | Not involved | Full responsibility |
| Support | Not involved (by default) | Arrange separately |
| Data | Access during engagement only | Own permanently |
Why This Matters
For Clients
- No lock-in: You can engage other consultants, vendors, or internal staff without our permission or involvement
- Full control: You make all final decisions about your systems
- True ownership: Open-source platforms mean no vendor can take away your access
For Us
- Clear boundaries: We are not responsible for operational failures
- Sustainable engagements: We can step away knowing clients are capable
- Focus on value: We advise where we add value, not where we don't
How to Communicate This
When Asked "Will You Manage This For Us?"
"Our model is specifically designed around client ownership. We provide guidance and enablement, but you operate and maintain your own systems. This protects you from dependency on any single vendor, including us."
When Asked "Who's Responsible If Something Goes Wrong?"
"You are responsible for your systems and their operation. We're responsible for the quality of our advice and guidance. If we guide you incorrectly, that's on us. If an operational issue occurs after we've left, that's your responsibility to handle."
When Asked "What If We Can't Operate This Ourselves?"
"Then we need to discuss whether you're ready for this type of engagement. Our model requires that you have or are building internal capability. If you need fully managed services, that's a different type of vendor relationship than what we offer."
Documentation and Handover
Every engagement should end with:
- Complete documentation — What we did and how
- Knowledge transfer — Training for people who will operate the systems
- Clear handover — Explicit end of engagement, beginning of client operation
- Independence test — Confirm client can operate without us
"Our job is to make ourselves unnecessary. A successful engagement ends with you fully capable of operating without us."