mindit-cost

name

mindit-cost

description

Analyze the build cost, support burden, maintenance cost, and technical debt of a design. Use this whenever the user asks "is this worth building," "how much will this cost," "is this maintainable," "what's the support burden," or wants a complexity review. Also trigger when comparing two design options and asking which is cheaper to ship, or when the user is reviewing a design that introduces a new component, library, or pattern. Produces a structured decision artifact with score, criteria, and anti-pattern matches.

mindit-cost

The sixth of the eight forces. Run this when the question is "what does this actually cost."

The force

Designs have a sticker price (the engineering hours to build them) and a lifetime price (the support, maintenance, and debt they leave behind). The sticker price is almost always lower than the lifetime price. A custom one-off component is cheap to design and expensive to maintain for the next five years.

Cost asks: of the price this design will charge over its lifetime, how much has the team actually budgeted for?

A high cost is not automatically a bad thing. Some designs are worth it. Cost surfaces the bill so the team can decide whether it is.

When to run this

• The user is choosing between two designs and asks which is "cheaper" or "more practical."
• The user introduces a new component, third-party library, or custom pattern and wants a review.
• The user uses words like "complexity," "maintenance," "debt," "support burden," "is this worth it."
• The user is in a constrained team (small eng team, late-cycle, low budget) and wants to know what to cut.

How to analyze

1. Inventory what is new. What components, dependencies, integrations, animations, or interactions does this design introduce that did not exist before?

2. Estimate the four costs. For each criterion below, ask both the sticker cost and the lifetime cost. Sticker is "what does it cost to ship this once." Lifetime is "what does it cost to keep this working for two years."

3. Surface the support burden. Walk through the flows the design adds, and ask: where will a confused user end up? In a docs page that does not exist yet? In an inbox? On a Slack channel? The support cost is paid in tickets per week.

4. Surface the maintenance burden. Ask: who maintains this in a year? Is it a third-party dependency that needs version bumps? Is it a custom component nobody on the current team built?

5. Check anti-patterns.yaml.

6. Write the artifact.

Rubric

Criterion	Weight	What you are scoring
Build complexity	0.25	Hours of engineering work to ship the design once. New components, custom interactions, animations, integrations.
Support burden	0.20	Estimated tickets per week the design will generate. Confusing flows, unintuitive states, manual fallbacks.
Maintenance burden	0.20	Ongoing work to keep the design functional: dependency updates, content updates, browser regressions, design-system drift.
Technical debt	0.15	Shortcuts taken or assumptions baked in that will cost more to remove later than to do correctly now.
Marketing & training cost	0.10	Does this design require explanation, onboarding, sales enablement, documentation, or training to land?
Total cost of ownership signal	0.10	Has the team explicitly reasoned about TCO, or is the design priced by sticker alone?

Anti-patterns

See anti-patterns.yaml. Brief list: snowflake-feature, unverified-third-party, explain-it-twice, silent-maintenance, copy-paste-component, no-debt-budget, novel-interaction-tax.

Output format

Two files in .mindit/decisions/. Filename: cost-<yyyymmdd>-<slug>.{md,json}.

JSON conforms to schemas/decision.schema.json with skill: "mindit-cost" and force: "cost".

Example

Input: "Review the new onboarding flow. It introduces an in-product video player, a six-step tour, and a custom progress widget."

Inventory of new work:

• In-product video player (custom or library)
• Six-step tour engine
• Progress widget (custom component)
• Six pieces of video content

Sample findings:

• Build complexity: video player + tour engine + custom widget = three new components, plus content production. High sticker cost. Severity high.
• Support burden: tours that misalign with the actual product after a release become a support headache. Severity medium.
• Maintenance: video content drifts as the product changes. Either someone owns refresh quarterly or the videos rot. Match: silent-maintenance. Severity high.
• Technical debt: the tour engine, if custom, locks the team into supporting it forever. Match: snowflake-feature. Severity medium.
• Marketing cost: the team will need to explain "the new onboarding tour" externally. Severity low.
• TCO: no one has costed the maintenance of the video content. Match: no-debt-budget. Severity high.

Sample weighted score: 41.

What this skill does NOT do

• Does not give precise hour estimates. Costs are relative, not absolute. Engineers estimate hours.
• Does not block expensive designs. Some are worth it. The skill surfaces the bill.
• Does not score against features that have not been described. If the user has only shown a screen, score that screen, not an imagined system.