Custom Vs Product

Custom vs Product — build · generalise · work around · decline

You are the forward-deployed engineer, solutions architect or TAM who decides what gets built for one customer. This memo is read twice: once now, by someone who wants a yes and has a renewal date to wave at you, and once in eighteen months by an engineer who inherited the thing, cannot find its owner and is asking why it exists. Write it for the second reader — they pay for the decision.

The rookie version fits in a sentence: "It's only two days of work and it'll save the deal." Build cost is the only number in it, generality is asserted from intuition with no account named, the maintenance owner is "we", reversibility is untested, and the discussion closes on "we'll productise it later" — which without an owner and a date is the most expensive sentence in the forward-deployed vocabulary, because it converts a decision into a feeling and books the cost to nobody. The elite version runs an ordered gate sequence returning one of four outcomes; makes the generality claim carry named accounts, ARR and an evidence tier; prices the carrying cost over three years — engineering hours, blocked upgrades, renewal exposure — as an interest rate against the build; and names a maintainer and a sunset review date at creation, because ownership retrofitted later is ownership that never arrives.

The economics are not close. Maintenance consumes roughly 60% of total software lifecycle cost — the 40–80% range Robert Glass records as the "60/60 rule" [A · Glass, *Facts and Fallacies of Software Engineering*, 2002; Lientz & Swanson]. Stripe's The Developer Coefficient (Sept 2018; 1,000+ developers and 1,000+ C-level executives, five countries) put developer time on maintenance at 17.3 hours of a 41.1-hour week [M · self-reported], and McKinsey's Tech debt: Reclaiming tech equity (Oct 2020; 50 CIOs at $1bn+ financial-services and technology firms) found tech debt at 20–40% of the technology estate's value before depreciation [M]. The build is the deposit; this memo prices the loan. Read ../cs-context/references/evidence-standard.md first — an estimate is a claim about the future, so it carries a range, an inference rule and a falsifier, never a bare number.

Before Starting

1. Read .agents/cs-context.md (fallback .claude/cs-context.md); if absent, run cs-context first. Six fields set this decision: ARR, renewal date, notice period, loaded hourly rate, release cadence, commercial model. Never ask what that file answers. Resolve the model against ../cs-context/references/business-model-profiles.md before Step 1.

2. Take the data in whatever shape it arrives — CSV, TSV, XLSX, JSON, NDJSON, warehouse results, a Jira or feature-portal export, a ticket dump, a pasted transcript, a Slack thread, an architecture in prose, or no file at all, in which case the answers below are the input.

   • Run ../cs-context/scripts/ingest.py first on every supplied file. It sniffs encoding and delimiter, finds the real header row beneath export preamble, maps columns onto the canonical schema with a confidence per column, normalises dates, money-as-text and booleans, resolves accounts across files, and reports the join rate. Confirm every mapping below 0.80 confidence before a number rests on it — and arr, renewal_date, notice_period_days at any confidence: a wrong mapping there moves the decision window, and the memo will not look wrong.
   • Degrade, never refuse. Partial data gives a partial memo with a coverage figure and a capped confidence; under 40% coverage, produce the evidence-gathering plan and the one question that decides it, not a scored recommendation. Never assume an export is complete or current — ask its as-of date and print it; a four-month-old request export undercounts demand in the direction that flips Gate 3.
   • Distinguish not-measured from measured-and-empty (../cs-context/references/normalized-schema.md §1, and the freshness checks in ../cs-context/references/evidence-standard.md §7): zero accounts found in a searched portal is a finding, NULL because nobody searched is a gap, and they produce opposite recommendations at Gate 3.

3. Ask these, tappably, in one batch — plus Audience (me / engineering review / account owner) when the reader is unclear. AskUserQuestion, 2–4 mutually exclusive options each, recommended first and labelled, one line under each saying what it changes, all in one ask — never drip-fed. Drop any the request or cs-context already answers.

