Trust
What protects your business records.
Four promises about how your workspace behaves, and a plain list of what we do not hold.
Your workspace stays separate.
Your records are yours. There is no shared view, no way for another workspace to reach them, and no administrator mode that reads everything.
People only get the access they need.
Four levels of access, from full control down to read-only. Someone who should not be able to change something cannot change it. Not just hidden from the button, actually refused.
Sensitive changes ask again.
Billing, exports and changes to who can do what need a second check at the moment they happen, not a login from hours ago on a laptop left open.
Your connected accounts stay off the browser.
When you connect a calendar, an inbox or a payment account, those credentials live on the server and never reach the page you are looking at.
Technical details
One workspace cannot see another
Isolation is enforced in the database rather than in application code. Every query resolves against the workspace the request is authorised for, so a bug in a screen cannot widen what that screen can read.
There is no cross-workspace view, no shared table a query could fall through to, and no “admin mode” that reads everything.
Four roles, checked where the action happens
Owner, admin, operator and viewer. An owner can do everything including billing. An admin configures the workspace and manages members but cannot reach billing. An operator runs the business and changes no configuration. A viewer reads and writes nothing.
Permission is checked at the point the action is performed, not only where the button is drawn. Hiding a control is presentation; refusing the action is security, and both happen.
Privileged actions ask for a second factor again
Billing, data export and permission changes require step-up authentication at the moment they are performed, not merely a session that was authenticated hours earlier on a laptop that has since been left open.
A refusal for missing assurance is a distinct outcome from a refusal for missing permission, and the two are never conflated.
Provider credentials stay on the server
Connecting Gmail, Google Calendar, HubSpot, Calendly, Stripe or an analytics provider stores credentials server-side and scoped to the workspace that granted them. They are never present in the browser.
A capability that has not been built cannot be invoked even with valid credentials. The contract is a gate that runs before the provider call, not documentation about it. A fully credentialled read has been refused on that basis.
Public client links are narrow by design
Four surfaces are open to people with no account: an application form, a booking page, a booking-management page and an agreement to sign. Each carries a token that identifies exactly one form, booking or agreement and grants nothing else.
Those links are never published, never linked from a marketing page, and excluded from search indexing. A token in a public link is a token in a referrer header, a proxy log and eventually a search result.
A billing failure never destroys anything
The worst state a lapsed or cancelled subscription can produce is read-only, which preserves viewing and export. There is no billing state that means “delete the records”.
A failed payment continues access while the provider retries, because a card expiring is not a decision to stop running a business.
Software proposes; a person approves
An agent or a recommendation produces a proposal. A person approves it. A third, separate step carries it out. Nothing acts on the business because a model suggested it.
Every suggestion is presented with the evidence it rests on and with what it could not check.
The four public links, in full
Application forms
/f/…Someone applying to work with the coach.
No account, no sign-in. The submission lands on the CRM as a person and an opportunity.
Booking a time
/book/…A prospect picking a slot from the coach’s real availability.
Bookable times respect the coach’s hours and, where a calendar is connected, their busy periods.
Managing that booking
/booking/…The same person, afterwards.
View, reschedule or cancel from the link they were sent. Still no account.
Signing an agreement
/sign/…A client reviewing and signing what they are buying.
Reviewed and signed from a secure link. Signing never requires creating an account.
Everything else is behind the sign-in. The list is exact and deliberately short.
Audit & governance surfaces
Every configuration and membership change is already written to the workspace audit log. No screen reads it back yet, so this is recorded but not viewable.
It is part of Team and it is not built yet, so the plan comparison says “coming later” rather than showing a tick. We would rather tell you here than let you find out afterwards.
What we do not have.
- No SOC 2, ISO 27001, HIPAA or PCI DSS certification. We hold none of these, and no badge for any of them appears on this site.
- No penetration-test seal, no third-party audit report, and no uptime guarantee.
- Card details are handled by Stripe, in Stripe’s own interface. They never pass through MVP Coaching.
If a certification would decide it for you, ask. A clear no is more useful than a badge that turns out to mean something narrower than it looked.