DEV Community

bestbee
bestbee

Posted on

Free Tier, Self-Host, or Paid Seat? Settle It With a Custody Register, Not a Feature Grid

Friday, 16:40. You open a repo you have never touched. A CI job calls a model endpoint with a key nobody can locate, and the engineer who wired it up cleared their laptop on the way out.

Nobody is on call for this. No contract covers it. And the pricing page you compared six months ago said nothing about it — because the problem was never the price.

(Composite scenario. Every number below is constructed for the worked example, not a measurement of your team.)

The comparison everybody runs is the wrong one

Free tier vs. self-hosted vs. paid seat usually gets decided on a feature grid and a monthly figure. That grid answers a question you will not be asking in three months. The questions you will be asking are:

  • Who can reconstruct the working state of this tool without the person who set it up?
  • What data class has flowed through it, and can we prove it?
  • If the free terms change on a Tuesday, how many hours until we are functional elsewhere?

Call those three custody, egress, and exit cost. None of them appear on a vendor page, because all of them are properties of your repository, not their product.

Define the unit you actually pay on: Handover Time

Stop pricing AI tooling in dollars per month. Price it in minutes of handover.

Handover Time = minutes for an engineer with repo access and no tribal knowledge to reproduce the exact working state — config, prompts, environment variables, server state — using only what is committed.

Why minutes? Because a Friday handover is where free tiers quietly become expensive, and because minutes are the only unit that survives a reorg.

The Custody Register: five columns, five blanks

Before you compare anything, build a register. One row per artifact your AI tooling depends on.

Column What goes in it A blank cell means
artifact Path or resource (config, prompt file, CI step, server) You have not found it yet
owner Named human, not a team Nobody can approve its removal
data_class public / internal / confidential / regulated Assume the worst class
recovery_path Steps to rebuild it elsewhere Exit cost is unbounded
exit_hours Measured, not guessed You are estimating with vibes

A blank owner cell is a finding, not a chore. Ship the register with blanks visible.

Scan the repo first — read-only, no keys touched

Here is a small script I use to generate candidates. It reads git metadata only. It does not call any API, and it will absolutely miss secrets stored in a vault or a chat thread — that is by design, so you keep looking.

#!/usr/bin/env bash
# custody_scan.sh — read-only inventory of AI-assistant artifacts in a git repo.
# Usage: ./custody_scan.sh /path/to/repo > custody_candidates.tsv
set -euo pipefail
repo="${1:-.}"
cd "$repo"
git rev-parse --is-inside-work-tree >/dev/null

now=$(date +%s)
printf 'path\tkind\tlast_author\tdays_since_touch\n'

