Choosing a Framework: Prompt Options for Tradeoff Analysis

Bowman Pharmacy Group runs 312 stores, and last March a restock alert for insulin pens arrived nine hours after the shelf was already bare. The engineering team had four backend engineers, an eleven-week deadline, and four candidate frameworks scrawled on a whiteboard. The framework was never the hard part. The hard part was getting an AI model to lay the tradeoffs out honestly enough that the team could kill two options in one afternoon instead of arguing about them for a month.

This is a parameter-fitting problem, not a “which one is best” problem. Below are four prompt shapes for the same decision: an open comparison, a weighted scoring matrix, an adversarial risk pass, and a spike plan. Each fits a different amount of remaining time and a different level of agreement in the room. Swap in your own framework names and constraints and the structure still holds. If you first need to understand how the existing services are wired before naming candidates, pair this with code versus architecture prompting.

The Tradeoff Table for the Pharmacy Case

The four options the Bowman team wrote on the board were Django, Spring Boot, NestJS, and Go. The table below is the shape you should force any model to produce: one row per realistic situation, not one row per framework feature.

Read the fourth column before the third. The cost column is where a real decision gets made, because every framework on this list can technically store a restock alert. The question is what you pay in operations, hiring, and future debugging to keep it running at 4am. Notice that Go wins on the polling row and loses on the admin-screens row in the same table, which is the whole point: a framework is not good or bad, it is good or bad for a named workload.

When you feed this table to a model, keep the scenario column concrete. “High traffic” produces generic advice. “Polling 312 store feeds every 3 minutes on 2 vCPU VMs” produces an answer you can act on. The difference is not the framework knowledge; it is the specificity of the constraint you handed over.

When Each Prompt Shape Fits

Prompt shape should follow the state of the discussion, not the size of the budget. If nobody agrees on the candidates yet, an open comparison is the fastest way to surface options you forgot. If the shortlist is already three names long and the room is split, a weighted matrix forces everyone to argue about weights instead of vibes. If a decision is nearly made, an adversarial pass is the cheapest insurance you will ever buy. If you are still guessing at throughput, no amount of analysis beats a two-day spike.

The trap with the Bowman alert system was that the team wanted a pure performance answer while the actual constraint was a four-person team shipping in eleven weeks. That is a delivery question, and only the adversarial and spike prompts would have exposed it. A related habit, applying the same discipline to code review after the choice is made, is covered in code review prompts.

Prompt Snippets for Each Path

1. Open comparison. Use this first, while the candidate list is still soft.

Act as a backend architect. I am choosing a backend framework for an inventory alert system for a 312-store pharmacy chain. Team is 4 backend engineers, deadline 11 weeks. Candidates: Django, Spring Boot, NestJS, Go. For each, give: best-fit workload, two concrete strengths, two concrete costs, and one situation where it is the wrong pick. End with the single question the team should answer before choosing. Use plain prose, no code.

2. Weighted scoring matrix. Use this once the shortlist is fixed and people disagree.

Build a weighted decision matrix for picking a backend framework for a pharmacy inventory alert service. Criteria and weights: time to first working endpoint 30%, operational simplicity 25%, team familiarity 20%, concurrency for polling 312 store feeds 15%, long-term hiring pool 10%. Score each candidate (Django, Spring Boot, NestJS, Go) 1 to 5 per criterion, show the weighted total, and state which single weight would have to change to flip the winner.

3. Adversarial risk pass. Use this right before you commit.

Argue against choosing Go for a pharmacy inventory alert system. Assume a 4-person team with no Go in production and an 11-week deadline. List the five most likely ways this choice fails in the first six months, rank them by probability and impact, and for each give a cheap mitigation. Then tell me which one failure would be unrecoverable.

4. Spike plan. Use this when throughput is still a guess.

Design a 2-day spike to compare NestJS and Go for polling 312 pharmacy store inventory feeds every 3 minutes. Define the one metric that decides it, the exact test harness to build, the data volume to simulate, and the pass or fail threshold. Keep total effort under 16 engineer-hours.

5. Migration-cost probe. Use this to price the exit you may never take.

Estimate the cost to move a running pharmacy inventory alert service from Django to Go 18 months from now, assuming 7 REST endpoints, 12 database tables, and one nightly reconciliation job. Give effort in engineer-weeks and name the two parts that dominate the estimate.

6. On-call reality check. Use this to test an option against the people who carry the pager.

A pharmacy chain has 3 engineers on a shared on-call rotation, none of whom have run Spring Boot in production. List the five incident types most likely to page them in the first quarter on a Spring Boot inventory alert service, and for each, rate how hard it is to diagnose without prior Java experience.

The Tradeoffs Nobody Writes Down

Three costs hide behind every framework comparison. The first is the cost of being wrong slowly: a choice that is 15 percent worse in raw benchmarks but lets a four-person team ship in eleven weeks is usually the correct choice. The second is operational debt: a runtime nobody on call understands turns every incident into a group project. The third is the cost of the exit, which is why the migration probe prompt exists even when you expect to stay put.

Keep the matrix honest by fixing the weights before you score anything. Teams that score first and weight later always get the answer they already wanted. And keep one rejected option documented with the reason, because in nine months someone will ask why the pharmacy system is not in Go, and a one-line note ends that conversation instantly.

Sources & Notes

These four prompt shapes were written for a chain pharmacy selecting a backend framework for an inventory alert system, but the sequence generalizes: open comparison to surface options, weighted matrix to settle disagreement, adversarial pass to stress the favorite, spike plan to replace a guess with a number. The migration probe is optional and only worth running when the exit cost is genuinely uncertain.

Two cautions. Model output on framework tradeoffs ages quickly, so treat every strength and cost as a hypothesis to verify against your own stack, not as a current fact. And no comparison prompt knows your team’s actual fatigue, hiring pipeline, or on-call reality, so let it shape the debate and then make the call yourself. For the wider habit of describing the system before you ask about tools, the explain-a-codebase approach in explain codebase prompting is a natural next read.