FAQ

Everything you need to stay on top of what your product becomes after launch.

Guides

What is Hulahoop?

Hulahoop watches what happens after you launch. Connect a GitHub repository, add product context, and Hulahoop turns real usage into a clear queue of next moves. Each item shows what changed in live behaviour, why it matters, and what to do next. You review before anything touches your code. Hulahoop is built for makers who shipped with AI tools and want steady, safe progress without taking on an ops burden.

Design approach

Every screen leads with the outcome and hides setup detail until you ask for it. The layout stays calm and easy to scan so you can make one decision at a time without being pulled into configuration before you need it. The goal is a product that feels like a senior colleague keeping an eye on things, not a dashboard you have to interrogate.

Quick start

Sign in with GitHub and connect a repository. Hulahoop asks a short set of onboarding questions and writes a PROD.md file to your repo. Once that file is in place, Hulahoop starts watching your live property. Real usage signals surface as items in your queue. Each item tells you what happened, how confident the read is, and what the next step would be. You decide whether to act.

Review before patch generation

Not every signal warrants a change. Hulahoop first checks whether the signal is meaningful given your product context and recent history. Signals that do not clear that bar are logged but do not produce items. The ones that do clear it become a concrete next step with a confidence score and the files it would touch. You review that before any write access is used.

The PROD.md file

PROD.md is the runtime contract for your property. It records your domain, cloud provider, region, scaling mode, database type, backup policy, and the names of every secret your app needs at runtime. It lives in your repository, version-controlled alongside your code, so anyone looking at the project can see exactly how it runs. Hulahoop generates your first PROD.md during onboarding and keeps it up to date as your setup changes.

Connecting a GitHub repository

During onboarding you choose which repository to connect. Hulahoop requests read access to scan your code and write access scoped to that repository so it can commit PROD.md and, later, propose changes as reviewable diffs. You control which repositories are connected and can revoke access at any time from your settings. Hulahoop never pushes to a protected branch or bypasses a required review.

Custom domains

Your live domain is tracked in PROD.md alongside the rest of your production context. When your domain changes, updating the file keeps Hulahoop and your team aligned on which property is being watched. A stale domain entry is one of the quieter causes of signal confusion during incidents, so PROD.md treats the domain as a first-class field rather than an afterthought.

Environment variables and secrets

Secret values are never committed to your repository. PROD.md holds only the names of the variables your app needs at runtime. You supply the values to Hulahoop once through an encrypted channel and they are stored securely and injected at runtime. If a required variable is missing when a change is proposed, Hulahoop flags it before any write access is used. The name list in PROD.md also serves as documentation so new collaborators can see the full runtime contract at a glance.

Health checks and explainability signals

You can send runtime events to Hulahoop from your app using a lightweight ingest script available in your settings. Events are correlated with watchpoints defined from your PROD.md and page context. When a watchpoint threshold is crossed, a signal is generated. Signals are evidence, not verdicts. Hulahoop surfaces them as items in your review queue with the source, the threshold that was crossed, and the confidence level so you can see exactly what triggered each item.