[h] home·[n] notes·[w] work·[a] about
INA·
← notes
Features That Look Simple but Aren't
 
E-commerceEngineeringBusiness LogicCase Study

Features That Look Simple but Aren't

Building an e-commerce application isn't just about adding products to a cart. From shopping carts and checkout flows to coupons and promotion engines, seemingly simple features often hide the most complex business rules.

Introduction

One sentence I've heard countless times during product discussions is:

"It's just a small feature."

At first glance, many e-commerce features seem straightforward.

A shopping cart is just a list of products.

Checkout is just collecting payment information.

A coupon is just applying a discount.

A promotion is just reducing the price.

Simple, right?

Not exactly.

As I spent more time building production e-commerce applications, I realized that these features are rarely as simple as they appear. What looks like a few UI components often hides dozens of business rules, edge cases, and dependencies behind the scenes.

This article explores four features that taught me an important lesson:

The simplest-looking features are often the most complicated to build.


1. Shopping Cart

From a user's perspective, a shopping cart is incredibly simple.

  • Add product
  • Remove product
  • Change quantity

That's all they see.

Behind the scenes, however, the cart quickly becomes the center of the entire shopping experience.

A cart has to answer questions like:

  • Is the product still available?
  • Has the price changed?
  • Is there enough stock?
  • Is this product eligible for a promotion?
  • Can multiple promotions apply together?
  • What happens if a customer changes the quantity?
  • What happens if inventory changes while the user is still shopping?

Every modification can affect pricing, promotions, taxes, shipping costs, and the final total.

The cart isn't just storing items.

It's maintaining a constantly changing state that must remain accurate.


2. Checkout

Checkout often looks like a simple form.

In reality, it's where almost every business rule comes together.

A checkout page usually needs to calculate:

  • Product subtotal
  • Shipping cost
  • Tax
  • Discounts
  • Final payment amount

But the complexity doesn't stop there.

Customers may choose different fulfillment methods.

Delivery

Shipping isn't simply selecting a courier.

The application may need to consider:

  • Shipping destination
  • Available courier services
  • Shipping rates
  • Delivery estimation
  • Weight calculation
  • Free shipping campaigns

Pickup In Store

Pickup introduces an entirely different set of rules.

Questions become:

  • Which stores have inventory?
  • Is pickup available for every product?
  • Which pickup locations should be shown?
  • Does pickup remove shipping costs?
  • Are pickup promotions different?

Although both options belong to the same checkout page, they often follow completely different business logic.


Tax Calculation

Tax also varies depending on business requirements.

Some businesses include tax in product prices.

Others calculate tax during checkout.

Some products may even have different tax rules.

A single number displayed to the customer may require multiple calculations behind the scenes.


3. Coupon

Coupons appear simple.

Users enter a code.

A discount is applied.

Done.

Except it rarely works that way.

A coupon may have conditions such as:

  • Minimum purchase amount
  • Expiration date
  • Maximum usage
  • Usage per customer
  • Specific products only
  • Specific categories only
  • New customer only
  • Member only

Now imagine a customer enters two coupon codes.

Can both be applied?

If not, which one wins?

Should the customer receive an error message?

Or should the system automatically choose the better discount?

Every answer depends entirely on the business rules.


4. Promotion — The Most Complex Feature

If I had to choose one feature that consistently grows in complexity, it would be the promotion engine.

At first, a promotion sounds simple.

Buy something.

But in reality, promotions are driven by business strategies rather than technical simplicity.

Every campaign introduces new conditions.

Every condition introduces new edge cases.

Over time, the promotion engine becomes one of the most complicated parts of an e-commerce platform.


Different Types of Promotions

Some promotions are based on:

  • Minimum quantity
  • Minimum spending
  • Product category
  • Product brand
  • Customer segment
  • Payment method
  • Shipping method
  • Purchase history
  • Store location
  • Loyalty points

Each promotion may calculate discounts differently.

Some provide percentage discounts.

Some provide fixed discounts.

Others give free gifts.

Some unlock free shipping.

Some only affect specific products.

The application must evaluate all of these correctly.


Overlapping Promotions

Things become even more complicated when multiple promotions are active simultaneously.

Imagine a customer qualifies for:

  • Buy 3 items, get 10% off
  • Spend over $100, receive $15 off
  • Free shipping campaign
  • Loyalty member discount

Can all of them be combined?

Should only one promotion apply?

If multiple promotions are allowed, in what order?

Should percentage discounts be calculated before fixed discounts?

Or the opposite?

Without clear prioritization rules, different calculation orders may produce different totals.


Promotion Priority

One challenge I frequently encountered was defining promotion priority.

Business teams often expect the system to behave naturally.

For engineers, "naturally" isn't enough.

Everything must be explicitly defined.

Questions like these become important:

  • Which promotion should be evaluated first?
  • Can one promotion invalidate another?
  • Does a coupon override an automatic promotion?
  • Can a free gift promotion coexist with a spending promotion?
  • Should loyalty discounts be applied before or after coupons?

Even a single missing rule can lead to inconsistent pricing.


Edge Cases Never End

Promotions introduce an endless list of edge cases.

For example:

A customer qualifies for a minimum quantity promotion.

They remove one product from the cart.

Should the promotion disappear immediately?

Another customer qualifies for a minimum spending promotion.

After applying a coupon, the total falls below the minimum spending requirement.

Should the promotion still apply?

What if adding one more product activates a completely different promotion?

Every cart update may require recalculating every active promotion from scratch.


What I Learned

Building e-commerce applications taught me that complexity rarely comes from the UI.

Most of it comes from business rules.

The interface may only display a discount badge.

Behind that badge is often an engine evaluating dozens of conditions before deciding whether the customer deserves that discount.

As engineers, it's tempting to focus on writing elegant code.

But building these systems requires something even more important:

Understanding the business itself.

Because without understanding the business rules, it's impossible to build the correct software.


Final Thoughts

Whenever someone says,

"It's just a shopping cart."

or

"It's just a promotion."

I smile.

Not because they're wrong.

But because I know how much work is hidden behind those words.

The best e-commerce experiences feel simple to customers precisely because engineers spend countless hours handling the complexity they never see.

And that's one of the things I enjoy most about building software.

Turning complicated business rules into experiences that feel effortless.


Key Takeaways

  • Features that look simple often hide the most complex business logic.
  • Shopping carts are more than lists of products—they're dynamic pricing engines.
  • Checkout combines shipping, tax, promotions, and payment into one workflow.
  • Coupons require validation, eligibility, and conflict resolution.
  • Promotion engines are often the most complex part of an e-commerce platform due to priorities, overlapping campaigns, and constantly evolving business rules.
  • Great user experiences are built by hiding complexity, not exposing it.