AWS Builder Center
Decision Support Tool (Built with Kiro)

Decision Support Tool (Built with Kiro)

I built a tool that compares technical options based on constraints and priorities, then explains the trade-offs in plain language. Instead of just giving an answer, it shows why one choice makes sense for your situation.


What This Is

Whenever I compare tech, databases, APIs, cloud services, frameworks, I always run into the same problem:
Everything tells me what to use.
Almost nothing tells me why.
I wanted something that doesn’t just say:
“Pick this.”
…but instead shows:
  • what it’s good at
  • what it’s bad at
  • and what I’m trading off by choosing it
So I built a Decision Support Tool that compares options based on real constraints and priorities, and then explains the result in plain language.
I built the entire thing using Kiro, which made the process faster, cleaner, and honestly more fun than my usual workflow.

Why I Built It

Every technical decision is a compromise:
  • PostgreSQL vs DynamoDB
  • Cost vs performance
  • Simplicity vs control
Most advice online is either:
  • too generic, orjust someone’s opinion, or
  • a ranking with no reasoning
That’s frustrating when you’re actually responsible for the choice.
I wanted a tool that would:
  • let me define what I care about,
  • apply those priorities consistently,
  • and show me exactly why one option came out ahead.

What It Does

You give the tool:
  1. The options you’re choosing between
  2. Any hard requirements (constraints)
  3. What matters most to you (priorities + weights)
It gives you back:
  • a ranked list
  • a score for each option
  • and written reasons showing strengths and weaknesses
Not a black box. Not a magic answer. Just structured reasoning.

How I Designed It (With Kiro)

I started by asking Kiro how to structure the system: what belongs in the backend, how data should flow, and where the actual comparison logic should live.
Kiro helping me think through the architecture
architecture
The idea was simple:
1
2
3
4
5
6
User input
→ API
→ filter by constraints
→ score using priorities
→ explain the trade-offs
→ return the result
Nothing fancy. Just clean separation between UI, logic, and output.

The Core API

1
2
3
4
5
6
7
8
9
10
export default async function handler(req, res) {
const { options, constraints, priorities } = req.body;

if (!options || options.length < 2) {
return res.status(400).json({ error: "At least two options are required" });
}

const result = generateRecommendation(options, constraints, priorities);
return res.status(200).json(result);
}

Designing the API with Kiro

Instead of guessing the structure, I asked Kiro to define a clean request/response contract.
Kiro laying out the API contract
api layout
Example Input
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
"options": [
{
"id": "postgres",
"name": "Amazon RDS PostgreSQL",
"features": { "cost_per_hour": 0.145, "read_latency_ms": 5 }
},
{
"id": "dynamodb",
"name": "Amazon DynamoDB",
"features": { "cost_per_hour": 0.25, "read_latency_ms": 1 }
}
],
"constraints": [
{ "criteria": "cost_per_hour", "operator": "lte", "value": 0.30, "required": true }
],
"priorities": [
{ "criteria": "read_latency_ms", "weight": 0.40, "optimization": "minimize" },
{ "criteria": "cost_per_hour", "weight": 0.60, "optimization": "minimize" }
]
}

The Part I Care About: Explainability

The real work happens in the scoring logic:
  • filtering out anything that violates constraints
  • scoring each option using weighted priorities
  • sorting by total score
  • and attaching reasons to every result
I used Kiro heavily here to check logic, clean up edge cases, and make sure the output stayed readable.
Kiro walking through the scoring logic
logic
Example Output
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
{
"rankedOptions": [
{
"optionId": "dynamodb",
"name": "Amazon DynamoDB",
"totalScore": 87.5,
"reasons": [
{
"criteria": "read_latency_ms",
"explanation": "DynamoDB has much lower read latency (1 ms)",
"impact": "positive"
}
],
"tradeOffs": {
"strengths": ["Low latency"],
"weaknesses": ["Higher cost"]
}
}
],
"summary": {
"topRecommendation": {
"optionId": "dynamodb",
"confidence": 0.85,
"reasoning": "Latency mattered most, and DynamoDB clearly performed better"
}
}
}
Instead of hiding behind a number, the tool tells you what you’re gaining and what you’re giving up.

Making the UI About Comparison (Not Just a Winner)

I didn’t want a UI that just highlights the top option.
That misses the point.
So I used Kiro to help restructure the frontend to:
  • show options side by side
  • keep scores visible
  • list reasons as bullet points
  • make trade-offs obvious
Kiro helping redesign the frontend
frontend
The goal was clarity, not decoration.

How Kiro Actually Fit Into My Workflow

I didn’t just “use AI and hope for the best.”
I treated Kiro like a collaborator inside my editor.
I kept track of the prompts I used for:
  • system design
  • API structure
  • scoring logic
  • UI changes
The actual prompts used while building
Everything in the project can be traced back to specific decisions and iterations.

Why This Feels Different

This isn’t about “AI making decisions.”
It’s about:
  • making decisions understandable
  • turning trade-offs into something you can reason about
  • giving developers a way to justify choices instead of guessing
The tool doesn’t replace thinking, it supports it.

What I Took Away

Using Kiro changed how I work:
  • Less time stuck on structure and boilerplate
  • More time thinking about how decisions should actually be made
  • Faster iteration without losing control of the code
  • Docs, logic, and UI staying aligned naturally
It didn’t feel like asking a chatbot for snippets.
It felt like working with a technical partner inside my editor.

Final Thought

This project isn’t about ranking tools.
It’s about helping people understand their choices.
Kiro made it possible for me to go from a rough idea to a clean, explainable system faster than I normally could, without turning the project into a black box.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article