// 00 · Prepared for Dayanara · Phoenix, Arizona
An Uber for Phoenix dump trucks.
A two-sided marketplace that connects dump truck operators with contractors, builders and landscapers in real time — on-demand dispatch, live GPS tracking, and Stripe-escrowed payments. Purpose-built for Phoenix.
2.4B
Phoenix construction spend (2025)
3
Apps — driver, customer, admin
24h
Driver payment on job complete
// 01 · Executive Context
Phoenix is building faster than its dispatch model can keep up.
The Phoenix metropolitan area is in the middle of an unprecedented industrial and infrastructure build-out. TSMC Fab 1 and 2, Intel Ocotillo expansion, the I-10 widening and SR-202 extensions are generating localized, sustained demand for dump truck loads — dirt, gravel, demo, aggregate — at a pace the phone-and-paper dispatch model cannot keep up with.
The mental model is right: this market needs an Uber-style marketplace for dump trucks — truck owners on the supply side, contractors, builders and landscapers on the demand side, matched in real time. Iron Sheepdog proved the model works in the Southeast US. Trux built a similar engine in the Northeast. Neither operates in Phoenix. Uber Freight is built for enterprise long-haul, not local loads. The window in Arizona is open today.
The product is three apps talking to one backend: a driver app where operators accept or decline jobs, a customer app where contractors request a truck and a material, and an admin dashboard where dispatch, approvals, pricing and disputes are managed. A matching engine in the middle. Stripe escrow underneath. That is the whole system.
Market Drivers
Population Growth
TSMC · Intel Demand
Infra Build-Out
Labor Scarcity
// 02 · What Breaks Today
Three points of friction quietly bleeding margin.
3.2 hrs
Daily dispatch waste
Brokers spend hours on the phone calling drivers to check availability, negotiate rates and verify location. No real-time visibility, no dynamic matching.
67 days
Average driver settlement
Drivers operate on thin margins. Forcing them to wait 60+ days for payment creates cash flow crises — they leave for brokers who can pay faster.
0%
Real-time truck visibility
Contractors have no map, no ETA, no confirmation the truck arrived. Every status update is a phone call. Every dispute is a he-said-she-said.
// 03 · Three Apps, One Platform
A driver app, a customer app, and an admin dashboard.
Driver App
iOS + Android · React Native
- check Accept or decline jobs
- check Live GPS tracking
- check Job history
- check Earnings dashboard
- check Upload tickets (proof of delivery)
Customer App
iOS + Android · React Native
- check Request a truck / load
- check Set material type (dirt, gravel, demo)
- check Real-time tracking
- check Pricing estimate up front
- check Payment + receipts
Admin Dashboard
Web · React
- check Dispatch oversight
- check Driver approvals
- check Pricing control
- check Dispute resolution
- check Analytics
One API. Six services. The matching engine is the secret sauce.
Mobile apps and the web dashboard all talk to a single API gateway. Behind it, six services each do one job well. The matching engine sits at the center — it looks at location, truck type, and availability, then routes each job to the closest available driver with surge pricing when supply tightens.
User Service
JWT auth, driver vs contractor roles
Matching Engine
Closest truck, priority drivers, surge pricing
Job Service
Requested → accepted → in progress → completed
Payment Service
Stripe escrow · funds held until job complete
Notifications
Firebase Cloud Messaging for push alerts
GPS / Tracking
Google Maps API · live driver locations
Matching Engine — the secret sauce
Every request is scored by location, truck type and availability. The closest available truck is notified first; if they pass, it cascades to the next. Priority drivers jump the queue, surge pricing fires when demand outstrips supply in a zone. First to accept wins the job.
Data & Security
PostgreSQL is the system of record — users, jobs, payments, ratings. Redis holds the hot real-time state: live driver locations and active job states. Amazon S3 stores load tickets, driver documents and images. JWT authentication, SSL on every request, role-based access between driver and contractor scopes, and Stripe handling PCI end-to-end.
From truck request to driver paid — eight steps, no phone calls.
This is what happens every time a contractor taps "Request a truck." The full loop — match, accept, track, complete, pay, rate — runs on its own. Dispatch only sees the exceptions.
Contractor requests a truck
Customer app: pickup, drop-off, material type (dirt, gravel, demo), and a live pricing estimate.
Request hits the API
The API gateway authenticates, validates and routes the request to the matching engine.
Matching engine finds nearest drivers
Location, truck type and availability are scored in Redis against live driver locations.
Drivers get a push notification
Firebase Cloud Messaging pings qualified drivers with job details and a live countdown.
First to accept gets the job
The job locks to that driver. Stripe holds the contractor's payment in escrow.
GPS tracking begins
Live location streams on the customer map. ETA updates in real time until delivery.
Job completes, payment released
Driver uploads the ticket (S3), confirms delivery, Stripe releases escrowed funds to the driver.
Rating submitted
Contractor rates the driver, driver rates the contractor. Reputation is built into the marketplace.
Escrow holds the money. Ratings hold the network together.
Stripe sits between the contractor and the driver. Funds are held in escrow the moment a job is accepted and released the moment it completes — no waiting on invoices, no chasing payment. Two-way ratings build the trust layer that makes the marketplace self-regulating.
Stripe Escrow
Funds are captured when the job is accepted and held until the driver confirms delivery. Contractor is protected. Driver gets paid the moment the job is done.
Two-Way Ratings
Contractors rate drivers and drivers rate contractors. Reputation lives in Postgres and feeds back into the matching engine — the best drivers see the best jobs first.
Transparent Pricing
Contractors see a pricing estimate before they confirm. Surge pricing fires when a zone runs short on trucks — incentive for drivers, transparency for contractors.
The model works. It just does not work in Phoenix yet.
The "Uber for dump trucks" thesis has already been validated by regional players in other parts of the country. None of them operate in Phoenix. Uber Freight exists but plays a different game — enterprise long-haul, not local loads. That leaves the fastest-growing construction market in the US without a native marketplace.
Long-haul OTR freight for enterprise shippers. Built for national logistics and big trailers, not local dump truck loads. Different customer, different trip, different app.
The proof point. Dump truck marketplace operating in the Southeast US (Carolinas, Georgia, Virginia). Validates the thesis at scale. Does not operate in Phoenix.
Construction freight platform concentrated in the Northeast. Same marketplace thesis, different geography. Second proof that the model retains drivers and contractors at scale.
Built for Phoenix from day one. Driver app, customer app, admin dashboard, matching engine, Stripe escrow. Lean, boutique team — no distractions, shipped as spec'd.
The thesis is not unproven — Iron Sheepdog and Trux removed the category risk. What is unsolved is Phoenix. The two incumbents are regional operators whose expansion priorities are adjacent geographies. The time to own Phoenix is before they decide to fly west.
Pay the kickoff. MVP ships in 56–84 days.
Two phases. Phase 1 starts the moment the kickoff payment clears — not before, not on credit — and delivers a lean Phoenix MVP in 56–84 days: one monolithic Node.js backend, Postgres, Firebase, Stripe, Google Maps, three apps in production. Phase 2 is triggered only once the marketplace has paying drivers and real transaction volume, splitting the backend into microservices and adding the containerized infrastructure for multi-city scale. Kapitec's AI-accelerated engineering compresses each phase into days, not quarters.
- checkMonolithic Node.js + Express backend
- checkPostgreSQL — users, jobs, payments, ratings
- checkFirebase auth + Cloud Messaging (push)
- checkStripe escrow — funds held until job complete
- checkGoogle Maps — GPS tracking, routing, ETA
- checkDriver app + Customer app + Admin dashboard
- checkFirst pilot drivers + contractors onboarded
- checkSplit monolith into six microservices
- checkRedis — live driver locations, active job state
- checkContainerization — Docker + Kubernetes
- checkAWS infrastructure — EC2, RDS, S3, CloudFront
- checkMatching algorithm v2 — priority drivers, surge pricing
- checkAnalytics dashboard for dispatch and CFO reporting
- checkReady to onboard a second city
The MVP is deliberately monolithic — one backend, one Postgres, one Stripe account, one Firebase project. That keeps the first deployment simple and the first bugs easy to track. The microservice split only earns its complexity once there is Phoenix volume to justify it.
Pay to build. Not build to pay.
The engagement is split into a fixed MVP fee, an optional Scale phase quoted only if Phoenix traction warrants it, and an ongoing operations retainer. Nothing starts before the kickoff payment clears. No credit engineering, no "we'll settle up later" — that is the guarantee on both sides.
- checkDriver app + Customer app + Admin dashboard
- checkMatching engine · Job · Payment · GPS services
- checkStripe escrow, Firebase push, Google Maps
- checkApple + Google Play submissions
- checkPilot drivers and contractors onboarded
- checkFull source code ownership, handed to Dayanara
- checkMonolith split into 6 microservices
- checkDocker + Kubernetes containerization
- checkRedis caching layer · CloudFront CDN
- checkMatching engine v2 — priority + surge pricing
- checkAnalytics dashboard for dispatch + CFO
- checkReady to onboard a second US city
- checkAWS hosting, RDS, S3, CloudFront
- check24/7 monitoring, uptime + error alerts
- checkWeekly bug fixes + security patches
- checkMonthly iteration session — one new feature
- checkStripe, Firebase, Google Maps API costs pass-through
- checkDirect WhatsApp line to the engineering team
Twenty years building software that stays running.
Kapitec Soluciones has been shipping production systems since 2006. Our work sits behind operations on both sides of the border — heavy construction supply chains, multi-entity contractors, dispatch floors in Mexico and the United States. We are a boutique firm by design: small team, long tenures, clients measured in decades, not quarters.
Most of what we build sits inside our clients' operations, not in their marketing — the systems run every day but rarely carry a logo. Our construction work covers dump truck dispatch, supplier reconciliation, multi-site logistics, and payments on both sides of the border. We have built every primitive this proposal needs before — just never assembled under one Phoenix-focused marketplace.
Kapi — the company's flagship retail operating system — has been live with paying customers since 2006. Still deployed. Still shipping updates.
Operating dispatch, back-office and supplier networks across Mexican and US builders. Multi-entity accounting, payments, and logistics on both sides of the border.
We design, build, deploy, and operate. No subcontracted back-end, no black-box vendors under the hood. What we ship, we run.
Exactly the marketplace you described.
The platform is three apps talking to one backend: driver app, customer app, admin dashboard. A matching engine in the middle routes every load to the closest available truck with surge pricing when demand spikes. Stripe holds the money in escrow until the job is done, then releases it to the driver. Ratings on both sides keep the marketplace honest.
Phoenix is the right first city and the window is open today. The MVP is deliberately lean — monolithic Node.js, Postgres, Firebase, Stripe, Google Maps — to ship fast, validate with real drivers and contractors, and earn the right to scale. Everything underneath is production-grade from day one.
"Technology is the invisible enabler. Contractors focus on building. Drivers focus on driving. Administrative friction is what we remove — permanently."
Let's walk through the MVP for Dayanara.
A 30-minute working session. I'll bring a live walkthrough of the three apps mapped to real Phoenix routes, run a test job through the matching engine and Stripe escrow, and sketch the day-one onboarding plan for pilot drivers. No slides — only real screens.