Auani

It started with my cousin's YouTube channel in Uruapan, Michoacán, México.

My cousin was doing food deliveries in Uruapan, Michoacán, and documenting it on YouTube. Watching those videos, I started thinking about what a platform could look like if it were built to actually benefit drivers and restaurants instead of extract from them.

I ran an early test with my cousin. We got a successful delivery. Then he dropped out.

The Mexico side stalled for a few reasons: labor laws weren't clear on my end of things, I wasn't physically there to manage operations on the ground, and my cousin had other plans. ¯\_(ツ)_/¯

I pivoted to the DMV, which has a dense Hispanic community, so it mapped well to the platform's target user base.

I placed QR codes in Hispanic restaurants and bars, found early restaurant partners willing to test food ordering, and started taking real ride requests. I drove a regular commuter the same route a handful of times. The first paid trip was completed in November 2025.

Then things stalled. Promoters I was working with went quiet. Users who said they were interested disappeared. The Shipday API hit a paywall that changed the cost structure. And the bigger problem: DMV laws categorize this kind of operation as a taxicab service, which requires centralized insurance infrastructure and a centralized payment platform. The decentralized model I built was architecturally incompatible with those requirements.

Auani is on the backburner. I still think the model is sound. The problem wasn't the idea.

Drivers shouldn't pay a commission to exist.

Uber takes 20 to 40 percent of every ride and calls it a service fee. The driver has no leverage on that number and it compounds across every trip.

Auani's model was different. Drivers earn a base fare plus a per-mile rate for the actual distance traveled. The platform charges a separate, itemized fee to the rider on top of that. The driver's earnings and the platform's take are shown to the rider as distinct line items before they confirm a booking.

The community target was specific: Hispanic workers and businesses in the DMV. Spanish-first interface. Phone-first design. Features built around how people in that community actually navigate, like accepting business names and neighborhood landmarks as destinations instead of requiring a formal street address.

Inteligencia Artesanal. The resourcefulness that comes from working-class communities making something functional from whatever is available.

The brand concept is "Inteligencia Artesanal": artisanal intelligence. It's a nod to the practical ingenuity of people who build things outside of formal systems, not a lifestyle brand and not a savior narrative. The platform was built by someone from that community to serve it.

Two services, one platform (my first big mistake)

Auani is a rideshare and delivery dispatch platform. Riders submit a booking request through a shortcode-rendered form on the WordPress site. The plugin calculates the fare from route distance via the Google Routes API, shows an itemized breakdown, and collects payment through Stripe before dispatching the job to Shipday.

Drivers apply through a separate form, get reviewed in the admin panel, and connect their own Stripe Express account for payouts. Once approved, they appear as available in the Shipday dispatch dashboard and receive job notifications in real time.

Phone-first, Spanish-first, four steps.

All of Auani users were on mobile. The rider and driver interfaces were designed for that context: one task per screen, large tap targets, minimal text entry.

The request flow used a four-step wizard. A rider picked up their phone, scanned a QR code or opened a saved link, and was in the form within two taps.

Google Places autocomplete was configured to accept business names and points of interest. The target user base navigates by landmark and business name. Requiring a formatted street address would have broken the flow for a significant portion of users.

The fare is calculated live from actual route distance using the Google Routes API, not a flat rate. The rider sees base fare, distance fee, platform fee, and tax as separate line items before confirming. Nothing is hidden in the total.

Drivers operate through the Shipday dashboard, not the web app. Job alerts come in real time. The driver's Stripe Express account receives the payout directly after trip completion.

Named for a rabbit.

Auani is a Purépecha word for rabbit. The Purépecha are an Indigenous people of Michoacán. The name carries connotations of agility, intelligence, and ancestral wisdom. It's also specific: a word from the region where this started.

Que no te falte barrio, carnal.

Tagline

Literally: "May you never lack your neighborhood, friend." A community-grounded phrase. Not a rallying cry, not a startup slogan. Something that means something to the people it's directed at.

Colors

The palette references the avocado farming region of Michoacán. Not decoratively: the origin geography of the project and the namesake language are the same region. The color choices are a geographic acknowledgment, not a lifestyle reference.

Typography

Bebas Neue for display: compact, bold, no-nonsense. Open Sans for body: readable at small sizes on low-res mobile screens. The type choices were functional, not decorative. The interface is Spanish-first, so the typography had to perform well with Spanish text, including longer average word length than English.

One plugin gluing four APIs together.

