Building Option Insights: A Three-Week Journey with Kiro

The Inspiration

I built insights.sumiya.page as a personal finance tool to visualize statistics for my retail option trades. The tool analyzes CSV exports from brokers like Robinhood and Tastytrade, providing insights into trading performance, win rates, and strategy effectiveness, all running entirely in the browser without sending data anywhere.

Four months before starting this project, I had seen announcements about Kiro, an agentic IDE from AWS that facilitates spec-driven development, but couldn't get access. When this hackathon offered free Kiro credits, I jumped at the opportunity to finally try it out.

Why This Project?

I chose this project based on three key constraints:

  1. Personal utility: Something I would use myself
  2. Scope: Small enough to finish in 20-30 hours
  3. Familiarity: Domain and technologies I was comfortable with

Limiting the project to my personal options trading gave me control over the domain, while choosing plain HTML and JavaScript and deploying on AWS infrastructure I already owned kept the technical complexity manageable. I started with ambitious goals but scaled them back after a week when I realized the full vision would exceed the hackathon timeline.

The Development Process

Spec-Driven Development

Spec-driven development became a simple method: start by creating detailed specifications and requirements documents, then break down the work into concrete, executable tasks that can be systematically implemented.

I began by asking Kiro to explain how it worked and what information it needed. Kiro generated a structured document with placeholders, which I filled out with my requirements. After some back and forth with clarifying questions, we settled on a design and generated specific tasks for execution.

The approach I used was straightforward: use Kiro's spec-driven mode to create highly specific tasks, let Kiro execute those tasks, then validate the output myself.

Kiro helped me structure thorough requirements using industry standards like EARS (Easy Approach to Requirements Syntax) and INCOSE (International Council on Systems Engineering) system engineering standards.

Model Selection

Initially, I used Kiro's default Auto model, but found myself doing too much manual cleanup work. I switched to Claude Sonnet 4.5, a model I had successfully used in other projects. While it consumed 30% more credits per query, the familiarity and better output quality made it worthwhile.

The Timeline

The project spanned November 9-27, 2025, moving through distinct phases:

  • Nov 9: Initial repository setup
  • Nov 10: Planning and specification creation
  • Nov 11: Core foundation (8 commits) - CSV parser, analytics engine, data store, visualizations
  • Nov 12: Multi-broker support and summary metrics
  • Nov 13-14: Advanced visualizations with collapsible sections
  • Nov 15: UX improvements (7 commits) - demo data, iOS fixes, light mode
  • Nov 16: Bug fixes and file reorganization
  • Nov 23: Cleanup and asset management
  • Nov 24-25: UI refinements (7 commits) - CSS improvements, hierarchy optimization
  • Nov 26: Strategy improvements (6 commits) - better inference and naming
  • Nov 27: Infrastructure deployment (12 commits) - AWS setup and deployment scripts
  • Nov 28: Public release

Key Lessons and Challenges

What Worked Well

Structured Requirements: Going from an abstract idea to a feasible implementation plan with guidance on the spec-driven development process was excellent. The structured approach helped crystallize exactly what needed to be built.

Credit Visibility: Seeing credits consumed per query helped me understand which operations were expensive and oriented me toward more efficient prompting.

MCP Integration: Being able to link MCP servers (like AWS MCP) let me review and update infrastructure directly through Kiro, streamlining the deployment process.

Checkpointing: While I didn't need it, Kiro's checkpointing feature allows reverting to specific points in your development journey - a safety net for experimentation.

Critical Challenges

Parallel Execution Disaster: After initial successes, I got overconfident and launched 8 tasks in parallel. This wrecked my project state, teaching me a valuable lesson about controlled iteration.

To prevent this, I updated Kiro's steering documents with explicit instructions:

  • "Ensure there is no regression when a change is proposed"
  • "Review documentation and propose updates when the docs differ from the actual implementation"

These guardrails prevented similar issues in subsequent development phases.

Who Benefits from This Approach?

This methodology works well for:

  • Solo developers who prefer decomposing large bodies of work into organized, executable tasks
  • Development teams conducting discovery work where the goal is breaking down complex projects into serial and parallelizable tasks

The idea of breaking work into smaller units isn't novel, there's ongoing research on massive agentic decomposition using microservices architectures, but having a tool that facilitates this systematically makes the approach more accessible.

Final Thoughts

After using Kiro for three weeks, I'd recommend it for exploring whether spec-driven development fits your workflow. The key value isn't just code generation, it's the structured approach to decomposing requirements into actionable tasks.

If you've been putting off a complex project, try at least getting to the task breakdown stage.

At best, you'll be surprised by how quickly you can ship. At worst, you'll have a thoughtful collaborator helping you crystallize what you actually need to build.

Here is my release announcement: https://sumiya.page/2025/November/option-insights.html

I subsequently wrote about using Kiro in more detail here: https://sumiya.page/2025/November/building-option-insights-using-kiro-and-spec-driven-development.html

Share this project:

Updates