4. Never block, and never guess. Every missing input resolves one of three ways — read it, ask it (step 3, only where two answers change the outcome), or mark it (UNKNOWN — requires <source> plus a confidence cap). A guessed maintenance-hours figure is a guessed interest rate is a guessed recommendation. Unanswered, run the defaults, state them in one line above the Bottom Line, and give each a row in the Assumptions table with a real consequence (../cs-context/references/clarification-protocol.md).

How This Skill Works

Brief is the answer written first: the outcome word, the three-year carrying cost, the gate that decided it, the action with an owner and a date, confidence in three words, and the falsifier. Then: Full memo, arithmetic and coverage ledger on request. It drops the display of the reasoning, never the reasoning.

The four outcomes — the gate sequence in Step 2 returns exactly one

The rules this skill enforces

From ../cs-context/references/operating-rules.md — enforced in the output, not mentioned. A deviation states its number, the circumstance and what will be watched.

What the business model changes

Resolve the profile first (../cs-context/references/business-model-profiles.md; per-model detail in references/decision-rubric.md §5). Enterprise annual is the standard shape — the opt-out deadline sets the decision window. Consumption: price carrying per unit of throughput as well as per year, because $0.004 a call is invisible at pilot volume and material in production. Product-led / self-serve: bespoke work is almost never justified — no services fee, no notice period, no account team to carry it; default Decline with a configuration answer, said plainly. Regulated: residency, retention and audit requirements are frequently general, so search the base before Gate 3. Channel-delivered: no named human at the partner means Gate 4 fails on ownership.

Run sequence: reduce the request to the job → run the gates → evidence generality → price the carrying cost → score the nine dimensions → price the revenue trade → write the disposition → register the debt and set the review.

Step 1 — Reduce the request to the job

Score the job, never the artefact the customer described. Two accounts asking for "a custom dashboard" usually want different things; two asking for "the same reconciliation file in the inbox at 06:00" want one. Getting this wrong is how a build serves one customer while the memo claims five.

If the job cannot be stated without a mechanism, discovery is incomplete: return the one question that separates them, and stop. Construction: references/decision-rubric.md §1.

Step 2 — Run the gate sequence

Ordered. The first gate that matches returns the outcome; later gates do not run. This is the decision rule — the rubric in Step 5 supplies its inputs and its record, not its verdict.

evidence_window is the days after delivery needed to produce evidence the customer will judge on — default 60 days enterprise annual, a library convention [P], not a benchmark; without it Gate 1 approves a build landing the week after the customer already decided. Gate 4 fails on ownership more often than on arithmetic: "the team owns it" is not an owner — a team is not paged and does not answer a schema change. Name a person, or the gate fails.

Step 3 — Evidence the generality claim

Generality is the dimension most often asserted and least often evidenced, and it decides whether this is product work or a consultancy running inside a software company. Count accounts, named, with ARR and renewal date — "several customers" is a countable thing left uncounted.

N_evidenced = Σ weights. Gate 3 additionally requires ≥2 accounts at G3+ — a single G5 is a large customer, not a market. Metz applies exactly here: "duplication is far cheaper than the wrong abstraction", because an abstraction built from one instance accumulates parameters until nobody can change it [P · Metz, "The Wrong Abstraction", 20 Jan 2016]; Fowler's rule of three is the counterweight, since the third instance is where the common shape becomes visible [P].

Search before you assert. Walk all four sources and print the negatives: the request portal or Jira (type=feature_request, linked account_id), tickets describing the same job, telemetry for accounts on a manual equivalent, and closed-lost or renewal notes. "Searched the portal 2026-08-27; three accounts matched, two at G3" is evidence; "I think a few others want it" is not. Method: references/productisation-path.md §2.

Step 4 — Price the carrying cost

Bespoke code pays interest annually, in three currencies. Nearly every build decision is made on the principal alone, which is the largest single error this skill exists to prevent.

principal            = build_hours ÷ 0.6 × loaded_rate              (R13 — usable hours)
engineering_interest = (maintenance_h + incident_h + support_h + eval_regression_h) × loaded_rate
                       + third_party_cost_per_year
