Chapter I – How This Project Started
Every successful software project begins with a conversation. Not with code. Not with wireframes. And certainly not with a list of features.
It begins with people trying to solve a problem.
For this project, that conversation started with a simple enquiry submitted through the contact page of our website. The team behind Rasa Padhama wanted to discuss building an ecommerce platform for their growing spice business. At first glance, it sounded like a project we had undertaken many times before.
It wasn’t.
Our first discovery meeting made that clear.
The client had already established an online presence using a third-party multi-vendor platform. It had served its purpose well during the early stages of the business, allowing them to reach customers quickly without investing in a fully custom solution.
But success had created a new problem.
They weren’t looking for another website. They were looking for independence.
The business was evolving faster than the platform could.
Every new idea had to fit within someone else’s ecosystem. Every improvement depended on the limitations of software they didn’t own. Features that could differentiate the business often became difficult, expensive, or simply impossible to implement.
They weren’t looking for another website. They were looking for independence. That distinction shaped every conversation that followed.
Understanding Before Building
One of the easiest mistakes in software development is assuming you already understand the problem. (If you know, you know.)
Experience can be valuable, but it can also become dangerous if it encourages shortcuts.
Experience teaches patterns. Good discovery teaches exceptions. Every project has both.
Instead of jumping into design or discussing technologies, we spent time understanding how the business actually operated.
- How did customers discover products?
- What influenced their purchasing decisions?
- What happened after an order was placed?
- Which parts of the business worked well, and which created unnecessary friction?
- Most importantly, where did the client see the business three or five years from now?
The answers gradually revealed that this project wasn’t simply about replacing an existing one.
It was about building a platform that could grow alongside the business without forcing future ideas into someone else’s framework.
Over several requirement gathering sessions, we mapped customer journeys from the moment someone first visited the website to the point where an order was delivered. Every interaction was discussed. Every assumption was questioned.
Those conversations often uncovered opportunities that weren’t part of the original brief.
One of them became the platform’s loyalty program.
The client wanted to strengthen long-term customer relationships, but hadn’t yet decided how best to achieve that. As we explored their business goals, we proposed a points-based loyalty system that would reward repeat purchases, encourage future orders, and remain simple for both customers and administrators to manage.
The idea immediately resonated. It wasn’t a feature the client had requested. It became one of several ideas that naturally emerged because we were discussing business goals rather than individual website components.
Moments like these remind us why discovery meetings matter.
Clients often arrive with solutions. Our job is to uncover the problems those solutions are trying to solve.
The Question That Changed Everything
Then came a question that changed the direction of the entire project.
The client asked whether customers could purchase several months’ worth of products in advance, pay only once, and continue receiving those products at exactly the same price, even if market prices increased during the following months.
At first, the request sounded almost like a subscription service.
The more we discussed it, the more we realized it was something entirely different.
- There would be no recurring billing.
- No automatic monthly payments.
- No subscription renewals.
Customers would make a single purchase, locking in today’s prices for future deliveries over a period of up to four months.
The concept addressed a very real challenge.
Sri Lanka’s market conditions had become increasingly unpredictable, particularly for everyday household essentials. Prices could change significantly within a relatively short period, making it difficult for families to plan their monthly grocery expenses with confidence.
The client wanted to offer customers something more valuable than convenience. They wanted to offer certainty.
That idea eventually became known as Taste ePromise.
As exciting as the concept was, it immediately raised a series of engineering questions.
- How would future deliveries be scheduled?
- How would inventory be planned?
- How would original prices remain protected if product prices changed weeks later?
- What would happen if some products became unavailable?
- How could all of this remain simple enough for customers to understand in just a few clicks?
Those weren’t questions a plugin could answer.
They would shape much of the engineering work that followed.
An Ecosystem Begins to Take Shape
As discussions continued, another pattern emerged. Every new idea complemented another. Alongside Taste ePromise, the client envisioned several initiatives designed to strengthen customer engagement throughout the purchasing journey.
- Customers would earn rewards through Taste ePoints, encouraging long-term loyalty rather than one-time purchases.
- A referral program named Taste eShare would allow existing customers to introduce friends and family to the brand.
- Taste eBuzz would provide recipes, updates and newsletters, creating an ongoing relationship that extended beyond individual transactions.
- The business also planned to introduce Taste eSpicePrize, offering carefully curated spice combinations for customers seeking convenience without sacrificing authenticity.
When viewed individually, each initiative appeared straightforward. But together, they formed something much larger.
This wasn’t becoming an online store. It was becoming an ecosystem. That realization changed our own thinking.
Rather than asking, “How do we build this feature?”, we started asking, “How do these ideas work together?”
Good software isn’t a collection of independent features. It’s a collection of connected experiences.
Looking Beyond Products
One conversation in particular stood out. The client spoke passionately about helping customers discover new ways to cook with their products, not simply selling spices online.
Recipes were going to play an important role. Initially, it sounded like a standard blog. But the more we explored the idea, the clearer it became that recipes shouldn’t behave like ordinary articles.
When someone reads a recipe, they’re often thinking about making that meal.
Which naturally leads to another question.
“Can I buy these ingredients?”
That single observation planted the seed for one of our favorite features in the project.
Instead of forcing visitors to leave a recipe, search for each ingredient individually, and add them to the cart one by one.
What if the recipe itself became part of the shopping experience?
Like many good ideas, it didn’t appear in the original requirements document. It emerged through conversation.
We didn’t know it yet, but turning that idea into a seamless experience would become one of the more interesting challenges of the project.
We’ll explore the customer experience behind that journey in the next chapter. If you’re curious about the engineering that made it possible, we’ve also got a dedicated Engineering Insights article that dives into the technical implementation.
We’ll come back to that story in the next chapter.
Before a Single Line of Code
By the time our discovery phase concluded, we had pages of notes, process diagrams, customer journeys and technical discussions. What we didn’t have was a single line of production code.
And that was exactly how it should have been.
Too often, software projects rush toward development before everyone fully understands the problem they’re trying to solve.
The more time invested in asking thoughtful questions at the beginning, the fewer assumptions would need to be corrected later. Of course, not every challenge could be predicted. One of the platform’s most ambitious ideas would soon face a real-world test, forcing us to rethink parts of its design long after the discovery phase had ended.
As we moved into design and development, our attention shifted toward a different question.
How could we make shopping for everyday spices feel simpler than it already was?
The answer wasn’t adding more features. It was removing friction.
That’s where our next chapter begins.
Found this article useful?
July 7, 2026 @ 7:57 pm
Reading this honestly brought tears to my eyes 🥹. Seeing how much we have built into Rasapadhama.lk takes me right back to the original conversations and the dream behind it all. We are incredibly proud to say that, with your unwavering support, we have launched features that are publicly available to Sri Lankans for the very first time. We didn’t just build a website. we paved a new way forward
July 15, 2026 @ 8:24 pm
Thank you so much for this. ❤️
Reading your comment means more to us than we can put into words. It has been an incredible journey, and we’re grateful that you trusted us to be part of bringing that vision to life.
Writing this chapter reminded of us of those very first conversations, and we’re glad it brought those memories back for you too.
Thank you for believing in us from day one. The journey isn’t over yet, and I’m looking forward to sharing the chapters that are still to come.