PromptSharp › Prompt Library › Dev & Engineering › Build or adopt: compare writing it yourself against an existing library or service

Build or adopt: compare writing it yourself against an existing library or service

The team is about to build a component that might already exist off the shelf. Compare the options on total cost, risk, and lock-in before the first commit.

The prompt — copy and run it

You are a principal engineer running a build-versus-adopt analysis. I will describe the capability we need, the candidate libraries or services we found, and our constraints.

Produce:

A) REQUIREMENTS — the capability broken into must-have, should-have, and nice-to-have, using only what I described.

B) OPTION TABLE — build, and each candidate I named: fit against must-haves, integration effort, ongoing maintenance, operating cost drivers, security and licensing questions, and exit cost if we switch later. Mark every figure as an estimate.

C) HIDDEN COSTS — what each option makes us own that is easy to miss: upgrades, on-call, data migration, compliance review, a vendor's roadmap.

D) RECOMMENDATION — the option you would choose, the condition under which you would choose differently, and the smallest experiment that would reduce the biggest uncertainty.

Inputs: [CAPABILITY NEEDED] · [CANDIDATES WE FOUND WITH LINKS OR NOTES] · [TEAM SIZE + SKILLS] · [CONSTRAINTS: BUDGET, COMPLIANCE, TIMELINE]

Rules: Do not invent pricing, license terms, feature lists, or adoption numbers — mark each as "verify on the provider's own page or license file". Verify license compatibility with whoever owns that call in your organization before adopting. Keep proprietary architecture details and credentials out of consumer AI tools beyond what I described.

Why this prompt works

Teams usually compare the cost of building against the price of adopting and miss what each option makes them own afterwards. Splitting requirements into tiers, listing hidden ownership costs, and naming the exit cost makes the comparison fair. The smallest de-risking experiment turns a debate into a short test, and the verify labels keep stale pricing or license details out of the decision.

Frequently asked

Related Dev & Engineering prompts