Question 1

What is Hulahoop?

Accepted Answer

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 behavior, 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.

Question 2

Why not just ask the AI that built my app?

Accepted Answer

Because a coding agent optimizes once, from a blank slate, and only when you ask. It never met the people using your app, it does not know what normal looks like in your market, and it stops paying attention the moment a change ships. Hulahoop works the other way round. It watches real usage on your live app, holds a durable contract for what the app is for and what must not get worse, and keeps a record of every move it tried and what that move did. That record compounds: it shows which small changes move your numbers, on your app, with your users, and Hulahoop keeps working through the next one. That matters most in the stretch where maintenance stops being fun. Most apps become abandonware there, because the only thing keeping them moving was the owner opening the repo. Hulahoop keeps going. The honest way to read the difference is on the clock: a coding agent is judged on one session, and your app has to keep working for years. Over that horizon the thing that wins is not the best single answer, it is the record of what has already worked. You still review every move before it ships.

Question 3

Design approach

Accepted Answer

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.

Question 4

Quick start

Accepted Answer

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.

Question 5

The PROD.md file

Accepted Answer

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.

Question 6

Connecting a GitHub repository

Accepted Answer

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.

Question 7

Review before patch generation

Accepted Answer

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.

Question 8

Custom domains

Accepted Answer

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.

Question 9

Environment variables and secrets

Accepted Answer

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.

Question 10

Health checks and explainability signals

Accepted Answer

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.

Frequently asked questions