I Never Used Kiro Before. One Day Later, My App Was Live and Submitted to Kiroween.

Yesterday morning I had never used Kiro. By the evening, my app was deployed, demoed on video, and submitted to Kiroween 2026. This is an honest account of that day — what Kiro did, what it got wrong, and what actually changed about how I build.

The app

I hunt free NFT mints on BNB Chain, and I kept seeing the same trap: a contract looks free, but it hides an owner backdoor, a fake free quota, or a mint lane gated by some backend voucher. A simulation alone misses those. A security scan alone misses eligibility. So I built Free-Mint Triage: paste a contract address and it runs a two-node on-chain mint simulation, a GoPlus security scan, and a Sourcify source-verification check, then gives one plain verdict — Clean, Ambiguous, or Red Flag — with the evidence shown, not just a score.

It is read-only. No wallet connection, no signing. It can never move funds.

Live app: https://free-mint-triage.onrender.com
Source (MIT): https://github.com/pikyoe/free-mint-triage
Demo video: https://www.youtube.com/watch?v=ftQ7IM1s-pA
Devpost project: https://devpost.com/software/free-mint-triage

Hour zero: logging in without a browser

The first surprise was the login. My environment is headless — no browser for the normal sign-in flow. Plain kiro-cli login failed, as expected. But kiro-cli login --use-device-flow printed a code and a URL, I approved it on my phone, and the CLI was logged in. That one detail set the tone for the day: Kiro is built to work where developers actually are, not only in a shiny IDE window.

Spec first, code second

I did not vibe-code this. Before any code existed, the project had a spec in .kiro/specs/triage-app/ — requirements, design, tasks — plus steering docs in .kiro/steering/ describing the product, the tech, and the structure. Kiro's CLI chat then generated the frontend, the README, the LICENSE, and the .gitignore from that spec.

This is the part that changed how I build. Normally I would start typing and discover the design halfway through. With the spec in place, the plan existed before the code, and Kiro implemented to the plan. When something came out wrong, the argument was about the spec, not about a pile of generated code I no longer understood. The spec is the plan; the code is the execution.

What Kiro got wrong (and why that matters)

I want to be honest about the split, because "built with Kiro" should mean something specific. Kiro generated the UI, the README, and the LICENSE. The server, all the bug fixes, and the live tests were done by hand. And Kiro's frontend had a real bug: after the first check, its badgeFor() function replaced the badge elements without keeping their IDs, so the second check on the page crashed and showed a false "Network error." A judge doing a second check would have hit it. I found it while recording the demo video, fixed it by hand, and redeployed.

There was a second one: a mint simulation that genuinely needed more gas than the first sim allowed, which looked like a revert until I raised the cap. These are the bugs that only show up when you test the real thing, twice, against the live chain. Kiro got me 80% there fast. The last 20% — the part where the app actually has to be correct — was still mine.

That is, I think, the honest shape of building with an AI coding tool in 2026: it compresses the boring middle, and it makes the verification step more important, not less.

The rest of the day

Once the app worked, the day became logistics: a public GitHub repo (the connector could not create it, so I created it by hand), a free Render deploy in Singapore, a 67-second demo video recorded against the live site, and a Devpost submission in the Frankenstein category — stitching incompatible pieces (two RPC nodes, GoPlus, Sourcify) into one verdict.

Total time from first login to submitted project: one day. Total cost: $0 — free tiers all the way down, and the app itself spends nothing on-chain because it only reads.

What I will take into the next project

Three things. First, write the spec before the code, even for a small app — it is the cheapest leverage in the whole process. Second, test the generated code the way a skeptical user would, twice in a row, because the first run passing proves almost nothing. Third, keep an honest ledger of what the tool did and what I did; the write-up that judges read should be able to say exactly that, and mine does — the repo's KIRO-USAGE.md records the full split.

Kiro did not replace the building. It replaced the blank page. That turned out to be enough to go from zero to submitted in a day — and I will use it again.