Small teams fail kits in a specific way: one person installs it, nobody else can explain the webhook path, and six weeks later every feature fights the structure. Treat the kit like a dependency you own - with an owner, a review, and a changelog.
Assign ownership on purchase day
- One engineer owns auth and sessions.
- One engineer owns billing and entitlements (can be the same person on a two-person team - name it anyway).
- Someone owns env and deploy (often the founder).
Write the three names in the README. Ownership theater beats tribal knowledge.
First-week team ritual
- Pair on the clean-machine install once.
- Walk the payment path on a call with screen share.
- List “kit code” versus “our code” folders you agree not to tangle.
- Create a #kit-notes channel or doc for surprises.
Review standards
- PRs that touch webhooks require the billing owner.
- PRs that touch sessions require the auth owner.
- No drive-by renames of kit modules without a migration note.
Upgrades and freezes
Decide whether you track upstream kit updates or freeze at a purchased version. Both are valid. Wavering is how you get half-upgraded dependency trees. Record the decision with a date.
Hiring and handoff
New hires should complete the setup guide without Slack help. If they cannot, your documentation debt is already taxing velocity. Fix the guide before adding another feature squad.
Pick a full boilerplate when the repo is new; enforce the selection checklist as a team gate, not a solo shopping spree.