Governance first. Then the whole company.
How BuildBak® — a multi-state restoration franchisor and a heavy automation user for years — took Claude from the owner's own toolkit to a governed, company-wide Enterprise deployment, and then began building its own software with Claude Code.

Keenan Theron
Co-Founder
August 28, 2026 · 7 min read
Co-founder of Workiflow, a monday.com Platinum Partner and member of Anthropic's Claude Partner Network. Led the Claude enablement programme described here.
How BuildBak® — a multi-state restoration franchisor and a heavy automation user for years — took Claude from the owner's own toolkit to a governed, company-wide Enterprise deployment, and then began building its own software with Claude Code.
A franchisor whose product is a repeatable process
BuildBak® is a construction-centric restoration business operating as a franchisor from Framingham, Massachusetts, led by founder-owner Nate Hamel alongside his brother and co-owner Matt Hamel. Its franchise network runs across multiple states.
Restoration is emergency work. Jobs arrive unscheduled, run to insurance timelines, and are governed by documentation — scopes, agreements, and completion packages. What BuildBak franchises is a process: the same job, run the same way, in every territory.
That makes consistency and control the product. It also makes BuildBak unusually careful about any tool that touches customer data, or that lets a franchisee act outside the process.
Operating context
- Sector — construction and property restoration, emergency response
- Model — franchisor with a multi-state franchisee network
- Stack — monday.com as the operations hub, Make for automation, QuickBooks, Microsoft 365
- Relationship — Workiflow has managed BuildBak's platform and automation stack for over two years
- Claude plan — Claude Enterprise, selected on Workiflow's recommendation
The blocker was never interest. It was control.
BuildBak came to Workiflow ready to put Claude to work, but not ready to put it in front of a team. Before any rollout, an owner has to be able to answer a specific set of questions.
Who can see what. Which connectors can write rather than only read. What happens when an independently operated franchise connects an account to a shared system. Whether a private conversation stays private. And what the spend does as the seat count grows.
Those answers determined the plan. The administrative controls that answer them — single sign-on, custom roles and groups, connector governance, spend limits — come together fully on Claude Enterprise, so Workiflow recommended Enterprise and guided the sign-up.
Nate then set the sequence himself: work through the security constraints first, and only bring the wider team in after.
Questions to answer first
- Can anyone else read an individual's conversations?
- Can access to specific models be restricted by role?
- Can connectors be held to read-only by default?
- Can write actions be forced through an approval step?
- Can spend be capped per person?
Thirteen working sessions across six weeks
Workiflow ran a structured Claude enablement programme led by a certified Claude architect, working directly with the owner rather than through a training deck. Every session was a live working session on BuildBak's own account, and each was followed by a written recap and a short list of actions on both sides.
Phase 1 · Activation & governance
8 – 21 Jul
Phase 2 · Administrative controls
17 Jul – 12 Aug
Phase 3 · Capability & team enablement
21 Jul – 5 Aug
Phase 4 · Building with Claude Code
5 Aug – ongoing
Phases overlap by design. Governance work continued while capability work began, so the team was never waiting on a gate. The programme runs as a dedicated Claude workstream inside BuildBak's managed-services retainer with Workiflow.
Guardrails set before the first invitation went out
The account was configured from the administrative side down: custom roles and groups replacing blanket owner access, organisation-level context so every conversation starts knowing the business, and individual profile instructions on top of it.
Connector permissions were the substantive piece. Workiflow established a deny-by-default posture — unconfigured tools blocked outright, read-only as the standard, every write action held behind an explicit approval step — and every setting was verified live against real workflows rather than assumed.
Model access was then narrowed for the standard team, so capability matches role from the first invitation.
Delivered
- Custom roles and groups replacing undifferentiated owner-level access
- Organisation instructions plus individual profile instructions
- Deny-by-default connector policy — unconfigured tools blocked outright
- Approval-gated write actions, verified live against a real workflow
- Model access restricted by role for the standard team
Enterprise controls an owner operates himself
The requirement Nate cared most about was staying in control as the deployment grew: administering identity, access, and cost for the whole organisation without depending on the agency.
Workiflow configured Claude Enterprise's administrative layer end to end — single sign-on through BuildBak's identity provider, group-based rollout, spend governance — and handed it over documented, so the guardrails set in Phase 1 are controls BuildBak runs itself.
Admin-level oversight of the deployment was established at the same time, inside the governance the business already operates — so growth in seats never means growth in uncertainty.
Delivered
- Single sign-on enabled through the company's identity provider
- Enterprise admin console configured and operated by the client
- Admin-level oversight established across the deployment
- Staged rollout — a first cohort, then the wider team — run through groups
- Per-user monthly spend caps, keeping cost predictable as seats grow
- Full documentation retained by the client, so nothing depends on the agency
From a tool the owner used to a company capability
With the guardrails in place, the programme moved to what Claude is actually for at BuildBak. Sessions covered the practical judgement calls — chat versus a project, when a skill is the right shape and when it isn't, what Cowork handles, where Claude Code makes sense — rather than a feature tour.
The team built skills against real BuildBak work: a document-generation skill producing client-facing quotes on the company's own letterhead from a reference template, and a second for restructuring standard operating procedures. When the SOP skill proved unreliable across long conversations, Workiflow diagnosed why — a skill is a set of instructions, not an enforced sequence — and rebuilt it as a Project, where the instructions load every turn.
Certification paths were shared and an internal champion identified, so the capability outlives the engagement.
Delivered
- Document-generation skill producing branded client documents from a reference template
- SOP skill rebuilt as a Project, with the reasoning explained so the client can make the call next time
- Custom slash-command plugin for the development workflow in Claude Code
- Connector strategy across the operational stack, scoped to the deny-by-default policy
- Cowork introduced for large document projects
- Certification path shared and an internal champion identified
- A written recap after every session, with actions split by owner
The owner shipped his first working feature himself
The final phase moved from using Claude to building with it. Workiflow set Nate up with Claude Code on his own machine and proved a full deployment pipeline end to end — GitHub, Supabase and Vercel — before writing a line of product code, so every later change had a path to production.
Nate then built his first feature himself: an internal document-handling capability. He wrote the requirements, ran the build in Claude Code, and merged it.
That first feature was the start of a longer build, still under way. Claude Code remains the primary development tool for it, and the requirements behind it were authored and refined with Claude — the same working pattern, now applied to something bigger.
Delivered
- Claude Code installed and running on the client's own machine
- Full deployment pipeline proven end to end — a Next.js app across GitHub, Supabase and Vercel — before product work began
- Secrets handled properly — expiring keys, environment variables, never pasted into a conversation
- First feature built by the owner, not by the agency
- Requirements document authored with Claude and reviewed section by section with the client
- Claude Code adopted as the primary development tool for the work that followed
What changed
Outcomes
- From AI in one owner's hands to a governed Enterprise deployment — scoped, secured, and rolled out to the whole team in six weeks.
- Administrative oversight established across the deployment, operated by the owner.
- A non-technical owner shipped production software — his first feature, written and merged himself.
- The business is now building its own software with Claude Code — something it had never done before.
- The capability stayed in-house — a named champion, full client-held documentation and a certification path, not a dependency on the agency.
The difference between running my business with Claude and without it is like the difference between working with electricity and without it.
Nate Hamel
Founder & Owner · BuildBak®