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 the ideaGeek 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.

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.

Experience can be valuable, but it can also become dangerous if it encourages shortcuts.

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 website.

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. Rather than treating every purchase as an isolated transaction, we proposed rewarding repeat customers through a points-based system that could encourage future orders while remaining simple to manage.

The idea immediately resonated. It wasn’t a feature they had initially 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 engineering challenges of the project.

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. We chose a different path.

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. Some of the biggest ones were still waiting for us.

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.