Plain language, specific to how we work. We don’t claim certifications we don’t hold.
We request access to what a specific build requires, not blanket access to every system you run. Access is scoped to the engagement and revoked or handed back when the work is done.
Where a platform supports role-based or scoped permissions, we use them instead of admin-level access by default. If a build genuinely requires broader access, we say so and explain why before requesting it.
We don’t ask for or store your master credentials outside the systems built for that purpose. Service accounts and API keys are created per integration, so a single credential doesn’t unlock everything.
Automations run in infrastructure scoped to your engagement: typically your own accounts on the platforms you already use, or a dedicated environment we set up and hand over. We’ll tell you exactly where, per build.
Wherever practical, systems are built inside accounts your business owns (your CRM, your automation platform, your cloud account), not a shared account we control on your behalf. That’s what makes handover possible.
AI is used only where it earns the responsibility: where it’s doing part of the actual work, not decorating a page. Model choice depends on the task; we’ll tell you which providers are involved in any build that uses AI.
We do not use your business or customer data to train a model. Where a third-party AI provider is used, we configure it according to that provider’s available data-use settings and disclose what those are.
Anywhere a decision involves judgment, risk, customer communication, or sensitive data, a human stays in the loop. AI handles the parts of a workflow that are genuinely mechanical, not the parts that require judgment.
Builds that touch customer data or trigger customer-facing actions get logging so you can see what ran, when, and on what input. Not a black box you have to trust blindly.
Automations are built to fail loudly, not silently. When something breaks, it should be visible to your team quickly, with a defined fallback rather than a stalled process nobody notices.
Systems we build get a monitoring plan appropriate to what they do, from a simple status check to alerting on specific failure conditions. This is scoped per build and covered explicitly in the handover.
Every build ships with documentation covering what it does, how it’s configured, and how to change it. Documentation is written for your team to use without us, not as a formality.
We tell you which third-party platforms and services a build depends on, so you know your actual dependency surface, not just "it works."
What we build for you is yours. Code, workflow configurations, and documentation belong to your business, not to SMB Ops.
Handover is part of the deliverable, not an afterthought. That includes access, documentation, and a walkthrough with whoever on your team will own the system going forward.
Third-party APIs change or deprecate features outside anyone’s control. Where we’re engaged on an ongoing basis, that monitoring and maintenance is part of the retainer. Where we’re not, you own the system and can maintain it yourself, hire us for the fix, or bring in someone else. The documentation makes that possible either way.
We don’t hold or claim SOC 2, HIPAA, or ISO 27001 certification. If your engagement requires a specific compliance framework, tell us on the discovery call. We’ll tell you plainly whether we can meet it before scoping anything.
Bring them to the discovery call. If we're not the right fit for your compliance or risk requirements, we'll say so.
If we're not the right fix, we'll say so on the call and point you somewhere better.