Built with Kiro
How Kiro's spec-driven workflow shaped FlowLens from requirements through production-readiness work.
Spec-driven development
Kiro gave FlowLens a product boundary before implementation pressure could blur it.
The project started as requirements, design, and task artifacts rather than an open-ended coding session. That structure made the current Electron app easier to extend into setup, packaging, settings, security, and lifecycle work.
Why Kiro was central
The hard part of a fast build is not producing code. It is keeping the product legible while the implementation changes quickly. Kiro helped by forcing the early questions into explicit artifacts:
- what problem FlowLens solves
- which modes belong in V1
- which privacy boundaries are non-negotiable
- where Electron main and renderer responsibilities should split
- what shape a model response must return
- what should stay out of scope
That made later work less chaotic. When settings, encrypted secrets, tray lifecycle, packaging, updates, and diagnostics were added, they attached to an existing product structure instead of redefining the app.
Requirements-first scope
The project began with explicit user stories and acceptance criteria. The three modes, privacy posture, and one-follow-up boundary were product decisions before they became code.
Design before implementation
The design artifacts settled Electron boundaries, provider abstraction, screen capture behavior, and structured response format before implementation details took over.
Task-driven build sequence
Implementation work followed the spec instead of drifting toward whichever feature was most exciting. That mattered when the app expanded from overlay prototype to packaged background app.
Review-driven refinement
Later fixes came from concrete review findings: real tray icon, tray readiness refresh, setup/settings route split, and onboarding validation before completion.
What spec-driven development changed in practice
Scope control
It kept V1 narrow
FlowLens stayed focused on prompt improvement, error explanation, and writing improvement instead of becoming a generic desktop agent.
Architecture clarity
It created stable interfaces
The provider adapter, structured response contract, IPC boundary, and conversation state were designed as separable pieces.
Safety
It made privacy explicit
Capture is invocation-only, the renderer does not receive raw secrets, diagnostics are redacted, and setup gates risky runtime paths.
Maintenance
It made production work attach cleanly
Packaging, tray/menu-bar control, launch-at-login, updates, setup, settings, and cleanup could be layered around the core pipeline.
Concrete examples inside FlowLens
| Area | Kiro-shaped decision | Current implementation |
|---|---|---|
| Modes | Keep three clear workflows | Prompt Doctor, Error Explainer, Writing Improver |
| Response shape | Make model output predictable | spoken_summary, card_content, clarifying_question, actionable_output |
| Privacy | No passive capture | hotkey-gated screenshot and mic capture only |
| Process boundary | Keep privileged work in main | config, secrets, capture, provider, STT, TTS, updates, diagnostics |
| Extensibility | Avoid provider lock-in | OpenAI-compatible adapter with configurable base URL, key, and model |
| Installability | Remove terminal-only workflow | electron-builder packaging, setup wizard, tray/menu-bar lifecycle |
Where the original spec still matters
The original Kiro artifacts remain useful because they explain why the product is shaped this way:
requirements.mdcaptures the user stories and acceptance criteriadesign.mdcaptures the early architecture and trade-offs.kiro/specs/*in the desktop app repo preserves the spec-driven development trail- this Fumadocs site turns those artifacts into readable implementation documentation
FlowLens versus pure vibe coding
| Spec-driven with Kiro | Pure vibe coding |
|---|---|
| starts with user stories and acceptance criteria | starts with implementation energy |
| makes constraints visible early | lets constraints appear late as bugs |
| uses design docs to settle interfaces | discovers interfaces while coding |
| derives tasks from product shape | chases the next interesting feature |
| supports review and production hardening | often leaves the demo hard to install or maintain |
Why reviewers should care
Kiro's value is visible in the product itself. FlowLens is not just a voice UI on top of a screenshot. It has a scoped product surface, explicit privacy model, tested boundaries, setup validation, and a background-app lifecycle. That coherence came from the spec process.