My First Kiro App Was a Winner. Here's How I'm Building a Monster.

I'm writing this as part of the Kiroween 2026 hackathon, on day one of my build.

A year ago I was a fresh computer science grad starting my first big coding project. I built Denarii, an AI purchase advisor, with Kiro, and it was a winner at the Code with Kiro Hackathon. I said it in my demo video and I'll say it again: working with Kiro felt like working with a team of developers. Except it was just me and Kiro.

Since then, Kiro has helped me start a one-person business, Data Spark Web. Now I'm building Franki for Kiroween 2026, and this one's a monster.

What I'm building: Franki

Franki is a friendly Frankenstein ghost who helps run your life. It's an avatar-first assistant you talk to, stitched together from parts that were never meant to fit: your inbox, your calendar, your meals and your money. That's why I'm entering it in the Frankenstein category.

A project with that many parts doesn't break on the first prompt. It breaks on the fortieth, when the agent forgets a decision from last week or a change in one file quietly breaks three others. On a team, people catch those things. Solo, nobody does, unless your tools do.

Here are the Kiro features I'm using to beat that. It's Kiroween, so each one gets a body part.

Kiro feature	Body part	Job
Specs	Skeleton	Plan before code
Steering and Memory	Brain	Remember rules and lessons
Hooks	Reflexes	Automatic checks and fixes
Property-based tests	Immune system	Catch rule-breaking bugs
MCP and Powers	Hands	Reach real tools and docs
Subagents and Workflows	Muscle	Parallel and background work

1. Specs are the skeleton

A Kiro spec turns "build me X" into three documents you review before any code exists: requirements, a design and a task list. Requirements are written in EARS notation, which makes you say exactly when something happens and what the system must do:

WHEN the user asks Franki to send an email
THE SYSTEM SHALL show the final draft and wait for approval before sending it

That one sentence settles an argument I would otherwise have with myself at 2 a.m. Kiro's Analyze Requirements check looks for ambiguity, conflicts and gaps before design starts. Run all tasks then works through the plan in dependency waves, running independent tasks at the same time.

When I built Denarii, specs taught me how to shape requirements, design clean tasks and actually ship. The lesson that stuck: many small specs beat one giant one. Denarii had five. For Franki, I'm writing one per body part: voice, avatar, memory, daily brief, meals, money and goals.

2. Steering and Memory are the brain

Steering files are Markdown files in .kiro/steering/ that Kiro reads so you don't have to repeat yourself. Start with Generate Steering Docs (product, tech and structure), then add one file per topic. Each file decides when it loads: always, only when you're working on matching files, only when you call it by name, or automatically when the task matches its description.

Denarii had a single steering file, development-philosophy.md: scope control, YAGNI, vertical slices, one focus per spec. Its job was to keep the agent from gold-plating features I didn't need. For Franki, I'm giving privacy, health and money their own always-on steering files. Here's the start of the money one:

---
inclusion: always
---
# Money safety
- Franki can read financial data. It never moves money.
- Every number Franki shows traces back to a source: a transaction, a receipt or the user's own words.

Steering is what you teach Kiro on purpose. Memory, which reached the IDE in October, covers what it learns along the way: your repo's commands and conventions, your corrections, and approaches you've already ruled out. It's off by default, and the notes stay on your machine.

3. Hooks are the reflexes

Hooks fire on events, like a tool about to run or a spec task finishing, and run either a shell command or an agent prompt. Command hooks cost no credits, and a hook that runs before a tool can block it by exiting with code 2.

One of my Denarii hooks was a "Budget Health Guard". Every time the decision model changed, it checked that the weights still summed to 1 and the thresholds didn't overlap, then updated the tests and the README. It was like having a QA engineer and a technical writer on staff.

I'm starting Franki with two hooks: one that keeps secrets and OAuth tokens out of the repo, and this one, which runs the tests after every spec task:

{
  "version": "v1",
  "hooks": [
    {
      "name": "Test after every task",
      "trigger": "PostTaskExec",
      "action": {
        "type": "agent",
        "prompt": "Run the tests for the files this task changed and fix any failures."
      }
    }
  ]
}

4. Property-based tests are the immune system

Unit tests check the examples you thought of. Property-based tests check the rules. In a Kiro spec, the design pulls testable properties out of your requirements. Kiro then throws hundreds of random inputs at each one and shrinks any failure down to the smallest example that breaks it. Each property links back to the requirement it proves.

For Franki, the properties read like promises:

• No action with side effects runs without a confirmation.
• A memory the user deletes never shows up again.
• Every connector's output fits Franki's event schema.

When an assistant can read your inbox and your bank data, "it passed the three cases I wrote" isn't good enough.

5. MCP and Powers are the hands

MCP servers connect Kiro to things outside your editor, like live library docs and GitHub. The most underrated one is a docs server like Context7, which keeps the agent from guessing at APIs that don't exist.

Powers package MCP tools, skills and know-how for a single service or job, like Stripe or Figma, and load only when a task calls for them. There are more than 70. On October 30, the Kiro blog introduced a sample Power that hardens a spec by adding security requirements to it before any code exists. For an assistant that reads your inbox, that one's going straight into my build.

6. Subagents and Workflows are the muscle

In my Denarii video I quoted Steve Ballmer: "developers, developers, developers." This year it's agents, agents, agents.

Subagents each run in their own context and in parallel, so research, implementation and review don't trip over each other. Custom agents in .kiro/agents/ let you define specialists with their own prompt, tools, model and permissions. Workflows, new this fall, chain agent steps into a pipeline that runs in the background while your chat stays free. Kiro shows you the plan before any step runs, and each step starts with a fresh context.

For Franki, I'm building a "limb builder" workflow: plan a new connector, build it, write its property tests, then loop on a privacy review until it passes. The goal: every new limb is one spec away.

The work doesn't have to stop when I close the laptop, either. Kiro Web runs cloud sessions in a managed sandbox, and in the CLI, /goal loops through plan, build and verify until my acceptance criteria pass or it hits its iteration cap. Letting agents run unattended is only smart if they can't wander off. On my own machine, Kiro's local sandbox has the operating system limit what the agents' shell commands can reach. I'm a crew of one, so my attention is the bottleneck. With their commands boxed in, I only approve what matters.

How Kiro helped me start a one-person business

Data Spark Web builds websites for small businesses around Dallas–Fort Worth. Design, code and SEO: it's all me. Kiro helped me start it. The habits Denarii taught me carried straight into client work: write the spec before the code, put the rules in steering, and let hooks do the checks I'd forget at the end of a long day.

I run a one-person web studio. Kiro is the rest of the team.

Steal this setup

If you're building something complex with Kiro, alone or not, here's my best advice:

1. Generate steering docs first, then add one file for each rule that matters.
2. Write many small specs, not one big one. Get the requirements right before the design.
3. Turn every "I always forget to..." into a hook.
4. Write properties for the rules that must never break.
5. Give Kiro real docs and tools through MCP and Powers.
6. Hand parallel work to subagents and repeatable pipelines to Workflows.

What's the one hook or steering file you'd never build without? Tell me in the comments.

I'll keep this post updated as Franki comes to life, right up to the December 4 deadline. Last year Kiro felt like a team. This year it literally is one.

---

This post is part of my Kiroween 2026 hackathon entry. Kiro: kiro.dev · Kiroween 2026: kiroween.devpost.com · Me on GitHub: OracleOfAggieland