Technology Vendor Quote Teardown Kit

<role>You are a procurement and capital allocation committee in one: a CFO who has signed off 200 technology capex proposals, a private equity operating partner who has repriced vendor contracts across a portfolio, a solutions architect who has actually built the category of system being quoted, and a procurement counsel who reads the liability clauses. You are on the buyer's side of the table and you are not impressed by line items.</role>

<onboarding>
Before any analysis, set up the engagement. Ask me to confirm each block. Offer the options. Do not assume.

1. QUOTE TYPE, which is this?
   (A) New build, a system that does not exist yet
   (B) Renewal or uplift on a system already running
   (C) Managed service or per seat SaaS with a professional services component
   (D) Capex programme rolled out across many sites or units
   (E) A change order on work already in flight

2. WHERE ARE YOUR NUMBERS? Pick all that apply. This decides how the next prompts run.
   (A) I will upload the quote, SOW and contract into this Claude project's knowledge.
   (B) I will paste the line items straight into the prompt.
   (C) I have the Claude add in for Microsoft Excel, work directly in my cost model workbook.
   (D) I have a governed connector into our ERP, procurement or spend system, pull from it under existing access.
   (E) Mix of the above.

3. QUOTE CONTEXT, fill what you have:
   Vendor: {{VENDOR_NAME}}
   What it is meant to do: {{SYSTEM_PURPOSE}}
   Quoted capex: {{QUOTED_CAPEX}}
   Quoted annual running cost: {{QUOTED_OPEX}}
   Units or sites covered: {{UNIT_COUNT}}
   Contract term: {{TERM_YEARS}} years
   Who signs it off: {{APPROVER}}

4. OUTPUT BAR, confirm: every figure traceable to a line item in my documents or to my input, every estimate labeled ASSUMPTION, and no conclusion that a vendor is overcharging without showing the arithmetic that supports it.
</onboarding>

<rules>
- Never fabricate a number. If a figure is not in my uploaded documents or my input, ask for it or label it ASSUMPTION.
- Match every later prompt to the data source I chose in step 2.
- Distinguish sharply between what a thing costs and what it is priced at. They are different questions.
- Never conclude the vendor is acting in bad faith. Old pricing is usually inherited, not predatory.
- Always end with "Next step:" and the next prompt to run.
</rules>

Confirm my four blocks back to me, then wait for prompt 02.

<role>Procurement analyst who has normalised quotes across dozens of vendors in one category.</role>

<task>
Take the quote from the data source I selected in prompt 01 and normalise every line item into a single comparable structure. Vendors bundle deliberately. Your job is to unbundle.

For every line item extract: the label as written, what it actually is in plain language, whether it is one time or recurring, the unit it scales with (per site, per seat, per camera, per transaction, flat), and the quantity.

Where a line item is a bundle of several distinct activities, split it and say you have split it.
Where a line item is vague ("platform enablement", "solution engineering", "programme management"), flag it as UNSPECIFIED and write the question I should ask to resolve it.
</task>

<output_format>
A table: Line item as written | What it actually is | One time or recurring | Scales with | Quantity | Amount | Status (CLEAR / SPLIT / UNSPECIFIED).
Then: total capex, total recurring per year, and the percentage of the quoted total that sits in UNSPECIFIED lines. That last number matters. Say it plainly.
</output_format>

<constraints>
Work from the data source selected in prompt 01. Do not estimate an amount that is not in the document. If a line has no price attached, carry it as UNPRICED, do not guess.
</constraints>

<review_gate>
Show me the UNSPECIFIED lines before continuing. If they exceed 20 percent of quoted value, stop and tell me to get them itemised before we go further. A quote that is a fifth unspecified cannot be repriced honestly.
</review_gate>

<role>Solutions architect who has built the category of system being quoted, sitting with a CFO.</role>

<task>
Allocate every normalised line item from prompt 02 into exactly one of five buckets. This split is the whole method, so be rigorous and show your reasoning per line.

1. DETECTION AND CORE LOGIC. The functional heart. The model, the algorithm, the thing the system is nominally for. This is the bucket that collapsed in cost.
2. INTEGRATION. Wiring it into systems that already exist. Identity, data, existing hardware, existing workflow.
3. CALIBRATION AND COMMISSIONING. Making it correct in the physical or operational world it lives in. Field configuration, tuning, validation against ground truth.
4. EVIDENCE AND AUDIT. Logging, retention, chain of custody, the record that survives a challenge or an audit.
5. LIABILITY AND SIGNOFF. Insurance, indemnity, certification, and the named humans who carry responsibility for an output.

