Build a standalone survey rewards portal (web app, not WordPress)

For reference - see html design and wireframe attached which includes all design, and outlines all the front end functionality needed We need a logged-in rewards portal built as a standalone web app. The users are survey panelists. They log in, see the surveys they've completed and what their balance is, and cash out either as a prepaid Visa card or as a donation to a charity they pick. Once a week the site owner uploads a CSV that updates everyone's completed surveys and balances. She also needs a plain admin view showing which payouts she needs to fulfill. We already have a complete HTML prototype of every screen, so the design work is done. We'll share it with shortlisted candidates. What we need is the build. Heads up: we posted this earlier as a WordPress project and we've changed direction. We do not want this built in WordPress, and we're not looking for a WordPress plugin or a membership-plugin setup. Build it as its own app with its own auth, database, and admin area. It will live on a subdomain and we'll link to it from our main marketing site. No integration with the existing site is required beyond that link. Scale is small. About [X] panelists today, low thousands at most. This does not need to be architected for scale, it needs to be simple, correct, and easy for someone else to maintain later. Tech approach we expect Pick a stack you're genuinely fast in. We're not precious about the choice, but we want boring and maintainable over clever. What we're looking for: A mainstream web framework with a relational database. Next.js + Postgres, Laravel + MySQL, Rails + Postgres, and Django + Postgres are all fine. Tell us what you'd use and why. A proven auth library or service for login, sessions, and password reset. Do not hand-roll authentication or password hashing. Deployed on something managed and simple, with automated database backups. Render, Fly, Railway, Vercel with managed Postgres, or DigitalOcean App Platform all work. Tell us the expected monthly hosting cost. Custom code where it actually belongs: the rewards ledger, the weekly import, the redemption flow, and the admin screens. Source in a Git repo we own, with a README a future developer can follow to run it locally and deploy it. No payment gateway. The owner fulfills gift cards and donations manually outside the system. The app records the request and emails her what to do. The input file, read this part carefully This is where bidders had the most questions last time, so here is exactly what we get. One CSV per week, in wide format. The columns are: panelist ID, name, email, then one column for every survey. Each survey column is named after the survey. The cell holds the dollar value that panelist earned for that specific survey. Values are not uniform, some surveys are worth $5.00 and some are worth $2.00. A blank cell means that panelist didn't complete that survey. Things that follow from that format: The survey column header is the survey name. That's how the dashboard gets survey names, so no separate lookup is needed. New survey columns get added over time as new surveys run. The importer has to handle new column names on its own, without a code change or a manual field-mapping step every week. The file is cumulative. Last week's surveys are still in this week's file with the same values. The import has to be idempotent, so uploading the same file twice, or a file that repeats prior surveys, must never double-count. Treat panelist plus survey column as the unique key. Balance is derived from the survey records, never typed in or carried in the file. Available balance is the sum of that panelist's survey values that haven't been redeemed yet. The import needs a preview and confirm step before it writes anything, with plain counts on screen: how many panelists matched, how many new surveys were added, how many rows were skipped and why. A non-technical person has to run this alone every week without calling anyone. We'll give you a real sample file in her actual format. Rewards rules Each survey is worth whatever value sits in its CSV cell. There is no flat per-survey rate. Minimum redemption is $20.00 in available balance. Redemption is all or nothing. The user cashes out their full available balance. After redeeming, available balance resets to $0.00. Lifetime earned and individual survey history stay intact. Cash total plus charity total plus current balance should always equal lifetime earned. Build that as a check we can run, not just an assumption. One note on the prototype: it shows every survey at a flat $5.00 and describes the $20 minimum as four surveys. Ignore that. Show the real value for each survey and treat the minimum as a dollar threshold, since four surveys might only be $8.00. Screens to build All of these exist in the prototype. Match the design and make it responsive. Login. Email, password, keep me signed in, forgot password link. Forgot password. Email field, reset link that expires in 30 minutes, confirmation screen, resend option, support email fallback. Dashboard. Header with the panelist ID and an account dropdown (profile, dashboard, log out). Then: A greeting line that changes depending on whether the user is above or below the redemption threshold Three stats: surveys completed, lifetime earned, available to redeem Progress bar toward the $20.00 minimum with a status badge Two buttons, redeem for cash and donate to charity, disabled below $20.00 List of completed surveys, newest first, each showing its own dollar value and tagged available or redeemed Account totals: redeemed for cash, donated to charity, current balance Redemption history list with an empty state Two static info cards Redeem for cash modal. Confirms the full balance, shows the prepaid Visa option, shows the destination email, confirm and cancel. Donate to charity modal. Pick one of four organizations, each with a short description. Donate button stays disabled until one is selected. Confirmation modal. Separate copy for cash versus donation, confirms the balance is back to $0.00. Profile page. First name, last name, email, mobile, street, apartment or unit (optional), city, state dropdown, ZIP, current password, new password. Save and cancel, plus an unsubscribe link. Admin area The owner logs in and needs three things. Keep it plain, this needs no design work. Weekly CSV upload with the preview and confirm step described above, plus a log of past imports. A panelist list with balances, surveys completed, and lifetime earned, searchable by name or email. A redemption queue she can mark as fulfilled, showing type, amount, charity or card, panelist, address, and date. Data to store Per panelist: panelist ID, name, email, mobile, mailing address, join date, and account status. Per survey record: panelist, survey name, value, completion date, and redeemed or available state. Per redemption: type, amount, charity or card, date, and fulfillment status. Surveys completed, current balance, lifetime earned, total cash, and total donated should all be derived from those records rather than stored as editable fields. Emails Password reset Redemption confirmation to the panelist, with a separate version for donation receipts Notification to the owner with what to fulfill and for whom Optional welcome or set-your-password email if panelists are bulk imported Tell us what you'd use to send them and the monthly cost. Security basics We're storing names, emails, phone numbers, and mailing addresses, so we care about the basics. HTTPS, hashed passwords, rate limiting on login and password reset, no PII in logs, admin routes locked down separately from panelist accounts, and daily database backups. No card or bank data is ever stored. Questions to answer in your proposal You don't need firm answers from us to bid. Tell us how you'd handle each one and price around your assumptions. The CSV may not include a completion date per survey. How would you date individual survey records? What should happen when the CSV has an email that isn't in the system, create the account or skip and report it? Describe your exact approach to preventing a duplicate or cumulative upload from double-counting. What happens if a cell value changes between weeks, for example a typo correction, and that survey has already been redeemed? How would you get existing panelists into the system, one-time bulk import or self-registration, and how do they set a password the first time? Would you make the charity list admin-editable or hardcode it for phase one? What would you cut from phase one to keep the first build lean? What we'll provide The full HTML prototype for every screen A real sample CSV in the owner's actual weekly format Fonts and colors, already in the prototype A subdomain, DNS access, and whatever hosting account you recommend The charity list and email copy What to include in your proposal Fixed price, broken out by piece if you can Timeline and when you can start Your proposed stack, hosting, and any paid services, with monthly running cost Two or three similar builds you've done, ideally with user accounts, custom user data, or CSV imports Anything you'd cut from phase one How code ownership and handoff work, and what post-launch support you'd offer