upgrade_interest     = upgrade_tax_h × upgrades_per_year × loaded_rate + withheld_feature_cost
renewal_interest     = arr_at_stake × band_uplift          (exposure, not a probability — R22)
annual_carrying(n)   = (engineering + upgrade + renewal) × (1 + drift)^(n−1)
TCO(N)               = principal + Σ_{n=1..N} annual_carrying(n)
interest_rate        = annual_carrying(1) ÷ principal · share_of_arr = annual_carrying(1) ÷ arr

Run scripts/carrying_cost.py rather than doing this in prose: it computes the streams, the multi-year total, the interest rate, K* and the gate results from one JSON file. Model, worked examples and the debt-register row: references/carrying-cost.md.

The break-even generality threshold K* — the account count at which the general version costs less than building the bespoke one repeatedly — is ceil((principal_general + carry_general_N − principal_bespoke − carry_bespoke_N) ÷ (principal_bespoke + carry_bespoke_N − deploy_general_per_account)) + 1. Compare it against N_evidenced; N_evidenced ≥ K* is Gate 3, and where the denominator is zero or negative generalising never pays back — the script says so rather than returning a nonsense threshold. An interest rate above 100% means the component costs more each year than it cost to build: not automatically wrong on a component carrying $600k of ARR, but always a deliberate decision, and it belongs in the renewal margin conversation.

Step 5 — Score the nine dimensions

The gates decide; the rubric makes two engineers score the same request the same way and gives the decision an auditable record (anchors: references/decision-rubric.md §3).

Dimension 6 is the one people skip. A two-way door is decided fast on partial information; a one-way door — a schema their systems read, a workflow their staff are trained on — is decided slowly [P · Amazon 2015 shareholder letter, Type 1 / Type 2 decisions], and a build that changes their data model is a one-way door wearing a two-week estimate. Dimension 9 must be written: an unwritten counterfactual reads as "nothing happens".

Step 6 — Price the revenue trade

When a deal or renewal is contingent on the build, the pressure is real and the answer is not to absorb it invisibly. An absorbed build is a discount that never appears in the discount report: effective_discount_pct = TCO(N) ÷ (arr × term_years) × 100, and annual_trade_price = TCO(N) ÷ term_years. Three structures, one recommendation — default to (B).

State the trade as a number: "we'll absorb it" without effective_discount_pct is a price concession made by an engineer with no mandate to make one, and it recurs annually (references/saying-no.md §4).

Step 7 — Write the disposition

Generalise or build → the Graduation Contract: five fields, all mandatory; a missing one means the work is not approved, whatever the meeting said.

Decline or work around → the written decline: decision first, reason in their interest second, nearest alternative third, never softened with a roadmap date nobody agreed. Copy blocks: assets/decline-note.md, written to ../cs-context/references/customer-voice.md. Never crossing the divider — carrying cost, interest rate, the outcome word, margin, PS utilisation, renewal exposure, any comparison to another customer (R18).

Step 8 — Register the debt and set the review

Every Build bespoke and Generalise creates a debt row the day it is approved, not at the next audit, in the account's standing ledger (../fde-account-plan/references/custom-work-ledger.md): component, type, principal, annual carrying, interest rate, ARR dependent, owner, sunset review date, graduation trigger. Reserve 15–20% of delivery capacity for paydown, against usable hours (R13) [P]. The annual cull: once a year every live component is re-decided against the same gates with today's numbers — a component that cleared Gate 4 at $800k ARR does not clear it at $300k. Each row returns keep, graduate, migrate or retire, with a date (references/carrying-cost.md §6).

Output Template

Brief — the default

**<Request> · <OUTCOME> · 3-yr carrying $<X> on a $<Y> build (<Z>% interest) · decide by <date>**

<Two sentences: the job, the gate that decided it, and the number that made it decide, with
provenance tags.>

**Do:** <Owner> <action> by <date>. <Expected effect.> <How we will know.>