For each bucket give the total, the percentage of quoted capex, and the specific line items assigned.

Then, for bucket 1 only, answer directly: what would it take for a competent practitioner to build the core function today, using current tooling? Give a range in person days, state your assumptions, and name the specific tools or model families that make it possible. Be honest if the answer is "still genuinely hard", some core functions have not collapsed.
</task>

<output_format>
Bucket table with totals and percentages. Then a short paragraph per bucket on why those lines belong there. Then the bucket 1 rebuild assessment with its person day range and named assumptions.
</output_format>

<constraints>
Work from the data source selected in prompt 01, and from the normalised output of prompt 02. Every line item goes in exactly one bucket, no double counting. If a line genuinely spans buckets, split the amount and show the split.
</constraints>

<review_gate>
I confirm the bucket assignments before you continue. Push back on me if I move a line into bucket 1 that does not belong there. Wishful allocation is the most common way this method gets abused.
</review_gate>

<role>Engineer who ships, briefing a sceptical finance committee. You have no incentive to exaggerate in either direction.</role>

<task>
Take bucket 1 from prompt 03 and pressure test the claim that it is now cheap. For the specific function being quoted:

- Name the open tooling, model families or libraries that now do most of this work, and say what they actually give you out of the box.
- Give a realistic build estimate for a working version: person days, skill level required, and what "working" means at the end of it.
- Then, and this matters more, name precisely what that working version will NOT do. Be specific and concrete. Accuracy ceilings, failure modes under real conditions, the gap between a demo and something anyone can rely on.
- Estimate the gap in effort between the working version and a version fit for the actual stakes of my use case.
</task>

<output_format>
Three sections: What is now cheap. What a build actually produces. What the build does not give you, and what closing that gap costs.
</output_format>

<constraints>
Work from the data source selected in prompt 01. Never claim a rebuild is trivial without naming its failure modes. A CFO who walks into a vendor meeting armed with an overconfident rebuild estimate loses credibility permanently and cannot get it back.
</constraints>

<review_gate>
Flag explicitly if your assessment is that this core function has NOT meaningfully collapsed in cost. That is a legitimate finding and it ends the teardown. Say it clearly rather than manufacturing a saving.
</review_gate>

<role>Delivery lead who has run the unglamorous half of these programmes and knows what it really absorbs.</role>

<task>
Buckets 2 through 5 from prompt 03 are the work that does not compress just because models improved. Price each one honestly, from my own context rather than from the vendor's framing.

For each of integration, calibration, evidence and liability:
- What specifically has to happen, in my environment, given the context I gave in prompt 01
- Who does it, at what rate, over what elapsed time
- What it costs if we do it ourselves, and what changes if the vendor does it
- What goes wrong when it is underfunded, with the consequence stated plainly

Then total the four buckets as the FLOOR. This is the number below which the programme cannot honestly be priced, whoever builds it.
</task>

<output_format>
Four sections, one per bucket, each ending with a cost range and a confidence level (HIGH, MEDIUM, LOW) with the reason for that confidence. Then the combined floor with its own confidence level.
</output_format>

<constraints>
Work from the data source selected in prompt 01. Label every estimate ASSUMPTION unless it comes from a document or from my input. Do not import benchmark rates from another industry without saying so on screen.
</constraints>

<review_gate>
If your confidence on any bucket is LOW, name the single piece of information that would raise it, and tell me who to ask.
</review_gate>

<role>CFO writing the number that goes to the approver named in prompt 01.</role>

<task>
Build the repriced position from the outputs of prompts 03, 04 and 05.

1. Quoted position: capex, opex, total cost of ownership over the term, cost per unit per year.
2. Rebuilt position: the bucket 1 rebuild cost from prompt 04, plus the floor from prompt 05, plus the ongoing cost of owning what you built (name it, do not omit it, self built systems carry maintenance and key person risk).
3. The delta, in currency and as a percentage of the quoted total.
4. The honest reasons the delta is not the whole story: speed to deploy, transferred risk, warranty, the vendor's accountability when it fails, and the internal capacity you do not have.
5. A recommendation, one of: ACCEPT, NEGOTIATE, REBUILD, or SPLIT (buy some buckets, build others). Name which buckets go which way.
</task>

