Having recently audited several consultancy engagements where Twingate was deployed, I've noticed a significant variance in both the initial setup cost and the ongoing operational overhead. This directly impacts the total cost of ownership for the small business client, a metric often overlooked in favor of just the software subscription.
For a standard small business deployment (20-50 users, with a handful of key on-premises or cloud resources to secure), my recommended package structure focuses on predictable billing and eliminating future waste. The core components are:
* **Discovery & Architecture Session (Fixed Fee):** This is non-negotiable. We map all required access patterns (e.g., developer to staging database, accountant to on-prem file server). The goal is to define the absolute minimum set of policies, preventing a sprawl of unnecessary connectors and redundant access rules that complicate management later.
* **Base Deployment (Fixed Fee):** This includes:
* Provisioning the Twingate tenant and configuring the team.
* Deploying and configuring the necessary Connectors (typically two for redundancy) in the client's cloud (AWS/Azure) or on-premises.
* Defining the initial Resource and User Group structure based on the discovery session.
* Configuring the primary authentication method (e.g., SCIM with Azure AD, Google Workspace).
* **User Onboarding & Security Baseline (Per-User Fee):** A standardized package per user covering:
* Device enrollment and client installation.
* Basic security policy assignment (e.g., blocking non-compliant devices).
* Documentation of access revocation procedures.
* **Retainer for Ongoing FinOps (Monthly):** This is where cost control becomes operational. We schedule quarterly reviews to:
* Audit user accounts and deprovision inactive ones.
* Review access logs to identify and consolidate rarely used policies or resources.
* Assess Connector utilization in the cloud to potentially rightsize the instances they run on, as this is often a hidden infrastructure cost.
The critical pitfall to avoid is a one-time deployment with no ongoing oversight. Unchecked, you will see user counts creep up and resource policies multiply, leading to both increased direct license costs and unnecessary cloud compute spend for underutilized Connectors. The package must institutionalize periodic pruning.
Optimize or die.
CloudCostHawk
Totally agree on starting with a fixed fee for discovery. That scope creep later is a killer. 👍
When you're defining that minimum set of policies, how do you handle the client who inevitably asks "but what about future projects?" Do you lock the policy set to the discovery document and call changes a separate engagement, or do you bake in a small buffer?
Still learning.
You don't bake in a buffer. You price the initial policy set as a fixed deliverable. Future changes are a new SOW, billed hourly or as a retainer.
That "what about future projects" question is where the lock-in starts. If you give them an inch on policy management, you become their permanent admin. They need to own the operational model, not rent your brain indefinitely.
I generally align with your structure, but I'd split the **Base Deployment** fee into two distinct phases. Provisioning the tenant is administrative work, but deploying Connectors is infrastructure work with potential for complications.
The fixed fee for deploying Connectors must have a clear, predefined boundary. It covers deploying to *their* cloud account using a standard template (e.g., Terraform for AWS EC2). If their network configuration deviates from standard - unexpected VPC peering, restrictive NSGs, no outbound internet - that triggers a change order. You can't let the fixed fee absorb hours of network troubleshooting.
Also, include a standardized "handoff package" in that base fee: brief as-built docs and a 30-minute admin training session. It forces a clean break and defines the point where operational ownership transfers to them.
Mike
Yeah, the focus on the absolute minimum set of policies is spot on. It's so easy to just mirror existing network zones, but that recreates the same sprawl you're trying to fix.
To make that fixed-fee connector deployment repeatable, I've had good results using the Twingate Terraform provider to codify the initial setup. You can template the connector module so the base deployment literally runs a terraform apply against their cloud account. It locks in that "standard template" approach and the state file becomes part of the handoff docs.
Just curious, do you include any basic logging or monitoring for the connectors in that base fee? Even something simple like a dashboard for health status? I find that preempts a lot of "is it working?" calls later.
YAML is not a programming language, but I treat it like one.
Completely agree with locking changes into a new SOW - that's the only way to keep it clean. My caveat is that I build in a single "policy refinement" call about 2-3 weeks after go-live. No new projects, but we tweak the original set for any real-world snags we missed in discovery. It's a goodwill buffer that catches minor stuff and prevents them from feeling nickel-and-dimed on the first tiny change.
After that, any new project or access pattern is a separate ticket. I point them to Twingate's own docs for simple user adds, and make it clear that structural changes need professional services.
Benchmark or bust