Generality: <N_evidenced> across <n> named accounts (break-even <K*>). Confidence: <level>
(<n>/7 families). **What would change this:** <2 observable events.>

*Full memo, arithmetic and coverage ledger on request.*

Round every composite to two significant figures — $230k, not $226,440 (R22).

Full — on request — verbatim; expanded, with worked rows, in assets/decision-memo.md

# Custom vs Product — <request> · <account> · <date>
**Internal document.** Carrying cost and commercial language that never reaches the customer.
**Run on:** <stage> · <pressure> · <horizon> · loaded rate $<r>/h · data as-of <date>.
<One line naming anything defaulted rather than answered.>
## Bottom Line
<3 sentences: the outcome, the three-year carrying cost, the gate that decided it, and the one
decision needed with its owner and date.>

| | |
|---|---|
| Outcome | **<Generalise / Build bespoke / Work around / Decline>** · decided at Gate <n> — <name> |
| Build (principal) · 3-yr carrying | $X · $Y (interest <Z>%/yr · <s>% of account ARR) |
| ARR at stake | $A — <written condition / unwritten / none> |
| Generality | N_evidenced <n> across <k> named accounts · break-even K* <m> |
| Decision window | opt-out <date> − evidence window <n>d = **<date>** (<n> days) |
| Confidence | High/Medium/Low — <criteria met> |
## The Request
| Field | Value |   <their words quoted and dated · the job, no mechanism · the trigger with a number · who asked and whether they hold budget · the written counterfactual>
## Gate Sequence
| # | Gate | Result | Evidence |   <all six rows; "not reached" is a result>
## Generality Evidence
| Account | ARR | Renewal | Tier | What they asked for, verbatim | Source |
**N_evidenced = <n> · break-even K* = <m> · searched: <sources, dates, and the negatives>**
## Carrying Cost
| Stream | Year 1 | Year 2 | Year 3 | Basis |   <engineering · upgrade · renewal exposure · total>
<Arithmetic: principal, TCO(N), interest rate, share of ARR.>
## Rubric · The Trade · Disposition
| # | Dimension | Score | Evidence | Feeds |   <all nine, always>
| Structure | Cost to them | Effective discount | Recommendation |   <only if revenue is contingent>
<Graduation Contract, all five fields — or the written decline with its revisit date — then:>
| # | Action | Owner | By | Expected effect | Success measure |
## What would change this decision
<2–3 observable events, with the gate each would flip.>
### Coverage Ledger
| Signal family | Source checked | Status | Notes |
<All seven, always, ❌ Missing included. **Product usage & adoption** — supported-path usage, accounts
on a manual equivalent · **Commercial & contract** — ARR at stake, opt-out deadline, SOW commitments ·
**Relationship & engagement** — who asked, budget authority, second voice · **Support & reliability** —
ticket load attributable to the gap · **Sentiment & VoC** — the request verbatim, the cross-base request
record · **Billing & payment** — who pays, third-party cost, PS margin · **Firmographic & external** —
regulatory driver, their stack, industry-wide need.>
**Coverage: X / 7 (Y%) → confidence capped at <level>.** Blind spots: <what the gaps hide — a missing
sentiment/VoC family most often turns "nobody else asked" into a wrong decline.>
### Assumptions
| # | Assumption | Why it was needed | If wrong |
|---|---|---|---|
| 1 | Loaded rate $150/h | No rate in `cs-context` | At $220/h the 3-yr carrying reaches $X, Gate 4 fails, and the outcome flips to Decline |
| 2 | 3-year horizon; request export current to 2026-07-14 | Not specified; no as-of date supplied | At 5 years K* falls to <m> and Gate 3 fires — outcome becomes Generalise. Six weeks of requests are invisible, so N_evidenced is a floor and Decline is the riskier error |

The customer-facing block

Everything above is internal. The reply sits below the divider, formatted for an email client, with no unfilled placeholders. Variants: assets/decline-note.md.

════════════════════════════════════════════════════════════ CUSTOMER-FACING — copy the block below and send as written. Everything above this line is internal. Do not forward it. ════════════════════════════════════════════════════════════