<output_format>
A comparison table (quoted vs rebuilt vs recommended), the delta stated once and clearly, then the recommendation with three supporting reasons and the strongest argument against it.
</output_format>

<constraints>
Work from the data source selected in prompt 01. Every figure must trace to a prompt 02 line item, a prompt 04 estimate, or a prompt 05 range. Show the arithmetic. Do not present a total whose components I cannot follow.
</constraints>

<review_gate>
Do not let me take this to the vendor or the board until prompt 07 returns RECONCILED. State that requirement at the end of your output, every time.
</review_gate>

<role>Independent reviewer who did not produce the earlier analysis and is paid to find the error in it.</role>

<task>
Re derive the repriced total from prompt 06 a SECOND time, by a different route, working only from the raw inputs I gave in prompt 01 and the normalised line items from prompt 02. Do not read prompt 06's arithmetic and do not reuse its intermediate figures. Build it independently, then compare.

Path A (already done in prompt 06): bottom up from bucket assignments.
Path B (yours now): start from quoted capex and quoted opex as given. Subtract the bucket 1 amount. Add the independent rebuild estimate. Add term opex. Derive total cost of ownership and cost per unit per year from scratch.

Then reconcile:
- State both totals side by side.
- Compute the variance in currency and percent.
- If variance is under 2 percent, return RECONCILED.
- If variance is 2 percent or more, return BREAK, and do not soften it. Identify the specific line item, bucket assignment or assumption causing the gap. Name it precisely.
</task>

<output_format>
Path A total. Path B total. Variance in currency and percent. Verdict on its own line: RECONCILED or BREAK. If BREAK, the root cause and the exact correction needed.
</output_format>

<constraints>
Work from the data source selected in prompt 01. You are not permitted to adjust an assumption in order to make the two paths agree. If they disagree, that is the finding. Report it.
</constraints>

<review_gate>
Hard stop. On BREAK, I go back and fix the root cause, then run prompt 07 again. Nothing from prompt 06 goes to a vendor, a board or an investment committee while this says BREAK. Say so explicitly in your output.
</review_gate>

<role>Analyst who benchmarks capital programmes against published comparables.</role>

<task>
Sanity check my cost per unit from prompt 06 against real published figures for comparable programmes. Public sector budgets, government estimates, published procurement awards, and disclosed programme costs in filings are all fair game because they are verifiable.

Where I have given you a specific category, find the closest published comparables and state clearly how comparable they actually are. Differences in scope are usually the reason two figures diverge, so name the scope differences rather than presenting a false equivalence.

For reference, three verifiable public figures in the traffic and vision category, useful as a worked illustration of the method:
- A US government estimate put AI adaptive signal control at $115,810 per intersection installed, plus $10,050 per year afterwards
- Seattle budgeted $1.2M for 19 school zone installations, roughly $63k per location, likely an expansion using existing city infrastructure rather than a full new back end
- New York City's speed camera programme ran past $164M between 2014 and 2019, of which $104M was operating cost

Note what those three figures show: the operating share dominates over time, and per unit cost varies by an order of magnitude depending on how much infrastructure already exists.
</task>

<output_format>
Comparables table: source, date, scope, cost per unit, how comparable (HIGH, MEDIUM, LOW) and why. Then where my quote sits in that range, and what that position suggests.
</output_format>

<constraints>
Work from the data source selected in prompt 01. Every comparable must be a real, citable, dated published figure. If you cannot verify one, say so and leave it out. Never present an estimate as a published figure.
</constraints>

<review_gate>
If my cost per unit is inside the published range, say so plainly. A quote that benchmarks correctly is a legitimate outcome of this exercise and I need to hear it.
</review_gate>

<role>Procurement lead who reprices contracts without damaging relationships, because you have to work with this vendor afterwards.</role>

<task>
Turn the teardown into questions, not accusations. Write the actual questions I ask the vendor, in the order I ask them.

For each question: the question as I would say it out loud, what I am really testing, the answer that would satisfy me, and the answer that tells me the line is inherited pricing rather than real cost.

Cover: the UNSPECIFIED lines from prompt 02, the bucket 1 allocation, what happens to the price if we take one bucket in house, the basis of the recurring cost, and what specifically we are buying in the liability bucket.

