Skip to main content

​
Usage-Driven Development

Usage-Driven Development means the best next change comes from how people actually use the app, not only from the first prompt. In GenieForge, Usage shows what people actually did (pages, forms, first jobs). Signals and feedback capture friction, missing features, bugs, and workarounds. You review both, then improve the app in Build mode with plans, versions, and Preview. Day-to-day controls live on Signals and in-app feedback. This page is the governing idea.

​
Usage is a signal, not a command

The app does not silently rewrite itself from telemetry. Changes stay reviewable, permissioned, and reversible. GenieForge shortens the path from friction to a proposed fix; humans still decide what ships.

​
The loop in eight steps

  1. Someone hits friction in Chat or on a page (for example, asking to export a report that does not exist yet).
  2. A signal or Feedback captures it with enough context to reproduce the gap.
  3. Similar reports group on the project Signals → Grouped tab and rank by recurrence. When you commit to build one, add it to Roadmap.
  4. You review the evidence: is this an app fix, or a platform gap tagged for Platform feedback?
  5. You ask Build for a plan (often from the signal’s one-click path) that describes the missing outcome for the affected role.
  6. You Preview as those roles and confirm Access still looks right under App Blueprint → Access.
  7. A version ships from sidebar Publish so you can roll back the recipe if needed.
  8. An eval confirms a critical chat flow still works after the change (see Evals).

​
App improvements vs platform improvements

Closing a signal does not automatically close Platform Feedback, and the reverse is also true. Account or billing issues still go to support@genieforge.ai.

​
How to practice UDD day to day

  • Prefer small, named Build asks after reading Signals, not rebuilding the whole app from a vague feeling.
  • Describe the next change as an outcome fix for a role (“clients can download their own statement”), not a shopping list of blueprint labels.
  • Put durable preferences in Build Rules so each fix does not re-argue style or ownership rules.
  • Use Evals for the few chat paths that must not regress when you evolve.
  • Watch Credit Usage so improve loops stay intentional (Controlling credits).