Frequently Asked Questions — Human Testing for AI-Built Products

Jellar is a human signal testing platform for AI-built and vibe-coded web products. Builders list their projects. Real human testers run structured missions and submit detailed, page-level feedback. Everyone earns karma.

It's built for two groups:

• Builders — indie hackers, vibe coders, AI startup founders who have something live but don't have a way to get structured human feedback fast
• Testers — developers, designers, and curious people who want to contribute real signal to real products and earn karma for doing it well

If you've ever shipped something and wondered "why isn't anyone using this thing?" — Jellar is where you find out.

Three things make Jellar different:

• Structured missions, not open-ended browsing. Every tester follows a specific task — not "look around and tell me what you think." The structured format produces comparable, actionable feedback.
• Page-level UX diagnosis. Jellar surfaces where users get stuck, what surprised them, what they'd pay for. Not heatmaps — human sentences.
• It's peer-to-peer. The people reviewing your product are builders themselves. They know what a confusing onboarding feels like from the inside. Twitter engagement inflates vanity metrics. Jellar gives you friction points.

Web apps, iOS apps, and Android apps — at any stage from early MVP to post-launch. Projects go through a rigorous automated multi-point check and a human admin review before going live. Common categories include: SaaS tools, productivity apps, AI utilities, developer tools, creative apps, and marketplaces.

What isn't allowed: adult content, illegal services, apps requiring sideloading from unofficial sources, or anything that collects user data without clear disclosure.

Jellar's model doesn't require a large user base to work — it requires a reciprocal exchange. Free builders must complete 3 missions before listing. That means the platform generates testers organically: every builder who wants feedback has already given feedback to someone else.

For paid packs, the gate is removed — you list immediately. But the review pool still comes from the same mechanism. As the builder community grows, the tester pool grows with it at the same rate, because they're the same people.

In the early days, the Jellar team tests every listed project. As the platform scales, the community takes over. No seeded fake reviews, no outsourced click farms.

Three layers of protection:

• Minimum dwell time. Testers must spend at least 3 minutes with the project before submitting. The timer is enforced and tracked. Spending less than 60% of the requested duration caps quality bonuses.
• Quality-gated karma. Karma isn't awarded for completion — it's awarded for quality. Base 5 points, plus up to 6 quality bonus points for detailed friction descriptions, specific one-change suggestions, and genuine magic moments. Copy-paste reviews score 0 bonus.
• Admin approval queue. Every review is vetted by a human admin before the builder sees it. Low-effort, abusive, or obviously fake reviews are rejected — and rejected reviews have their karma reversed. Testers who farm reviews end up with less karma, not more.

GitHub accounts represent real humans with real histories. Creating a disposable GitHub account with enough commit history to look credible takes significant effort — far more than the karma farming would be worth. Compare this to email sign-up, where anyone can create 50 accounts in 10 minutes.

More importantly, GitHub users are the right demographic. Builders testing other builders produces feedback that's technically literate, practically grounded, and written by people who understand what it's like to ship something. A GitHub user reviewing your onboarding flow is not a random survey respondent — they're a peer.

Google OAuth is also supported for users who prefer it, with the understanding that Google accounts carry their own identity signal.

The natural loop is: build → list → get signal → iterate → list again. Every serious builder goes through multiple versions. The question is whether they have structured feedback to inform each iteration — and that's exactly what Jellar provides.

Builders return when:

• They ship a new feature and want to know if it landed
• They've fixed the friction points from the last round and want to verify
• They're testing a different user flow on the same product (Jellar supports multiple separate missions per URL)
• They've built something new entirely

The platform is designed for iteration, not one-time validation. A single Starter Pack gives you 5 reviews. A Signal Pack gives you 15 with pattern detection. The more you build, the more useful the signal becomes.

Jellar doesn't build your retention — but it identifies what's killing it. The structured mission asks: what confused you, what delighted you, would you pay for this, would you come back. Those four signals directly map to the levers that drive retention:

• Friction points → onboarding fixes, UX improvements, copy clarity
• Magic moments → what to double down on, what to put in the hero
• Would Pay signal → pricing validation, feature prioritisation
• Would Use Again → a direct proxy for D7 retention before you have D7 retention data

Most founders who fail at retention never had a clear signal about what their users found valuable. Jellar surfaces that signal at a stage when you can still act on it — before you've spent six months optimising the wrong thing.

Your submission goes through a comprehensive series of automated checks — URL reachability, HTTPS, load time, no known phishing patterns, etc. Then a human admin reviews it before it goes live. Once approved, your project appears on the Pulse (the live 3D globe and ladder) and testers can pick it up.

You'll get an email when your project goes live, and another email each time a review comes in. All reviews are held in an admin approval queue before you see them — to filter out low-effort submissions. Only quality, genuine feedback reaches your dashboard.

Yes — intentionally. Each submission is a separate mission with its own review cap and its own set of testers. You can use this to:

• Test your sign-up flow, then test your core feature separately
• Get a fresh set of eyes after a big update
• Run different missions against the same product at different stages

The only restriction is that another user can't submit your URL under their account. If someone tries, the check flags it.

Testers see your project listing on the Pulse, including the platform type (web/iOS/Android), expected time to complete, and whether sign-up is required. They click to open a mission briefing that shows your specific task — the exact scenario you want them to test.

They open your product, spend the requested time with it, then complete a structured review covering: star rating, friction points, magic moments, a written summary, one change they'd prioritise, expectation vs reality, and whether they'd use or recommend it. Paid-tier projects also receive First Impression and Would Pay signals.

Testing other people's projects is always free. Testers never pay anything — ever.

Listing your own project for testing is free too, with a condition: you need to complete 3 missions as a tester first (the reciprocal gate). Free listings get 3 reviews per project, per calendar month.

Paid packs remove the gate and increase the review cap: Starter ($15, 5 reviews), Signal ($39, 15 reviews), Launch ($79, 30 reviews). Packs are one-time purchases, not subscriptions.

Karma measures your contribution quality as a tester. Base 5 karma per approved review, plus up to 6 bonus points for detail:

• Detailed friction point (40+ chars)
• Multiple detailed friction points
• Detailed magic moment (30+ chars)
• Detailed summary (80+ chars)
• Specific one-change recommendation (40+ chars)
• Expectation vs reality comparison (40+ chars)

Longer missions pay more: if you spend at least 60% of the requested time and write a quality review, a length multiplier of up to 3x applies. A 30-minute mission with a great review earns twice the base karma of a 5-minute mission.

Karma decays by 5 points per month for inactive accounts. Tiers: New (0-29), Active (30-79), Trusted (80-199), Elite (200+). Trusted and Elite reviewers carry more weight in a builder's dashboard.

No — reviews go into an admin approval queue first. This is intentional. Only quality, genuine reviews reach your dashboard. Low-effort, copy-paste, or suspicious reviews are rejected before you see them. A rejected review also reverses the karma awarded to the tester — so there's no incentive to game it.

In practice, most reviews are approved within 24 hours. You'll get an email as soon as an approved review is released.

Jellar requires all app submissions to link to publicly listed App Store or Play Store listings, or legitimate beta channels like Apple TestFlight. Every submission goes through automated checks and human review before going live.

That said, no review process can guarantee the complete security of a third-party app. Jellar recommends:

• Using a secondary device or test profile when testing unfamiliar apps
• Never entering real payment, banking, or government ID details when testing
• Reviewing the app's permission requests before installing
• Uninstalling the app after completing the mission if you don't want to keep it

All testers must tick a safety acknowledgement checkbox before starting an app-based mission. If something feels off during testing, use the Report button to flag it immediately.

Jellar collects: your GitHub or Google account email (for login), your username, karma score, and the reviews you submit or receive. For project submissions, we store your project URL, location (for the globe), and submission answers.

We don't sell your data. We don't show ads. The business model is review pack purchases — not data monetisation. See the Privacy Policy for the full breakdown.