Nick Ayoola

• Back

Q4U: A two-sided queue marketplace, built solo with React Native & Expo

Q4U lets people pay a nearby "queuer" to physically hold their place in a line, and pays that queuer out automatically when the handoff is done. A complete two-sided marketplace with real payments, identity verification, and live location, built from scratch for iOS and Android from a single codebase.

Overview

Waiting in line is one of the last chores you can't outsource. Q4U fixes that: Requesters post a paid request to have their place held; nearby Queuers accept the job, hold the spot, and hand it over in person, verified by a QR code, with payment captured and paid out automatically on completion.I designed and built the entire product end to end: the mobile app, the backend, the payments and payout rails, identity verification, and the full store submission, and I now run it in production.

My role

Sole developer & product owner: product design, UI, React Native app, Supabase backend & database, Stripe payments + payouts, phone & identity verification, push notifications, observability, and iOS/Android release engineering with EAS.

Tech stack

Overview

1. Escrow-style payments and automated payoutsMoney is the hard part of any marketplace. I used Stripe manual-capture payment intents to hold a requester's funds when they post a job, then capture on completion, an escrow-like flow that protects both sides. On handoff, an Edge Function captures the payment and uses Stripe Connect (separate charges & transfers) to pay the queuer's share, keeping the platform fee, then Stripe pays out to their bank automatically.The subtle part was the onboarding return flow: Stripe only accepts http(s) return URLs and rejects custom app schemes. I solved it with an https redirect Edge Function that 302s back into the app via a deep link, plus an Expo Router +native-intent rewrite so the user lands exactly where they left off.Outcome: a full hold → capture → transfer → payout pipeline running on live Stripe (validated end-to-end in sandbox first).2. Debugging an auth deadlock that froze the whole appScreens would spin forever and user data wouldn't load after re-login. The cause was subtle: awaiting a Supabase query inside the onAuthStateChange callback held the auth client's lock and deadlocked every subsequent request. Deferring the profile fetch out of the callback fixed it instantly.Outcome: a class of "random freezes" eliminated, the kind of bug that only gets solved by understanding why, not just retrying.3. Native platform quirks: keyboards & builds

Outcome: clean builds and a polished, native-feeling UX on both platforms.4. Trust & safety on a two-sided marketplaceStrangers meet in person and money changes hands, so trust matters. I built:

5. Offline resilience, and knowing where to stopOpening the app with no connection showed a long black screen and a blank profile. The root cause was startup network calls that hung with no timeout. I fixed it in layers: a global fetch timeout so offline calls fail fast, a branded loading state instead of a blank screen, a persisted profile so the name renders instantly from cache on cold start, and recoverable "can't load" states.The decision I'm most pleased with is where I stopped: I deliberately did not go full offline-first. In a realtime payments marketplace, stale data actively misleads (a job cached as "active" might really be completed), so the rule is cache for display continuity, always revalidate, and never let a user take a money action on stale data.Outcome: a fast, legible cold start offline, and a defensible boundary on how far to take caching.6. Shipping and operating in productionBuilding it was half the job; taking it live and keeping it healthy was the other.

Outcome: shipped solo to both stores, and the ability to diagnose and fix a production issue in minutes rather than a release cycle.

What I shipped

What I shipped

Building a marketplace solo meant owning every layer, from a Postgres RLS policy to a Stripe webhook to an iOS provisioning profile to a live-crash hotfix. The biggest lessons were in the unglamorous parts: payments edge cases, auth races, native platform differences, and the store-submission and operations work that turns a build into a shipped product. I lean on modern tooling, including AI pair-programming, to move quickly, but every architecture decision, integration, and bug fix went through my own understanding and testing. That's how I shipped it solo to both app stores and kept it running in production.Status: Live on iOS, available on the App Store. Android release pending Play Store review.

Available for React Native / Expo freelance work.
Nick Ayoola · Email · LinkedIn

• Back

Turning a daily hunt through car adverts into an automated sourcing pipeline

Built with Next.js, .NET & a Python OCR microservice on Azure
Position One Motor Company used to source vehicles by hand every morning: trawling AutoTrader, copying advert details, looking up each registration in a second system for history and valuation, then re-keying everything into a Google Sheet. I replaced the whole routine with a three-part system that scrapes the listings, reads number plates from vehicle photos, enriches each record from external services, stores it in PostgreSQL, and keeps their Google Sheet up to date on its own, every hour.Status: Live in production. Runs an automated hourly pipeline for the client, powered up and down on a schedule to keep cloud costs near zero. Designed and built solo.

Built with Next.js, .NET & a Python OCR microservice on Azure
Position One Motor Company used to source vehicles by hand every morning: trawling AutoTrader, copying advert details, looking up each registration in a second system for history and valuation, then re-keying everything into a Google Sheet. I replaced the whole routine with a three-part system that scrapes the listings, reads number plates from vehicle photos, enriches each record from external services, stores it in PostgreSQL, and keeps their Google Sheet up to date on its own, every hour.Status: Live in production. Runs an automated hourly pipeline for the client, powered up and down on a schedule to keep cloud costs near zero. Designed and built solo.