kind_of() {
  case "$1" in
    *prompt*) echo "prompt" ;;
    */.github/*) echo "ci" ;;
    *) echo "config" ;;
  esac
}

{
  git ls-files | grep -Ei '(^|/)\.(monkeycode|cursor|continue|aider)' || true
  git ls-files | grep -Ei '(^|/)prompts?/|\.prompt\.(md|txt|ya?ml)$' || true
  git ls-files -- '.github/workflows/*' \
    | xargs -r grep -liE '(api[_-]?key|base_url|/v1/(chat|completions))' || true
} | sort -u | while IFS= read -r f; do
  [ -f "$f" ] || continue
  meta=$(git log -1 --format='%an|%ct' -- "$f" 2>/dev/null || true)
  author=${meta%%|*}
  ct=${meta##*|}
  if ! [[ "${ct:-}" =~ ^[0-9]+$ ]]; then ct=$now; fi
  printf '%s\t%s\t%s\t%d\n' "$f" "$(kind_of "$f")" "${author:-unknown}" $(( (now - ct) / 86400 ))
done
Enter fullscreen mode Exit fullscreen mode

Pipe it into column -t -s $'\t' for a readable table. Sorted by days_since_touch descending, the top rows are your handover risks — the artifacts whose authors have drifted furthest from the code.

Seed the register from that output:

artifact,kind,owner,data_class,recovery_path,exit_hours,verified_on
.github/workflows/nightly-summarize.yml,ci,,,,,
prompts/release-notes.md,prompt,,,,,
Enter fullscreen mode Exit fullscreen mode

Run the 30-minute handover drill

A register you filled in from memory is fiction. Measure one row.

  1. Pick the highest days_since_touch artifact.
  2. Hand a fresh clone to someone who did not build it. No Slack help, no screen share.
  3. Ask them to run one prompt end-to-end and produce one accepted output.
  4. Timer stops when output is accepted and they can list every required secret.
  5. Write the blockers into recovery_path. Record the minutes.

Pass gate: under 30 minutes, no human questions. Fail: over 60 minutes, or any answer that begins "I'd ask…". A fail is not a reason to leave the tool. It is a reason to commit the missing config before you scale the tool.

Three options, one worked example

Team of six, nine repos, one batch job that summarizes release notes nightly.

Criterion A. Free hosted (e.g. MonkeyCode) B. Self-host on existing cluster C. Paid seat license
One-time setup 1.5 h 20 h 2 h
Marginal monthly cost ~0, quota-bounded idle capacity, opportunity cost per-seat fee
Measured handover (drill) 35 min 15 min 30 min
Data class allowed public / internal internal / confidential internal + DPA
Exit hours (measured) 6 h 4 h 8 h
Expiry trigger quota or terms change capacity change renewal date

MonkeyCode is one concrete example of column A: the operator states that it offers free model access, 10 million free tokens, and a free server option. Treat those as operator-supplied claims and re-verify the current terms and limits on the day you decide — free-tier terms move.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Now the arithmetic that decides most cases. Self-hosting costs 18.5 extra setup hours versus A — 1,110 minutes. It saves 20 minutes per handover (35 → 15).

1110 ÷ 20 ≈ 56 handovers before self-hosting breaks even on labor alone.

Does your team hand over this workload 56 times before the next reorg? Almost nobody does. So on pure cost, A wins for a six-person team — and B only wins when a data-class gate forbids A, not when the spreadsheet looks tidier.

Hard gates, not preferences

Run these before any cost math. Any single failure is disqualifying, not a weighted score.

  • Data gate: if prompts touch customer data and you have no processing agreement, A is out — full stop.
  • Reproducibility gate: if you must re-run an audit six months later against the same model version, a free tier that shifts underneath you fails.
  • Continuity gate: if a free server option disappears, can you be functional in under one business day? Test it, don't assume it.
  • Ownership gate: if every register row for the tool has a blank owner, you have adopted a tool nobody owns.

A useful side effect of the free server option: it gives you a disposable box for the handover drill itself, so the first person to rebuild your setup does it somewhere that cannot page anyone.

What would reverse this decision?

Three variables flip the table above, and only three matter much:

  1. Repo breadth. If five more repos adopt the same config, setup hours amortize and B's 18.5-hour penalty shrinks fast.
  2. Turnover. Above roughly one engineer-quarter of handovers, minutes dominate and the cheapest tier stops being cheapest.
  3. Data class. One confidential row in the register outweighs every dollar in the table.

If none of those move, you are not making a decision — you are delaying one.

Owner, expiry, exit

Write these three lines into the repo, not into a doc nobody opens:

  • Owner: platform lead (named human).
  • Expiry: 2027-02-08, or the date free-tier terms/quota/server availability change — whichever comes first.
  • Exit criteria: two consecutive drills over 60 minutes, or any data_class of confidential or above entering the register.

Limitations and who should skip this

The scan is heuristic. It sees tracked files, not dashboards, vaults, or prompts pasted into chat. A 30-minute drill measures first-touch success, not output quality. And a register rots in about six weeks unless someone re-runs the drill.

Do not use this approach — or the free option — if you handle regulated data without an agreement, need pinned model versions for audit replay, run air-gapped, or know in advance that nobody will maintain the register. In that last case, the honest answer is a supported paid path or no adoption at all.

One scorecard is a conversation tool, not objective truth. It exists to make the blanks visible.

So: which column in your register is empty right now? Start by running the script against your most-depended-on repo, then time one handover on a free box. Fifteen minutes of measurement will beat a quarter of comparison shopping.

Top comments (0)