What We Learned Building a Hyperlocal Ordering Platform During COVID-19
A real story from Nikiphoros about De-live-r, a hyperlocal ordering platform built during COVID-19, and why simplifying the customer experience mattered more than building another conventional ecommerce application.
During the COVID-19 lockdown, the world changed almost overnight. Shops were closed, customers could not move freely, and even businesses that had products ready to sell struggled to find a practical way to serve their local customers. At Nikiphoros, we saw an opportunity to use the ecommerce technology we already had and build something specifically for that situation. That idea became De-live-r.
1. The Problem We Saw During Lockdown
At the time, many local vendors wanted to continue selling essential products, but the normal shopping process was no longer possible. Customers could not simply walk into a shop, browse products and purchase what they needed.
Our first thought was straightforward: build another ecommerce application that could allow vendors to put their products online and customers to order them.
But while thinking through the actual situation, we noticed another problem.
For many small vendors, entering and maintaining hundreds of products in an ecommerce system was itself a major operational challenge. Shop counters were already busy, and asking employees to prepare a complete digital catalogue could take days.
2. Rethinking the Traditional Ecommerce Model
Most ecommerce applications begin with the assumption that the vendor will first create a product catalogue. The customer then opens the application, browses categories, selects products, adds them to a cart and completes an order.
That model works well when the business has the time and resources to maintain its catalogue.
But during lockdown, we were looking at a completely different environment.
Vendors were dealing with restrictions, changing availability and limited staff. We therefore decided to simplify the first version instead of trying to reproduce a conventional ecommerce experience.
3. Turning the Customer Into the Product Request
Instead of asking every vendor to enter their entire inventory, we changed the starting point.
The customer could select a broad category such as:
- Grocery: Everyday grocery requirements.
- Vegetables: Fresh vegetable requirements.
- Milk & Bakery: Common daily essentials.
- Non-Vegetarian: Relevant local requirements.
- Other categories: Depending on what was available in the local market.
The customer could then type what they wanted, specify the quantity and add another requirement if needed.
This was intentionally closer to a digital request book than a traditional product catalogue.
4. Vendors Could Respond to the Request
Once a customer submitted a requirement, it became available to vendors operating in the relevant category.
Instead of maintaining a complete digital catalogue before receiving any orders, vendors could respond to customer requirements based on what they could actually supply.
The final transaction still involved manual coordination. The application was not trying to automate every part of the local supply chain.
We deliberately kept the first version simple. The goal was to make local ordering possible under unusual circumstances, not to build a perfect replacement for every part of a conventional ecommerce marketplace.
5. Working With Chandrapur District Administration
The concept eventually reached the Zilla Parishad Chandrapur district administration, which helped announce the initiative through local newspaper communication and its social media channels.
For a small technology company with a team of only a few people, this was a significant moment. The project was no longer only an internal product experiment. It had received attention from the local administration during one of the most difficult periods businesses had experienced.
It also created an unexpected challenge: communication.
Because newspaper publication could not simply present a direct promotional URL in the same way as a normal advertisement, people who read about the service needed another way to find it. Social media communication included a Play Store route, but the application was still under Google Play review at the critical moment.
6. The Timing Problem
People started looking for the application before it was available on the Play Store.
The following day, the application was approved and became available. Some vendors joined the platform and the concept started moving from an idea toward actual usage.
This experience taught us something that has remained important in our product work: technical completion and public availability are two different milestones.
7. Feedback From Real Users
One of the most memorable moments was receiving a call from a person who had successfully received an order through the platform. He called simply to say thank you.
For a developer, that is very different from seeing a successful test case in a development environment. A real person had used something we built to solve a problem in the real world.
We also received feedback from the manager of Samadhan Purti Super Bazar, a well-known store in Chandrapur. He liked the concept and suggested another useful idea.
The store manager suggested remembering what customers had previously typed as product requirements and using those entries as suggestions the next time they wanted to request the same or similar product.
It was a small suggestion, but it represented something important: users were already thinking about how the product could become more useful in their everyday workflow.
8. Another Attempt in Gadchiroli
We also explored whether the concept could be extended to Gadchiroli through discussions with the district administration.
The response was encouraging regarding the technology, but it highlighted a much bigger operational question: who would actually deliver the products?
The assumption was that vendors could deliver orders because they were the people selling the products. But during lockdown, vendors themselves were facing extraordinary restrictions.
One example made the situation very clear. A vendor had previously been asked to deliver essential items such as milk and bread to an official residence on a daily basis. Even though the vendor knew the person making the request was the district collector, the vendor still declined because of the circumstances at the time.
That conversation showed us that technology could make an ordering process possible, but it could not automatically solve the physical constraints created by a lockdown.
9. Then Google Changed the Situation
Another unexpected challenge came from the Google Play review process.
The application was rejected because of COVID-19-related content and policy requirements. At that time, applications containing certain COVID-19-related information required appropriate official government documentation.
We explained that the application was fundamentally an ecommerce and ordering platform and that the COVID-related reference was not the purpose of the product. We were willing to remove the relevant content, but the application still could not continue as originally planned.
It was a difficult moment because the product had started receiving attention at exactly the time when the external environment was changing rapidly.
10. What De-live-r Taught Us
De-live-r was a small idea, but it gave us several lessons that continue to influence how we approach software development.
- Start with the real problem. The obvious solution was another ecommerce catalogue. The real problem was that vendors did not have the capacity to create and maintain that catalogue.
- Simplification can be more valuable than adding features. Removing the need for complete product entry made the concept much easier to operate.
- Technology has physical limits. An application can connect customers and vendors, but it cannot automatically solve delivery, staffing or movement restrictions.
- Real users reveal things developers cannot predict. The suggestion about product-history-based recommendations came directly from someone using the system.
- Distribution is part of product development. Having a working application is not enough if people cannot discover or install it at the right moment.
11. Why This Project Still Matters to Us
De-live-r was not the largest application we built, and it did not become the long-term marketplace we originally imagined.
But it remains one of the projects we remember because it happened during an extraordinary period and forced us to think differently about product design.
Sometimes the best product is not the one with the most features. It is the one that removes the biggest obstacle standing between a person and the thing they need.
Nikiphoros
12. From One Small Idea to a Larger Product Mindset
Our experience with De-live-r strengthened something we already believed: software development should begin with understanding how people actually work.
Whether we are building an ecommerce application, employee system, CRM, attendance platform or another business solution, we try to look beyond the requested feature list.
The important question is often not simply “What should the application do?”
It is:
What is making the user's existing process difficult, and how can technology remove that difficulty without creating a new one?
Conclusion
De-live-r started with a simple thought during an extremely difficult time: if people could not go to their local shops, perhaps technology could help them communicate what they needed.
The final product was shaped by much more than code. It was shaped by vendors, customers, administrators, platform policies and the realities of operating during lockdown.
For Nikiphoros, that experience became an important reminder that good software is not only about technology. It is about understanding people, simplifying their work and building around the reality in which the product will actually be used.