Inspiration

I always have loads of ideas for projects. Often I start them, and most of the time I don't even finish them. My problem isn’t creativity. The problem is that most of those ideas never make it past the “oh, that would be cool” stage.

For the Kiroween Hackathon, I saw a chance to fix that for myself: build a place where I can dump all my ideas, validate them against specific criteria (like the hackathon rules), and actually move the good ones towards something shippable. That’s how No Vibe No Code was born.

What it does

No Vibe No Code is a web app that takes you from idea to a Kiro-ready setup.

  • You can start by writing your own idea, or use Dr. Frankenstein – a chaotic idea generator inspired by the Kiroween category that mixes random tech companies or AWS services into weird but fun project prompts.
  • You can then validate the idea with the Kiroween Analyser, which scores it against the hackathon criteria and shows how well it fits.
  • Once you’re happy with an idea, the app generates the core docs you need:
    • A PRD – to clarify the problem and the user
    • A technical design doc – to describe how the solution will work at a feature level
    • An architecture design – to map the components, services, and boundaries
    • A roadmap for an MVP – to define the smallest version worth shipping and how to get there
  • Finally, you can export to Kiro:
    • Bundle all your generated docs
    • It generates steering rules
    • Spec templates aligned with your roadmap

Instead of opening Kiro to a blank chat and typing “help me build X”, you walk in with an idea, docs, roadmap, and Kiro boilerplate ready to go. From there you can just start kicking off specs and building.

How we built it

I built No Vibe No Code using the same spec-driven mindset it’s designed to support.

  • I started with a raw Kiro setup (no steering rules, MCPs, or hooks).
  • In the first week I joined the Kiro Discord, read through best practices, and learned about the MCP server directory and auto-generated steering files.
  • From there I gradually added:
    • Custom steering rules for tech, structure and product
    • Useful MCPs
    • Inclusion rules and triggers to wire things together in a way that matched how I like to work
  • I used Kiro Auto for most of the specs at first, then experimented with Sonnet 4.5, and finally switched to Opus 4.5 for the last few specs where quality really mattered.
  • When Kiro announced property-based testing, I dedicated a spec just to adding it, so I could trust the logic behind flows like validation and scoring a bit more.

It started as “let’s just see what raw Kiro does” and ended up as a small ecosystem that actually understands how I like to work.

Challenges we ran into

  • Starting completely raw with Kiro: no steering, no MCPs, no hooks. I was missing a lot of Kiro’s power at the beginning and discovered things as I went.
  • Model trade-offs: figuring out when Auto was “good enough” and when to pay more for Sonnet or Opus, especially under hackathon time and credit limits.
  • Feature scope: Dr. Frankenstein, validators, docs, and export to Kiro are a lot of moving parts, so I had to keep reminding myself this was still a hackathon project, not a full-blown SaaS.

Accomplishments that we're proud of

  • Turning my “too many ideas, not enough finished things” problem into an actual tool I can use for future projects.
  • Making Dr. Frankenstein: it can generate really crazy and bizarre ideas
  • Shipping a working flow from idea → validation → docs → Kiro export
  • Adding localisation to the project to support both English and Spanish languages

What we learned

  • Starting with raw Kiro was interesting, but having a good boilerplate from day one would have made things much easier.
  • Property-based testing gives a nice confidence boost when you’re letting AI generate non-trivial logic.
  • Trust in “autopilot” is earned: models behave much better when you give them strong boundaries and good inputs rather than asking them to “just build the thing.”

The project is now live and open source:

Apps built with No Vibe No Code:

  • Spooky Snippets - A collection of pixi and three js spooky animations for your frontend

Website: Spooky Snippets // Repository: GitHub – llamojha/spooky-snippets-kiroween

  • SaaS Landing Page Showcase - Show case SaaS Landing Page UX and their prompts to generate your own

Website: SaaS UX Showchase // Repository: GitHub – llamojha/saas-landing-page-showcase

What's next for No Vibe No Code

Next steps I’d like to explore:

  • Adding more validators beyond Kiroween (e.g. side projects, games, other hackathons) - working as modules or microservices
  • Polishing the Kiro export and steering rules so it’s even easier to go from “I’ve got an idea” to “I’m already writing specs”. Adding structure for microservices.
  • Maybe rebranding to No Vibe No Spec
  • Adding suggestions for Kiro Powers

Built With

Share this project:

Updates