Two months ago, my product manager walked up to my desk and said four words: "We need parcel delivery." I nodded confidently. Inside? I had no clue where to start. FoodMartex was already handling food orders—customers ordering from restaurants, riders delivering meals, and admins managing operations. Adding parcel delivery meant building a second nervous system alongside the first one. Same platform. Same users. Entirely new logic. I said yes anyway. Sometimes that's all you need to do.
The False Start
Week one was humbling. I opened my editor and stared at the blank screen for what felt like hours. Where do you even begin with something this big? I started with the customer create page—a form with pickup and dropoff locations, item type, weight, and dimensions. Google Places autocomplete, real-time cost estimation, field validation. It was supposed to be the "easy part." It wasn't. The first version was a mess. The autocomplete broke when users typed too fast. The cost estimator fired at the wrong time. Validation errors showed up in the wrong places. I deleted the whole thing and started over. Then I did it again. The third time, I stopped trying to write perfect code and just wrote working code. That was the moment everything changed.
The Map That Broke Me
Week three. The rider interface. Riders needed an interactive map that showed pickup location, drop-off location, and their own live position. A route line connecting all three. Stage tracking—are you heading to pick up your parcel, or are you on your way to deliver it? I remember Friday night. I was trying to draw a simple line between two points using Leaflet. A basic polyline. Should have taken five minutes. Three hours later, I was still staring at a blank map. I went to bed frustrated. I woke up Saturday and tried again. Nothing. Saturday night, I almost gave up and used a static map instead. Sunday, 2 a.m. I don't know what changed. Maybe my brain finally processed the problem. But the line appeared. A green route from point A to point B. I took a screenshot. Sent it to no one. Just sat there and smiled.
The Tracking That Wouldn't Quit
By week five, the pieces were coming together. But real-time tracking was the thing that scared me most. Every ten seconds, the tracking page polls the server for the latest status. Sounds simple. But what happens when:
- Is the network slow?
- The user refreshes mid-poll?
- The status changes between two polls?
The rider loses GPS signal? I handled each case one at a time. The status badges changed colour—green for delivered, red for cancelled, blue for in transit, and orange for pending. Small details, but they told a story. The first time I saw a status transition from "pending" to "in transit" to "delivered" in real-time on my screen, I refreshed the page three times just to make sure it wasn't a fluke. It wasn't.
The Final Stretch
Weeks six through eight were about tying everything together. An admin panel with rider assignment, pricing configuration, and a full timeline. A rider history page with filters. A customer list with cancel capability. The patterns were clear by now. The hard lessons from weeks one through five had become muscle memory. I was no longer fighting the code — I was simply writing it. Three days ago, a real user opened the app. Created a parcel delivery. A rider accepted it on the map. Picked it up. Dropped it off. The tracking updated every ten seconds from start to finish. I didn't do anything special. I just watched.
What I Learned: Two months ago, parcel delivery was a blank Vite project. Today it's 11 pages across 3 user roles, 3 API services, an interactive map, and real-time tracking that actually works. But the real lesson isn't technical. It's this: You don't need to know how to build something before you start building it. You just need to be willing to write bad code first, learn from it, and rewrite it better the next time. The map didn't work on Friday. It worked on Sunday at 2 a.m. Between those two points, nothing changed except I didn't give up. That's the whole secret. There's nothing else.
Top comments (1)
This is such a vivid example of learning by doing. I really appreciate how you describe the step-by-step struggle—from building the customer form, to the interactive map, to real-time tracking—and how persistence and iteration transformed a blank Vite project into a fully functioning multi-role system.
The key takeaway resonates deeply: you don’t need to have all the answers before you start building. Starting with working-but-imperfect code, observing what fails, and iteratively improving is often more effective than waiting for perfect planning. The way you handled real-time polling, network edge cases, and UI feedback shows the value of building muscle memory through hands-on problem-solving.
I’d love to collaborate or exchange ideas on practical approaches to real-time system development, mapping interfaces, and multi-role application architecture, especially for small teams shipping complex web apps.
Would you be open to discussing techniques or patterns for iterative, resilient frontend-backend development in similar projects?