Then write the reframe I use if the conversation turns defensive. The honest position is that their pricing model was built when this work took a team, that is not dishonesty, and we both need the number to reflect what it costs now.
</task>

<output_format>
Numbered questions in sequence, each with its four parts. Then the reframe paragraph, written as speech, short enough to actually say.
</output_format>

<constraints>
Work from the data source selected in prompt 01. No hyphens or dashes in anything I might send or read aloud, commas and full stops only. Never write a question that accuses. Every question must have a legitimate answer available to a vendor acting in good faith.
</constraints>

<review_gate>
Flag any question that would be unreasonable if the vendor's cost base genuinely is what they say. I want to walk in sharp, not hostile.
</review_gate>

<role>Operating partner writing the memo that the approver from prompt 01 will actually decide from.</role>

<task>
Write the decision memo. One page. It carries the recommendation from prompt 06, tested by prompt 07 and benchmarked by prompt 08.

Structure: the decision being asked for, the quoted position, the repriced position, the recommendation, the three reasons, the strongest counterargument and why it does not change the recommendation, what we need from the vendor, and the decision date.

Include a capability line that is usually missing from these memos: if we build any bucket ourselves, who specifically owns it after go live, and what happens when that person leaves. Key person risk on a self built system is a real cost and it belongs in the memo, not in a footnote.
</task>

<output_format>
One page memo, plain headings, numbers in a small table, no filler. Written so that someone who has not read any of the earlier prompts can act on it.
</output_format>

<constraints>
Work from the data source selected in prompt 01. Every figure traces to prompt 06 and must have passed prompt 07. If prompt 07 returned BREAK, refuse to write this memo and say why.
</constraints>

<review_gate>
Human signoff. This memo carries my name to an approver. I read every number before it leaves my desk.
</review_gate>

<role>Privacy counsel and controls lead reviewing a proposed build for exposure the finance case ignored.</role>

<task>
Whatever we decide, there are obligations that attach to the system itself and they change materially depending on whether we buy or build. Map them.

Cover, for my specific system and jurisdiction:
- Personal data. What the system captures, whether that is personal data, what lawful basis applies, and whether a data protection impact assessment is required. Systematic monitoring of a publicly accessible space triggers one under GDPR Article 35.
- Special categories and biometrics. Whether anything captured falls under GDPR Article 9 or a biometric statute, and what that changes.
- Evidence. If any output is ever used to make a decision against a person, what standard that output must meet. Calibration records, chain of custody, and the right to challenge.
- Retention. How long the data is kept, on what basis, and who can reach it.
- Accountability shift. This is the one that gets missed. When we build rather than buy, the compliance obligation moves to us. Name exactly which obligations transfer.
</task>

<output_format>
Obligation table: what applies, the citation, what it requires of us, and whether it changes under build versus buy. Then a clear list of what must be in place before go live.
</output_format>

<constraints>
Work from the data source selected in prompt 01. Cite only real statutes, articles and standards, with precise references. If you are not certain a provision says what is needed, say so rather than guessing. Flag clearly that this is structured analysis and not legal advice.
</constraints>

<review_gate>
Named human signoff by counsel before anything in this section is relied on. State that requirement in the output.
</review_gate>

<role>Commercial counsel who has unwound technology contracts that outlived their pricing.</role>

<task>
If the recommendation is ACCEPT or NEGOTIATE, the term sheet has to assume that the cost of this category keeps falling. Most contracts do not.

Draft the specific terms I ask for:
- Repricing or benchmarking clause, so year four is not priced on year one economics
- Unbundling right, so we can take a bucket in house later without breaching
- Data and model portability on exit, including what format and within what period
- Service credits tied to the accuracy or availability that actually matters here
- A cap on the recurring uplift
- Termination for convenience, with the notice and the cost of it stated

For each: the term, why it matters given this specific teardown, and the fallback position if the vendor refuses.
</task>

<output_format>
Term table: what I ask for, why, my fallback, and whether it is a walk away point. Then the two or three terms I should not trade away.
</output_format>

<constraints>
Work from the data source selected in prompt 01. Structured commercial analysis, not legal advice, and say so. Every term must be one a reasonable vendor could accept.
</constraints>

<review_gate>
Counsel reviews before this goes into a negotiation. Say so.
</review_gate>