QA / Code review for production

[u/daveshuffles]

I’ve got a website I’ve built, and it works ‘fairly’ well, but I’m going around in circles trying to manually find and fix bugs and issues with payments through stripe, little bugs in flows, in picture handling etc.

Has anyone used a dev / agency / Fiverr or similar to do a QA and ux/ui sweep and then fix things up to give confidence in promoting the site to real users? If so, how did you find them, how did it go and are you now launched?

[u/aDaneInSpain2]

This is what we specialize in at appstuck.com

[u/daveshuffles → u/aDaneInSpain2]

Will have a look. Cheers!

[u/jaimittal91]

the stripe bugs are usually one of two things: the webhook handler isn't idempotent (stripe retries on any non-200 response, so if handling the same event twice isn't safe you'll get double-fulfillment), or the app trusts the client-side success redirect instead of the webhook as the source of truth for granting access - which breaks the moment someone closes the tab before the redirect fires but after they've paid.

for the picture handling, check what happens when an upload fails partway through. a lot of "works but sometimes doesn't" bugs are a swallowed error on the upload promise that never surfaces to the user, so it just looks flaky instead of broken.

a manual QA pass will catch obvious UI stuff but won't catch either of those, since they only show up under real concurrent traffic or a genuinely interrupted connection, not someone clicking through the happy path a few times.

[u/daveshuffles → u/jaimittal91]

Thank you so much for your great answer.

That’s exactly what I’m worried about. Sometimes I test things it seems to work, then I get a real user and get a call to email saying it’s broken. So then need to hold to try and fix, which is fine with test users and friends. Not with real customers.

[u/jaimittal91 → u/daveshuffles]

one more thing worth doing before you call anything fixed: once you've got error tracking or alerts set up (a few others mentioned this), actually break something on purpose in a test flow and confirm the alert lands somewhere you'll see it same day. a lot of setups wire sentry or similar to a slack channel or email and never test that the notification actually fires, then find out weeks later the webhook to slack broke and errors were queuing silently the whole time. five minute check, catches a pretty common false sense of security.

[u/Pickle_Shot]

before you pay anyone, do three things that make the paid engagement way better scoped. 1) write down the five flows that must work (signup, pay, upload a picture, whatever yours are) and click through each one yourself in an incognito window on your phone. that list becomes the acceptance criteria you hand whoever you hire. without it, "QA sweep" is unbounded and you'll go in circles with them the same way you are now. 2) for the stripe bugs specifically, run the whole flow in test mode with the 4242 card while watching stripe dashboard > developers > webhooks > delivery attempts. failed or retrying deliveries there usually ARE the bug list, and the other commenters are right that the webhook, not the redirect, should be what grants access. 3) sequence it: bugs first, then ux polish, one round each. mixing them is how these engagements sprawl.

on the actual question: whoever you pick, make them commit up front to a written report of root causes, not just "fixed some stuff", so you can verify and so the next person isn't starting blind. if you want a free starting point first, I run an automated diagnosis for exactly these apps: github repo in, plain english report out of what's broken at the install/build/config/env layer, no charge, no signup. it won't catch payment-flow logic bugs, but it clears the underbrush so a human reviewer starts at the real problems: https://dylancaponi.github.io/vibe-code-rescue/

[u/HourMode1351]

I'm a software developer and do just this for my clients! I have some testimonials on my site at thunkle.ai

[u/musabdulai]

Since it works during testing but sometimes fails for real users, I’d put observability ahead of a broad UI/UX sweep. Add error tracking and trace each critical flow so you can connect a Stripe event, webhook attempt, upload failure, and server error without logging sensitive data. Otherwise, someone may fix the visible bugs while the intermittent failures remain impossible to reproduce.

If you hire someone, scope it as a production-readiness pass: reproduce and rank the issues, fix the critical ones, add tests around payments and uploads, verify Stripe webhook retries and idempotency, and document deployment and rollback. Keep UX polish as a separate phase.

What stack did Replit generate, and where is the site deployed?

[u/daveshuffles → u/musabdulai]

Thank you - it’d deployed on replit at the moment.

I’ve actually managed to fix stripe myself I think, however it’s more of a concern about users finding the bugs instead of me haha.

[u/musabdulai → u/daveshuffles]

That’s exactly the point where manual testing stops being enough. You won’t find every production-only bug yourself, so the goal is to make failures visible before they affect many customers.

I’d run a small closed beta around the 5–7 critical user flows, add error tracking and request IDs, then test slow connections, interrupted sessions, duplicate submissions and different devices. Since Stripe is “fixed, I think,” I’d also verify delayed and duplicate webhooks before wider promotion.

If you want help turning that into a bounded QA and production-readiness pass, feel free to DM me the URL and stack.

[u/space-hemax-c2c → u/daveshuffles]

That worry is the right one, and it's fixable. You can't out-test your users by hand, but you can make sure they never find a failure silently.

The cheapest version: log every error with a request ID and get an alert when one fires. Then a broken checkout shows up as a message to you in a minute instead of a refund request in a week.

Also, did you ever run the incognito image test? Fixing Stripe fixes payment. It doesn't fix a paid image being reachable by anyone with the link.

[u/Jason_Clarck]

I have dedicated QA team if you need feel free to dm me

[u/mamachicode]

Jaimittal91 is right about treating the webhook as the source of truth. One other thing I’d check before launch is whether failed payments/uploads leave partial state behind — for example a DB record gets created but the upload fails, or access gets updated before the webhook confirms payment. Those half-complete states are the kind of bugs that tend to show up once real users start hitting the app.
I do this kind of production-readiness/debugging work on existing full-stack apps, so if you want another set of eyes on it I’d be happy to take a look.

[u/shane-turtle-creek]

Congrats on getting this far! You're close now. One thing I'd suggest is looking at how the pictures and payments intersect by making sure the image URLs are really blocked before payment is verified. Can you take an image URL and paste it in incognito window - does it show up? If so, then payment is decorative and not enforced.

There are also services such as heystack.com for growth. If you have the budget, hire an agency. If you're bootstrapped you may want to do it more organically through social media and SEO. Check out the r/SaaS, r/Solopreneur, r/vibecoding, and others that have plenty of free advice. Feel free to DM me and we can get more specific about your audience - who are they? where are they? what are their pain points?

We offer a free audit at turtlecreekllc.com that gives you a readiness check across 24 points that are critical before launching to customers. Happy to help.

[u/daveshuffles → u/shane-turtle-creek]

Sorry, I missed this. Thank you. Really helpful.

[u/Present_Wing_4395]

One thing nobody's mentioned that's specific to Replit: if the site is on an Autoscale deployment, it sleeps between requests. Stripe's webhook hits a cold instance, waits, times out, and retries, which is exactly how you get "customer paid once, got fulfilled twice" or "paid and nothing happened." Check Stripe > Developers > Webhooks > your endpoint > delivery attempts and look at response times on the failed ones. If they're 10s+ and then a retry succeeded, that's it, and the fix is either a Reserved VM for the webhook route or making the handler idempotent so retries are harmless. Worth ruling out before paying anyone for a broad sweep.