My role

Sole developer & product owner: architecture, the Next.js dashboard, the .NET backend and data model, the Python OCR microservice, PostgreSQL/EF Core, Google Sheets integration, JWT authentication, and the full Azure deployment, automation, and cost engineering.

My role

Sole developer & product owner: architecture, the Next.js dashboard, the .NET backend and data model, the Python OCR microservice, PostgreSQL/EF Core, Google Sheets integration, JWT authentication, and the full Azure deployment, automation, and cost engineering.

Tech stack

Key challenges

1. On-demand computer vision without paying for idle computeThe vision model is the heaviest thing in the stack, yet it only needs to run for a few minutes an hour. Keeping a GPU-class container warm all day would have dominated the running cost. I ran the OCR service on Azure Container Apps scaled to zero, and drove it from an Azure Logic App that, every hour between 9am and 7pm, starts the container, waits for it to warm, triggers the scrape, waits for the run to finish, then shuts it back down. The start/stop calls hit Azure's management API using a Managed Identity, so the most privileged part of the system holds no stored secrets.
Outcome: full computer-vision enrichment on demand, with the OCR container billing essentially nothing between runs.2. Reading the plates the model gets wrong, rightNumber plates in photos are small, angled, and dirty, and raw OCR routinely confuses O/0 and I/L/1. I built a two-stage reader: YOLOv8 locates and crops the plate, then PaddleOCR reads it, then a correction pass uses the fixed UK plate layout to disambiguate each character by position rather than guessing. Where a reading is still ambiguous, I expand the plausible candidates and validate them against the downstream lookup, taking the first that resolves to a real registered vehicle.
Outcome: near-miss reads like "L1 OO1" get turned back into valid registrations instead of dead lookups, so the enrichment step actually fires.3. A data-import pipeline that's safe to run, safe to rerun, and testableThe endpoint that imports car records into the pipeline was risky to run blindly, it could reprocess the whole dataset or write bad data, and I needed to be able to exercise it without side effects. I built three habits into it. Input validation with clear error responses, so bad requests fail fast and legibly. A dry-run mode that reports exactly what a run would do without writing anything, which I drove through Postman to verify behaviour safely. And incremental processing via a marker/cursor: the run records how far it got, so a rerun only picks up records past that marker instead of starting over, on top of the scrape itself stopping at the first advert it has already stored.
Outcome: an idempotent, incremental import, no full reprocessing, no accidental writes during testing, and clear failures on bad input.4. The boundary between my code and the databaseEF Core turns LINQ into SQL and only supports a subset of .NET methods; get it wrong and a query either throws or silently drags rows into memory to evaluate client-side. Two bugs lived right on that seam:

Outcome: queries execute at the database level where they should, and timestamps store and read back with correct timezone semantics, two commonly-botched areas, fixed at the source rather than papered over.5. Credentials that load correctly in every environmentWe authenticated to Google Sheets with a service account, but the credentials lived differently in each environment: a file path locally, raw JSON on Azure. That's exactly the kind of split that produces environment-specific "works on my machine" deployment bugs. I refactored credential loading into a shared utility that detects whether the env var holds raw JSON or a file path, validates it, fails with a clear error when it's missing or malformed, and is centralised so every service that needs it reuses the same logic.Outcome: deployments stopped carrying environment-specific credential bugs, and standing the system up in a new environment got noticeably less fiddly, the robust path instead of the brittle one.6. Shipping and operating it in productionBuilding it was half the job; keeping it running and cheap was the other. Three runtimes, three deployment models: a Node/Next.js dashboard and a .NET API on App Service, and a Python container on Container Apps behind its own registry, wired together with JWT auth, environment-injected secrets, and a Neon-hosted Postgres. Beyond the hourly OCR cycle, a second pair of Logic Apps starts the front and back-end servers in the morning and stops them in the evening, so nothing bills overnight. When a run misbehaves, I diagnose it from the Container App console logs and redeploy the affected service on its own, without touching the rest.Outcome: a production system I can operate and cost-tune day to day, running a manual daily chore entirely on its own.

What I shipped

Reflection

Automating this workflow meant owning every layer, from a YOLO crop and an OCR correction rule, to an EF Core migration, to a Google Sheets append, to a Logic App that starts a container with a Managed Identity token. As with most real systems, the biggest lessons were in the unglamorous parts: what an ORM can and can't push to the database, getting timezone types right across a boundary, loading credentials the same way in every environment, and making reruns safe by default. I lean on modern tooling, including AI pair-programming, to move quickly, but every architecture decision, integration, and bug fix went through my own understanding and testing. That's how a chore someone used to do by hand every morning became a system that just runs.

Status: Live in production for Position One Motor Company.
Available for full-stack / cloud automation freelance work.Nick Ayoola · Email · LinkedIn