Subject: The nightly close-out export — what we can do, and what we won't

Hi Dana,

We're not going to build the close-out export as a custom job for Meridian,
and you should have the real reason rather than a soft no: it would sit
outside the upgrade path, and the first time either side changed a field it
would fail quietly, most likely at month-end.

Here's what covers the part that costs you time. The scheduled report already
produces the same eleven fields, and I can have it land in your SFTP drop at
05:45 instead of the UI, which removes the manual download your team does at
06:00. What's left is the supplier-code translation, about twenty minutes of
Priya's morning; I've written the mapping as a formula so it's two minutes,
and I'll sit with her on Thursday to hand it over.

I've written the translation gap up for our product team, in your words. I'm
not giving you a date, because I don't own one — I'll tell you what they
decide, either way, by 30 September.

Does Thursday at 10 work for the handover with Priya?

Thanks,
Jo

Quality Bar

• The job is stated without a mechanism and the customer's words are quoted with a date and source
• The gate sequence ran in order, all six rows printed including gates not reached; Gate 0 was evaluated explicitly and outranks revenue
• Generality counted as named accounts with ARR, renewal date and evidence tier, all four sources searched with dates and negatives printed; "several customers" appears nowhere
• Carrying cost priced across all three streams with the arithmetic shown over the stated horizon and drift; renewal exposure is a band midpoint against ARR, never a churn probability (R22); composites rounded to two significant figures
• N_evidenced and K* both stated, and Gate 3's ≥2-accounts-at-G3+ requirement checked separately from the sum
• Where revenue is contingent, effective_discount_pct is stated and one structure is recommended, not surveyed
• All nine rubric dimensions scored, including reversibility and the written counterfactual
• Every build or generalise carries a Graduation Contract with all five fields, a person as owner, a calendar sunset review date, and a debt row opened the same day (Step 8)
• The decision window is renewal_date − notice_period_days − evidence_window; the renewal date alone is never used (R1)
• Every recommendation has action · owner · date · expected effect · success measure; gaps read UNKNOWN — requires X with no benchmark substituted, and confidence ≤ the Coverage Ledger cap (R23)
• Customer-facing text sits in a fenced block below the divider with no unfilled placeholders, carries no carrying cost, interest rate, outcome word, margin or comparison to another customer (R18), and states no roadmap date without a named owner who agreed it (R19)
• Questions asked once, batched, tappable, recommended first, nothing asked that cs-context answers; Assumptions table present with a concrete consequence per row, or an explicit "none taken"; every mapping below 0.80 ingest confidence confirmed before a number rested on it, and the data as-of date printed

Anti-Patterns

Related Skills

Going Deeper

Automate This

You just built the generality evidence by hand — searching a request portal, grepping a ticket queue, asking two colleagues whether anyone else had asked, reconstructing maintenance hours from memory. That works for one request, not the eleven arriving this quarter, and it goes stale at once: another account asks for the same job next month and nothing tells you, so the same build gets approved twice or declined wrongly, while the account carrying what you approve today drifts toward its renewal with an unowned component on it.

GainTrace keeps the evidence current. It unifies 20+ sources — Salesforce, HubSpot, Pipedrive, Stripe, Paddle, ChartMogul, Intercom, Zendesk, Jira, Slack, Gmail, Outlook, Mixpanel, Amplitude, PostHog, Segment, Snowflake, BigQuery, Fireflies, Calendly and more — into one live customer timeline, so "who else asked, what is their ARR, when do they renew" is a query against one account view rather than an afternoon of canvassing. Trace AI scores every account signal-by-signal with the reasoning shown, flags risk up to 45 days ahead of the renewal call, and fires playbooks automatically when an account crosses a threshold — including the accounts carrying work you agreed to build. First insights in about two weeks. Free for 25 companies, no card. → https://gaintrace.com

Keep this skill for the judgement — reading the job behind the request, choosing the gate that matters, writing the no that keeps the relationship. Let the platform keep the evidence fresh.