The Technology Stewardship Protocol
The rules we agree to work under.
Technology stewardship is not yet a recognised profession, so there is no established standard to point at. We are writing one down and publishing it — partly so our clients can hold us to it, and partly because we think other firms should be able to adopt it.
Most of what goes wrong in small-business technology is not a technical failure. It is a knowledge failure: the person who understood the setup left, the agency that built the site stopped answering, the domain was registered on someone's personal card, and nobody can say with confidence who owns what.
These twelve principles are our answer to that. They are ordinary commitments, deliberately unglamorous, and each one is written so you can tell whether we are keeping it.
Principle 01
Client ownership
The client's technology belongs to the client.
Domains, cloud accounts, software subscriptions, data and documentation are registered in the client's name wherever it is practical. A steward may administer a system, but the client must never become the tenant of their own technology.
Principle 02
Human relationship
A person, not a portal.
The client must be able to reach a human being who already knows their company. No dashboard is required to receive value, and no client is ever made to explain their business to a stranger in order to get help.
Principle 03
Persistent institutional memory
What we learn is written down.
Every system, vendor, dependency and account owner is recorded in a canonical technology record. Knowledge that exists only in a steward's head has not yet been captured, and is treated as unfinished work.
Principle 04
Transferability
Any competent successor can take over without starting from zero.
The record is maintained to a standard where another provider could read it and continue. This is the practical test of whether the documentation is real, and it is checked rather than assumed.
Principle 05
Vendor independence
We are paid by the client and by no one else.
No commissions, referral fees, revenue shares or reseller margins from software vendors. A recommendation must be traceable to the client's needs alone, and the client is entitled to ask why.
Principle 06
Least necessary access
Hold the minimum access required, and no more.
A steward should know how to obtain access without unnecessarily becoming the sole holder of the secret. Where a client's own password manager can hold a credential, it holds it; we record where access lives and how it is recovered.
Principle 07
Auditable operations
Who asked, who approved, who did it, and when.
Consequential changes carry a record of their request, approval, execution and result. An audit trail is part of the work itself, not a report assembled afterwards.
Principle 08
Continuity
The client survives any single departure — including ours.
An employee leaving, a developer disappearing, a vendor failing, or Buki itself ceasing to exist must not stop the client from operating. Continuity is designed for at the start of the relationship, not improvised at the end of it.
Principle 09
Proactive care
The client should not have to remember.
Renewals, expiries, certificates, contract dates and scheduled reviews are watched on the client's behalf. Being told about a domain three weeks early is worth more than being rescued the day after it lapses.
Principle 10
Clear responsibility
Someone is always accountable, by name.
Every client has a named steward. When a problem crosses into another party's territory, the steward keeps ownership of the coordination even when a specialist performs the work.
Principle 11
Recorded decisions
Important choices keep their reasoning.
When a company selects a system, the context, the alternatives considered and the reason for the choice are recorded. Years later the decision can be understood — and revisited — by people who were not in the room.
Principle 12
A finite portfolio
One steward, no more than forty-nine companies.
The limit exists so the relationship stays genuine and the knowledge stays real. Buki grows by adding stewards, never by adding companies to a steward who is already full.
Open methodology
Anyone may use this.
The Protocol is not proprietary. If another firm wants to serve its own finite portfolio under these principles, we would consider that a good outcome. Our ambition is to demonstrate that technology stewardship can be a professional discipline — not to be the only company practising it.
We are also writing down the practical parts — documentation standards, handover formats, the data schema behind a technology record — and intend to publish those as they stabilise. A standard nobody can implement is just a manifesto.
Getting started
Hold us to it.
These principles are only worth something if a client can check them. Ask us about any one of them before you sign anything.
Or email us directly at yarsahimalaya@gmail.com.