React Native (Expo SDK 54) + Node/Postgres engineer - fix a defined backlog on two live apps

WHAT THIS IS SIPJOLT is an automated coffee-vending business. We operate machines in real locations that take real payments today. Around them sits a software stack: a customer mobile app for ordering and loyalty, and a fleet-operations app that technicians and drivers use on their phones to service the machines. Both apps are built and substantially working. Neither is finished. I'm hiring one contractor to take them the rest of the way. I want to be direct about something up front, because it changes who should apply: most of this codebase was written by AI coding agents over several months. It is not spaghetti - it has extensive test suites, documented architectural rules, and deliberate fail-closed behaviour in the payment and hardware paths. But it was written fast, by many sessions, and its true defect density is unknown. Several independent audits have found real bugs, and each audit finds more. This means the job is to inherit and verify, not to rewrite. If your instinct on seeing an unfamiliar codebase is "let me modernise this," we will not work well together. If your instinct is "let me read it, reproduce the bug, write a failing test, then fix the smallest thing," please keep reading. WHAT YOU'D ACTUALLY WORK ON 1. The customer app (React Native / Expo). Ordering, payments, loyalty, deep links, Apple Wallet passes. Working today; needs a defined list of defects closed and an Android internal build shipped so we can test on real devices. 2. The fleet-ops app (Node + React PWA). Used in the field on phones for station visits, replenishment, cleaning records with photo evidence, shipments, and incidents. It's live at a production URL and currently reports itself not-ready due to a notification-delivery issue. It needs its remaining publish blockers closed and a release actually shipped. This is not a discovery engagement. I have file-and-line findings from multiple audits - severity-ranked, with reproduction steps for many of them. Examples of the real work, so you know what you're getting into: - A top-up path where a customer's card is charged, the wallet row is missed, and the system reports success while consuming the idempotency key so it can never self-heal. - Cross-tenant data leakage on an operations endpoint where one operator sees another tenant's refill alerts. - A response sanitiser whose own tests fail on the pinned Node version. - Public API routes with no rate limiting. - An error-logging path that writes SQL and bound parameters into logs. You'd be working through a prioritised backlog like that, with tests, on branches, reviewed. THE STACK - EXACT VERSIONS, VERIFIED TODAY Customer app - Expo SDK 54.0.37, React Native 0.81.5, React 19.1.0 - JavaScript / JSX - not TypeScript (191 JS/JSX files, zero .ts or .tsx) - React Navigation 7, Zustand 5, Stripe React Native 0.66.0 - jest-expo for tests; EAS Build for releases; Node 20.19.4 or newer, below 27 Customer backend - Node 26.x, Express 5.2.1, Drizzle ORM 0.45.1, PostgreSQL (Neon), Stripe 20.4.1 - Jest 30; deployed on Railway Fleet-ops app - Backend: Node 22, Express 5.1.0, PostgreSQL with row-level security, multi-tenant - Frontend: React 19.2.0, Vite 7.2.4, Vitest 3.2.7, installable PWA - Deployed on Railway If you haven't shipped an Expo app through EAS to a store, or you haven't worked with Postgres row-level security, say so honestly in your proposal - I'd rather know. EXPLICITLY OUT OF SCOPE We also run software directly on the machines: Android controllers, serial protocols, vending payment hardware. None of that is part of this job. No firmware, no embedded Android, no hardware access, no site visits. I handle everything physical myself. If a task turns out to need the machine, it becomes mine, not yours. You will never be asked to do anything that can dispense a drink or move money on real hardware. HOW WE'D WORK Staged access, and I'll tell you why plainly: a previous contractor delivered a build containing a hardcoded backdoor and committed database credentials. So access is earned in steps - a paid trial task with no repository access, then read access, then write access on your own branches, then deploys. Nothing personal, and it moves quickly if the work is good. Paid trial task first. One real bug from our codebase, one file, no repo access and no credentials needed. It's a genuine defect with a known answer, so I can evaluate it fairly. Budget under an hour; I pay for it either way, at your rate. Then a defined first engagement: roughly 40-60 hours over 3-4 weeks, working the prioritised backlog on both apps, with a checkpoint at the halfway mark. If that goes well there's ongoing work; I'd rather build a long relationship than churn contractors. Rate: $40-60/hour depending on demonstrated depth in this specific stack. If you're outside that band and think you're worth it, make the case with specifics. Working style: async-friendly, any timezone. I need clear written updates more than I need overlapping hours. I read everything. WHO THIS IS RIGHT FOR - You've shipped React Native apps through EAS and know what a build profile is without looking it up. - You've worked on payment code and you think in terms of unknown outcomes, not just success and failure. - You're comfortable inheriting a large codebase you didn't write and don't fully trust. - You write tests that fail before your fix and pass after, without being asked. - You say "I don't know" when you don't know. WHO THIS IS WRONG FOR - Agencies who won't name the individual doing the work. - Anyone who opens with a proposal to rebuild, migrate, or modernise the stack. - Anyone who lists every technology in existence on their profile. - Anyone who needs a fully specified ticket to start. TO APPLY - ANSWER THESE THREE QUESTIONS I read every answer. Two lines each is plenty; I'm looking for specifics, not essays. Proposals that skip these get skipped. 1. Name a mobile app you shipped to a store using EAS Build. Which build profile did you use, and what's one thing you had to configure in eas.json or your app config that wasn't obvious the first time? 2. You inherit a codebase largely written by AI agents, with extensive tests and unknown defect density. What are your first three actions in week one - and what do you deliberately not do? 3. A payment request to your processor times out. You never learn whether the customer's card was charged. What does your code do in that moment, and what does the customer see? Tell me your availability over the next month and anything above you'd push back on.