Verified against ChatGPT · 2026-08-13
Map a technology landscape around the one decision it actually needs to inform
Produces a technology landscape brief organized around a specific buy-vs-build or vendor-selection decision, rather than a broad survey of every player in the space.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Map the technology landscape for the area below, but keep it organized around the actual decision I'm making — not a comprehensive survey of every vendor and approach that exists in this space. TECHNOLOGY AREA Vector database options for a RAG-based internal knowledge search tool. THE DECISION THIS MAP FEEDS Whether to self-host an open-source vector store or use a managed service, for a team of 4 engineers with limited ops bandwidth. CONSTRAINTS THAT RULE OPTIONS IN OR OUT Must support on-prem deployment for one specific client's data residency requirement; budget under $2,000/month at current scale. WHAT I ALREADY KNOW OR HAVE RULED OUT Already ruled out fully-managed enterprise options as too expensive for our current scale — no need to re-litigate that. Organize the landscape around Whether to self-host an open-source vector store or use a managed service, for a team of 4 engineers with limited ops bandwidth., grouping approaches or vendors by how they answer that decision rather than by category labels that don't map to it (e.g., don't just list "open source vs proprietary vs managed" if what actually matters to the decision is something else, like data residency or integration effort). Apply Must support on-prem deployment for one specific client's data residency requirement; budget under $2,000/month at current scale. as hard filters, not soft preferences — an option that fails a hard constraint should be excluded entirely and named as excluded, not included with a caveat. For each option that survives the filter, state what would make it the right choice and what would make it the wrong one, tied to the actual decision, not a generic list of pros and cons. Skip re-explaining anything already covered in Already ruled out fully-managed enterprise options as too expensive for our current scale — no need to re-litigate that. — treat that as already known rather than restating it. WHAT NOT TO DO Do not produce an exhaustive vendor list padded out for completeness — every entry in the final map has to be a genuine live option for Whether to self-host an open-source vector store or use a managed service, for a team of 4 engineers with limited ops bandwidth., not a name mentioned for thoroughness. Do not present a "clear winner" unless the evidence genuinely supports one; a landscape this early usually narrows the field, it doesn't always pick the final answer. OUTPUT FORMAT 1. The decision restated in one line. 2. Options excluded outright by Must support on-prem deployment for one specific client's data residency requirement; budget under $2,000/month at current scale., named and why. 3. A table of the remaining live options: name, right-fit scenario, wrong-fit scenario, and open question still needing an answer before committing. 4. If evidence points clearly toward one option, say so plainly; if it doesn't, say that plainly too instead of forcing a recommendation.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A generic "map the landscape" request gives a model no principle for what to include or exclude, so it defaults to the most common organizing scheme for that technology category found in its training data — usually a category taxonomy like open-source-vs-managed that may have nothing to do with the actual decision at hand, and it tends toward completeness (listing every notable player) because that reads as more thorough even when most of those players are irrelevant to the specific choice being made. Anchoring the map explicitly to one decision changes the sorting logic entirely: instead of grouping by industry-standard category labels, the model has to group by how each option answers the actual question, which is a fundamentally different and more useful cut of the same information. Treating hard constraints as filters rather than soft caveats matters because a model asked to "keep constraints in mind" will often include a constraint-violating option anyway with a footnote acknowledging the mismatch, which leaves a decision-maker to do the actual filtering themselves — explicitly requiring exclusion forces that filtering to happen upfront where it belongs. Refusing to force a "clear winner" when the evidence doesn't support one addresses a specific pressure in landscape research: a confident recommendation reads as more useful and complete than an honest "it depends, here's what would tip it," so a model will lean toward manufacturing a top pick unless explicitly told that a genuinely still-open decision is an acceptable and more honest output than a premature one.
What you get back
Decision: self-host vs. managed vector store for a 4-person eng team. Excluded outright: fully cloud-only managed options with no on-prem deployment path (fails data residency constraint for one client). Remaining options table: pgvector (self-hosted) — right fit if the team is comfortable owning Postgres ops; wrong fit if uptime SLAs matter more than cost. Weaviate (self-hostable, has managed tier) — right fit if wanting a migration path to managed later without a rewrite. Open question for both: actual ops burden estimate given the team's current bandwidth is still unverified.
Verified against
ChatGPT GPT-5.1 · 2026-08-13
Changelog
- 2026-08-13 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
