Community

Community Guidelines

Twnhall runs on real people doing real testing. Read this once and you'll understand everything about how and why this community works.

The Foundation

The Social Contract

"Real people. Real feedback. Real work."

Twnhall exists because automated testing can't tell you where a real person hesitated. Builders put products in front of actual humans; testers do the work of using them properly and reporting back.

There are two account types: Builder and Tester. They are separate accounts, each with its own dashboard and its own history. One person can hold both — plenty do — but you are always acting as one or the other, never both at once.

Testing here is treated as work. Some missions carry a payout; all of them build a rating and a rank that follow your Tester account. That cuts both ways: testers are accountable for the quality of what they submit, and builders are accountable for reviewing it honestly.

This isn't a SaaS tool. It's a shared workspace where builders and testers hold each other accountable. The energy here should feel collaborative and direct — developer to developer.

How It Works

You pick your account type when you sign up. If you want to do both, create the second account from your sidebar — it's a separate account, and you switch between them.

As a Builder

  1. 1.Create a project — fill in the name, URL, and a brief summary of what you built.
  2. 2.Create Missions — each mission defines one specific area for testers to focus on. Add a payout and a skill tag if you want to pay for the work.
  3. 3.Wait for testers to pick up your missions and submit written feedback with screenshots.
  4. 4.Review each submission — approve it or request changes — and rate the tester's work from 1 to 5.

As a Tester

  1. 1.Browse available missions from your Tester home or the mission feed.
  2. 2.Pick a mission, visit the project URL, and follow the builder's instructions.
  3. 3.Submit written feedback and at least one screenshot as proof of visit, tied directly to that mission.
  4. 4.Track the status on your Tester home. Approved work counts toward your rating, your rank, and your balance.

The Review Loop

Every submission moves through the same four states. Testers see the current state on their home screen; builders move it.

Pending Review

You've submitted. The builder hasn't looked at it yet. Nothing counts toward your rating or balance while a submission sits here.

Approved

The builder accepted the work and rated it. This counts toward your completed-mission count and your rank, and any payout on the mission becomes part of your available balance.

Needs Changes

The builder sent it back with a specific reason. Read the note, fix what they asked for, and the submission can still be approved afterwards.

Paid

The payout has been settled. This is final — a paid submission can't be reopened, re-rated, or rejected.

Approval is the gate on payment.Nothing pays out that a builder hasn't approved first. Builders: review promptly and in good faith. If you request changes, say exactly what needs changing — "not good enough" is not a review.

Withholding approval from work that meets the brief in order to avoid paying is a violation of our Terms of Service and will cost you your account.

Withdrawals aren't live yet.Your approved balance is a record of what you've earned. We'll publish the withdrawal process before enabling it.

The Screenshot Requirement

Every feedback submission requires two things: written feedback and a screenshot from the project.

The screenshot serves a dual purpose — it acts as proof of visit so submitters know you actually used their product, and it provides visual context that written feedback alone can't capture.

This is not optional. Feedback without a screenshot cannot be submitted. This requirement is the trust layer that keeps the community honest.

Standards of Conduct

Be specific

Vague feedback is wasted feedback. Tell the submitter exactly what you encountered, where you got confused, and what could be clearer. Good feedback is actionable.

Be constructive

You're talking to another developer who shipped something and asked for help. Critique the work, not the person. Frame problems as opportunities.

Follow the mission

Each mission has a focus area. Stick to it. If you notice something outside the mission scope, mention it briefly — but don't let it derail your primary feedback.

No harassment or hate speech

This is a peer community. Harassment, discriminatory language, and bad-faith interactions are not tolerated and will result in account termination.

Do the work before you submit

Actually use the product. Submitting feedback for a mission you didn't attempt, padding a comment to clear the length minimum, or running an automated tool in place of real testing defeats the entire point of the platform — and on a paid mission, it's taking money for work you didn't do.

Review honestly, rate fairly

Builders: a rating reflects the quality of the submission in front of you, nothing else. Don't rate someone down because the feedback stung, and don't request changes to delay a payout. Testers: don't solicit ratings or trade them between accounts.

One account per role, per person

You may hold a Builder and a Tester account. You may not create extra accounts to test your own projects, inflate your own reputation, or work around a suspension.

Keep what you see confidential

Screenshots you take while testing often show unreleased work. They're for the builder and for Twnhall — don't publish, share, or reuse them anywhere else.

Respect externally linked projects

When a mission takes you to an external project URL, you're a guest on that developer's product. Behave accordingly — don't abuse, attack, or misuse what you find there.

What Good Feedback Looks Like

Good

"The checkout form loses my input when I click back — I had to refill my card details twice. The error message on the CVV field also doesn't appear until I submit, which was confusing. Screenshot attached showing the empty state after navigating back."

Not helpful

"Looks good! Nice design."

What a Good Project & Mission Looks Like

Testers can only help you as well as you brief them. A clear project sets the context; a focused mission tells testers exactly where to look and what kind of feedback you need.

The Project

Good

"Ledgerly — a budgeting app for freelancers. It connects to your bank, auto-categorizes income and expenses, and forecasts taxes owed. We just shipped onboarding and the dashboard; both are live and need fresh eyes before launch."

Not helpful

"My new app. Check it out and tell me what you think."

The Mission

Good

"Test the onboarding flow. Sign up with a new email, connect the demo bank (use credentials user / pass), and reach the dashboard. I want to know: where did you hesitate, did anything feel slow or unclear, and did the tax forecast make sense? Screenshot the step that confused you most."

Not helpful

"Just look around and find bugs."

A strong mission does three things: it scopes one focus area, it gives testers the steps and any credentials they need to get in, and it asks specific questions so the feedback comes back actionable.

Enforcement

Twnhall reserves the right to remove feedback, suspend missions, or terminate accounts that violate these guidelines. We don't issue warnings for serious violations — harassment, hate speech, and deliberate gaming of the system result in immediate removal.

Where a violation involves payment — bad-faith reviews, rating manipulation, or submitting work you didn't do — any unpaid balance on the account may be forfeited. Enforcement applies to the person, not just the account: if you hold both a Builder and a Tester account, a violation on one can cost you both.

If you encounter a violation — bad-faith feedback, abusive content, or a project that appears malicious — contact us at twnhallhq@gmail.com