The platform runs on WordPress with F! Ride handling the entire booking, pricing, dispatch, and payout flow. There is no separate order management system — everything goes through the plugin's own booking tables and AJAX endpoints.

• Core: WordPress platform foundation. F! Ride does not require WooCommerce for its booking flow.
• Dispatch: Shipday API real-time driver assignment, job creation, routing, delivery tracking, and job alerts pushed to driver
• Maps: Google Places API autocomplete for pickup and dropoff, accepts business names and POIs, not just street addresses
• Maps Google Routes API calculates actual trip distance for fare computation
• Payments: Stripe + Stripe Connect payment authorized at booking, captured on driver acceptance. Drivers connect their own Stripe Express accounts for direct payouts.
• Custom: F! Ride booking form ([f_ride]), driver application ([f_ride_apply]), pricing calculator, Shipday API bridge, Stripe Connect onboarding, admin panel with trips, drivers, dispatch, pricing, and export tabs

F! Ride

The plugin uses its own booking tables and AJAX endpoints, not WooCommerce orders. The [f_ride] shortcode renders the booking form. On submission, the plugin calculates the fare from the actual route distance, authorizes payment through Stripe, and creates the dispatch job in Shipday. Payment is captured when a driver accepts.

Pricing is fully configurable in the admin panel: base rate, included miles in base, per-mile rate, platform fee, tax rate on the platform fee, surge multiplier, and payout schedule. All rates are stored as WordPress options and can be adjusted per service area. Stripe fee bearing is also configurable: the driver or platform absorbs it.

• Core: WooCommerce + HPOS compatibility
• Payments: Stripe Connect OAuth + automatic commission splits
• DB: fm_commissions, fm_payouts, fm_messages, fm_message_threads
• Roles: fm_vendor role, scoped product and order queries
• Auth: Certificates of authenticity, sold state, resale royalties
• UX: Front-end dashboard, artist profile pages, buyer messaging

Where things began to break: DMV Laws & Shipday API Paywall.

Two structural problems ended the active phase. First, Shipday changed its pricing tier, which altered the cost math for the platform at low volume. Second, and more fundamentally: DMV tri-state regulations classify this type of operation as a taxicab service. That requires centralized insurance infrastructure and a centralized payment platform.

The decentralized architecture where drivers set their own rates and Auani earns a fee separately was not compatible with that regulatory model. Rebuilding to comply would require insurance partnerships, licensing, and a fundamentally different business structure.

Tech Stack

• Platform: WordPress + WooCommerce
• Vendors: WCFM (WC Frontend Manager and Dokan alternative)
• Courses: Tutor LMS
• Grants: F! Grants
• Payments: WooCommerce Stripe gateway
• Pending: F! Gallery

The ride fare never left the drivers pocket.

Immibrand hasn't turned a profit since I converted it to a multivendor marketplace (ask me why I stopped selling my portraits if you ever come across me in person).

It's a live project and a working concept: the platform exists, products have sold, and there have been successful conversions through the seller registration flow. But the user base is still being tested and the monetization model is still being validated in practice.

The plan for how it makes money is straightforward. Revenue comes from two sources: a sliding commission on sales and optional subscription plans for sellers who need more product slots and support. Phase 1 is free forever and generates no direct revenue. The seller on the free plan who sells 20 products at a 10% commission is the proof of concept, not a loss leader being pressured toward an upgrade.

The rider sees every line item before confirming. There is no opaque total. The driver's portion and the platform's portion are separate fields in the booking. Uber bundles everything into a commission percentage and never discloses the split.

The platform is bootstrapped. No outside investment. Running costs during the soft launch were API subscriptions (Shipday, Google Maps Platform, Google Routes), hosting, and Stripe fees.

It did not reach profitability. The first paid trip completed in November 2025. Active operations paused before transaction volume covered API costs at scale. Whether the model works at volume is still an open question.

What was built.

Auani reached a functional soft launch: a working dispatch system, a food ordering interface, driver routing, and at least one completed paid transaction. I didn't dive too deeply into the food online ordering because it's the same stack as Immibrand for its multivendor marketplace that I was attempting to repurpose for multivendor online food orders. You can see some initial traction below.

On a backburner, not dead.

The platform mechanics work. The dispatch layer connects. Orders and trips flow through. The driver-keeps-100% model is real, not theoretical. The problems that paused active operations are regulatory and operational, not architectural.

If the conditions change, the platform doesn't need to be rebuilt. It needs to be restarted.