I Built a Super-App Backend in 2 Weeks. Here's What Nobody Tells You About the Chaos.

Day 1: "How hard can it be?"

I had 14 days. One Laravel backend. Five verticals.

• Food delivery
• Marketplace
• Pharmacy
• Laundry
• Parcel delivery

"Just connect everything and ship," I told myself.

Narrator: It was not that simple.

The Number That Keeps Me Up at Night

By Day 14, I was staring at:

• 1,028 PHP files
• 236 database migrations
• 65 commits in the Git history

Sixty-five commits in fourteen days.

That's not a project. That's a hostage situation with git push.

The Commission Problem Nobody Warned You About

Here's the thing about building a multi-vendor platform: everybody wants their cut.

The vendor wants theirs. The rider wants theirs. The platform wants its cut. And somehow, all of this needs to calculate correctly, down to the kobo, across every single order type.

I spent 3 days building a commission engine that handles:

• Vendor commission percentages
• Platform commission splits
• Rider delivery fees
• Markup calculations (global AND vendor-specific)
• Null handling for every edge case that breaks at 2 AM

"What happens when both markup types are null?"

Nobody tells you about this in tutorials. You find out at 2 AM when your test user places an order, and the whole system divides by zero.

Notifications: The Invisible Monster

You know what's harder than building an order system?

Telling people about it.

I built a notification system that sends:

• Push notifications with images (because text-only is 2019)
• Real-time status updates for every order state
• Market order events: accepted, en route, delivered, cancelled
• Pharmacy order matching alerts
• Laundry dispute handling flows

Each notification has to be:

• Instant
• Contextual
• Delivered across multiple channels
• Actually useful (not spam)

I wrote 428 lines of notification logic in one week alone.

The Payment Resurrection

Users abandon carts. Payment gateways time out. Networks flicker.

So I built a payment resurrection system: when a payment fails, or times out, customers can reinitialise and try again without losing their order state.

// Market orders — recoverable
// Pharmacy orders — resumable
// Laundry orders — retryable

All recoverable. All resumable. All tested.

Because nobody's perfect. But your payment system should be.

Real-Time Order Tracking

Every order has a lifecycle:

Placed → Accepted → En Route → Delivered

But what happens when things go wrong?

• Customer disputes a laundry item
• Rider can't find the address
• Vendor runs out of stock after confirming

I built status logs for every single state change. Every transition. Every timestamp. Every reason.

Not because the client asked for it.

Because debugging without logs is just guessing with confidence.

The Feature Toggle That Saved the Day

Not everything should be live on Day 1.

So I built an ensureFeatureAvailable method that gracefully handles feature unavailability. If a feature isn't ready, users get a clean response instead of a 500 Internal Server Error.

if (!$this->featureEnabled($feature)) {
    return response()->json([
        'message' => 'This feature is coming soon.',
    ], 403);
}

Small thing. Huge impact.

What I Learned in 14 Days

1. Migrations are forever. Make them idempotent or make them twice. I chose twice.

2. Edge cases aren't edge cases. They're just cases you haven't hit yet. I handled null values in markup calculations on Day 12. Should've been Day 1.

3. Notifications are a product. Not an afterthought. The way you notify users IS the user experience.

4. Commission math is a philosophical problem. It's not about the numbers. It's about who gets paid, when, and how you prove it.

5. 1,028 files is not a flex. It's a cry for help. But the system works. Every route. Every controller. Every relationship. It all connects.

6. Logs are not optional. If you can't trace an order from placement to delivery, you're not building a system. You're building a house of cards.

The Numbers

The Architecture

├── Market Orders
├── Pharmacy Orders
├── Laundry Orders
├── Restaurant Orders
├── Parcel Delivery
├── Payment Recovery
├── Admin Dashboard
├── Spin Campaigns
├── Promo Engine
└── Notification System

One backend. Five verticals. One codebase.

What's Next

The backend is live. The API is stable. The foundation is solid.

But this is just the beginning.

Building the infrastructure was the hard part.

Making it scale? That's the interesting part.

If you're building something similar and want to talk shop, or if you just want to feel better about your own deadline, hit me up.

P.S. — If anyone asks, yes, I did rewrite the same migration three times. No, I will not elaborate.