Ongoing Beta Tester for New Web Apps — 2 to 4 New Builds Every Month (Monthly Retainer)
Budget / Salary$750–1,500
TypeFreelance project
LocationRemote
Posted1 hour ago
Type: Ongoing / long-term. Not a one-time project. Pay: $900–$1,400 fixed monthly. No hourly billing. Most important thing: Obsessive attention to detail. Coding experience is not required; catching what everyone else missed is. Availability: Los Angeles business hours (Pacific Time). Location doesn't matter, but if you can't work a Pacific Time schedule, please don't apply. Video calls: You'll sit in on some of my client calls, camera on. Non-negotiable.
What this is
I run a small studio shipping new web applications constantly — two to four brand new apps a month, plus updates to the ones already live. Each needs a fast, thorough beta test before it reaches a client.
I'm not looking for someone to go deep on one product for six months. I need someone who can pick up an app they've never seen, figure out what it's supposed to do, and break it within a day or two — with very little direction from me. Then do it again next week with a different app.
If you like variety and you instinctively click the button twice, submit the empty form, and paste an emoji into the name field, this is a good fit.
The stack
React + TypeScript, Vite, Tailwind. GitHub is the source of truth — all code is written and pushed there, with a two-way sync to Lovable, which I use only for database changes and migrations. Supabase for database, auth, and edge functions. Deployed to Vercel or Railway, so you'll always get a live preview URL. Some builds are Shopify apps, some internal tools, some client-facing sites.
You don't need to be a developer. If you can use Claude or ChatGPT to help you read code and figure out what's going wrong, that's enough.
What I can't teach is attention to detail, and that's the whole job. Noticing the date that shows as 03/04 in one place and March 4th in another. The typo in an error message. The field that accepts a negative number. That the client said something on a call that doesn't match what the app does. Writing a bug report where every step is right, so it reproduces on my machine the first time. If you skim, this won't work.
Client calls
You'll join some of my client calls on video, camera on, taking your own notes. Usually 30–60 minutes, during LA hours. The point is that you hear what the client wants directly instead of me relaying it afterward — you'll get more from ten minutes on the call than from anything I could write up later.
You're there to listen, not present. Be presentable on camera, have a working mic and a quiet space, and speak English clearly enough to follow the conversation and ask a question when something's unclear. If you'd rather not be on video with clients, this isn't the role.
How we'll work
I don't hand out test scripts. I hand you an area and walk away.
A typical assignment from me is one sentence: "Go through everything a salesperson touches in this app and make sure it works." From there you figure out what a salesperson actually does, what screens they hit, what could break, and you test all of it without checking in at every step. If something's ambiguous, make a reasonable call and note the assumption. Don't sit waiting on an answer.
If you need constant direction, this won't work.
What each round looks like
1. I send a link and an area to focus on. Sometimes a Loom walkthrough, sometimes one sentence.
2. Test as every role, not just as admin. This is the most important instruction here. Most of my apps have roles — admin, manager, salesperson, dispatcher, viewer — and what a user can see and do changes per role. The worst bugs exist for only one of them. I'll give you a login for each. A bug that only breaks for salespeople is invisible from an admin account, and those are exactly the ones that reach a client.
3. Never trust a success message. The most common bug in my apps is a "Saved!" toast over a save that didn't happen — the UI says it worked, the database never got the write, no error anywhere. The only way to catch it is to save, reload the page, and confirm the change stuck. Every time. If your report says something saves correctly and it doesn't, that's the failure that costs me real money.
4. Check whether it's already there. A lot of what gets reported to me as "this feature is missing" turns out to exist, just buried behind an icon or a toggle nobody found. Before filing something as missing, look for it. If it took you a while, that's still worth telling me — but as "hard to find," not "doesn't exist." Different problem, different fix.
5. Cover the rest. Every screen, button, route, and menu in scope. Broken routes, dead links, menu items pointing to the wrong place, back-button behavior, deep links. Forms, empty states, error states, mobile layout. Chrome, Firefox, and Safari on desktop, plus mobile Safari and Chrome on Android.
6. Turnaround beats exhaustiveness. First pass back within 24–48 hours. I'd rather have the top fifteen problems tomorrow than a forty-page report next week.
7. Log everything in GitHub Issues. Severity (blocker / major / minor / cosmetic), which role it happens for, exact repro steps, expected vs. actual, browser + OS + screen size, screenshot or short recording. Loom is fine.
8. Light code review. You'll have repo access on most projects. You don't need to read code unaided — paste the diff into Claude and ask what looks wrong, then use judgment on what's worth raising. Hardcoded keys, broken logic, missing error handling, dead code. You don't have to be certain or right every time.
What I'll give you
A live preview URL, a login for every role in the system, and an account loaded with realistic test data. You'll never be pointed at an empty database — half these screens look perfectly fine with no rows in them, and testing against blank tables tells neither of us anything.
Reports — keep them short
I don't want long AI-generated write-ups with headers and padding. I can spot those instantly. Every report answers three things in plain language: what you worked on, what's broken (with links to the issues), and what you did about it. A few lines each. Bullet lists of bugs are fine — it's the narrative padding around them I don't want.
Once a month, add one line on recurring problems you're seeing across different builds. You'll spot patterns across twenty apps that I won't.
AI tools
Use Claude or ChatGPT freely — to understand an unfamiliar app, read code you don't follow, diagnose a problem, or draft a suggested fix. I use them constantly.
The hard line: AI doesn't do the testing. The clicking has to be a real person on a real browser, and every bug you file has to be something you reproduced yourself. Don't file bugs an AI told you might exist.
And sanity-check what it tells you. These tools invent confident explanations for problems that aren't there. If you pass along a guess as fact and I chase it for an hour, that's worse than you saying "something's broken here, I'm not sure why."
What success looks like
First-pass test back within 48 hours of me sending the link.
Every role tested, not just admin.
Nothing reported as "saved" that didn't save — you verified by refreshing.
Broken navigation and dead routes never reach a client.
Every bug reproducible from your report alone. If I can't reproduce it, it comes back to you.
To apply
Keep it short. Include:
Your monthly rate within the range above, and confirmation you can commit for at least three months.
Roughly how many separate applications you've tested in the past year — breadth matters more than depth here.
Which of these you've used, if any: React apps, Supabase, Vercel preview links, GitHub Issues, Loom, Claude or ChatGPT for technical work. A short list is fine.
Your location, and confirmation you can work Pacific hours and be on video with clients.
One bug you found that a developer missed, and how you found it. Three to five sentences.
What you'd actually go test if I said "make sure everything the salespeople use is working." A few lines. I'm checking how you think.
Pick any app you use often and tell me one small thing wrong with it that most people never notice. One or two sentences. This is the question I care most about.
Start your proposal with the word NAVIGATION so I know you read this.
If you think this is more work than the budget supports, say so and tell me what you'd cut. First month is a paid trial; after that the retainer renews monthly with no end date.
What this is
I run a small studio shipping new web applications constantly — two to four brand new apps a month, plus updates to the ones already live. Each needs a fast, thorough beta test before it reaches a client.
I'm not looking for someone to go deep on one product for six months. I need someone who can pick up an app they've never seen, figure out what it's supposed to do, and break it within a day or two — with very little direction from me. Then do it again next week with a different app.
If you like variety and you instinctively click the button twice, submit the empty form, and paste an emoji into the name field, this is a good fit.
The stack
React + TypeScript, Vite, Tailwind. GitHub is the source of truth — all code is written and pushed there, with a two-way sync to Lovable, which I use only for database changes and migrations. Supabase for database, auth, and edge functions. Deployed to Vercel or Railway, so you'll always get a live preview URL. Some builds are Shopify apps, some internal tools, some client-facing sites.
You don't need to be a developer. If you can use Claude or ChatGPT to help you read code and figure out what's going wrong, that's enough.
What I can't teach is attention to detail, and that's the whole job. Noticing the date that shows as 03/04 in one place and March 4th in another. The typo in an error message. The field that accepts a negative number. That the client said something on a call that doesn't match what the app does. Writing a bug report where every step is right, so it reproduces on my machine the first time. If you skim, this won't work.
Client calls
You'll join some of my client calls on video, camera on, taking your own notes. Usually 30–60 minutes, during LA hours. The point is that you hear what the client wants directly instead of me relaying it afterward — you'll get more from ten minutes on the call than from anything I could write up later.
You're there to listen, not present. Be presentable on camera, have a working mic and a quiet space, and speak English clearly enough to follow the conversation and ask a question when something's unclear. If you'd rather not be on video with clients, this isn't the role.
How we'll work
I don't hand out test scripts. I hand you an area and walk away.
A typical assignment from me is one sentence: "Go through everything a salesperson touches in this app and make sure it works." From there you figure out what a salesperson actually does, what screens they hit, what could break, and you test all of it without checking in at every step. If something's ambiguous, make a reasonable call and note the assumption. Don't sit waiting on an answer.
If you need constant direction, this won't work.
What each round looks like
1. I send a link and an area to focus on. Sometimes a Loom walkthrough, sometimes one sentence.
2. Test as every role, not just as admin. This is the most important instruction here. Most of my apps have roles — admin, manager, salesperson, dispatcher, viewer — and what a user can see and do changes per role. The worst bugs exist for only one of them. I'll give you a login for each. A bug that only breaks for salespeople is invisible from an admin account, and those are exactly the ones that reach a client.
3. Never trust a success message. The most common bug in my apps is a "Saved!" toast over a save that didn't happen — the UI says it worked, the database never got the write, no error anywhere. The only way to catch it is to save, reload the page, and confirm the change stuck. Every time. If your report says something saves correctly and it doesn't, that's the failure that costs me real money.
4. Check whether it's already there. A lot of what gets reported to me as "this feature is missing" turns out to exist, just buried behind an icon or a toggle nobody found. Before filing something as missing, look for it. If it took you a while, that's still worth telling me — but as "hard to find," not "doesn't exist." Different problem, different fix.
5. Cover the rest. Every screen, button, route, and menu in scope. Broken routes, dead links, menu items pointing to the wrong place, back-button behavior, deep links. Forms, empty states, error states, mobile layout. Chrome, Firefox, and Safari on desktop, plus mobile Safari and Chrome on Android.
6. Turnaround beats exhaustiveness. First pass back within 24–48 hours. I'd rather have the top fifteen problems tomorrow than a forty-page report next week.
7. Log everything in GitHub Issues. Severity (blocker / major / minor / cosmetic), which role it happens for, exact repro steps, expected vs. actual, browser + OS + screen size, screenshot or short recording. Loom is fine.
8. Light code review. You'll have repo access on most projects. You don't need to read code unaided — paste the diff into Claude and ask what looks wrong, then use judgment on what's worth raising. Hardcoded keys, broken logic, missing error handling, dead code. You don't have to be certain or right every time.
What I'll give you
A live preview URL, a login for every role in the system, and an account loaded with realistic test data. You'll never be pointed at an empty database — half these screens look perfectly fine with no rows in them, and testing against blank tables tells neither of us anything.
Reports — keep them short
I don't want long AI-generated write-ups with headers and padding. I can spot those instantly. Every report answers three things in plain language: what you worked on, what's broken (with links to the issues), and what you did about it. A few lines each. Bullet lists of bugs are fine — it's the narrative padding around them I don't want.
Once a month, add one line on recurring problems you're seeing across different builds. You'll spot patterns across twenty apps that I won't.
AI tools
Use Claude or ChatGPT freely — to understand an unfamiliar app, read code you don't follow, diagnose a problem, or draft a suggested fix. I use them constantly.
The hard line: AI doesn't do the testing. The clicking has to be a real person on a real browser, and every bug you file has to be something you reproduced yourself. Don't file bugs an AI told you might exist.
And sanity-check what it tells you. These tools invent confident explanations for problems that aren't there. If you pass along a guess as fact and I chase it for an hour, that's worse than you saying "something's broken here, I'm not sure why."
What success looks like
First-pass test back within 48 hours of me sending the link.
Every role tested, not just admin.
Nothing reported as "saved" that didn't save — you verified by refreshing.
Broken navigation and dead routes never reach a client.
Every bug reproducible from your report alone. If I can't reproduce it, it comes back to you.
To apply
Keep it short. Include:
Your monthly rate within the range above, and confirmation you can commit for at least three months.
Roughly how many separate applications you've tested in the past year — breadth matters more than depth here.
Which of these you've used, if any: React apps, Supabase, Vercel preview links, GitHub Issues, Loom, Claude or ChatGPT for technical work. A short list is fine.
Your location, and confirmation you can work Pacific hours and be on video with clients.
One bug you found that a developer missed, and how you found it. Three to five sentences.
What you'd actually go test if I said "make sure everything the salespeople use is working." A few lines. I'm checking how you think.
Pick any app you use often and tell me one small thing wrong with it that most people never notice. One or two sentences. This is the question I care most about.
Start your proposal with the word NAVIGATION so I know you read this.
If you think this is more work than the budget supports, say so and tell me what you'd cut. First month is a paid trial; after that the retainer renews monthly with no end date.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.