# Designing a Continuous Pricing Model

Mario Vega

26 June 2018

Let me lead this off by stating my love for the eCommerce platforms I've used during my time as a web developer. I've worked so far with WooCommerce and Shopify, and I couldn't be happier with how easy they make it for anybody to start their own online store quickly.

Typically, I'm not one to try and re-invent the wheel when it comes to code. With client work and with my own side projects, I've learned that the easiest code to maintain is the code you don't have to write. Whenever possible, I recommend solutions that leverage existing code, because you outsource the responsibility of maintaining your code to someone else -- in the best scenarios, someone whose job it is to exclusively maintain code. Open-source flips this model on its head a bit in that the technology's users are also its maintainers, but for the average, non-technical user, this rule holds up nearly 100% of the time. In fact, when it comes to software working as intended, I personally have more faith in open-source projects that can leverage entire communities of intelligent developers than I do in closed-source projects where only a handful of people even see the code, let alone know how it works.

However, I've recently come to the conclusion, both through my experience working with clients and as an indirect product of my nascent studies in machine learning, that there is a category of eCommerce products that aren't well served by existing solutions. And the more I dug into the issue, the more I came to believe that this wasn't a problem that could be solved incrementally, by adding or modifying code for an existing solution. In fact, the difference digs right into the inner workings of how every eCommerce application currently works, and to make the changes I'm suggesting would require a restructuring of how inventory is managed, priced, and published to the web.

So, what is this difference? As alluded to in the title, it involves the ability to price items on a curve. But what does that mean, and why isn't it possible in current eCommerce applications?

## Continuous vs. Discrete Pricing

The simplest way I've thought of to explain the difference is selling t-shirts vs selling jelly beans.

With t-shirts, it's fairly easy to price each t-shirt your store offers individually. Perhaps you have black tees and red tees, or perhaps you have some tees with graphics on them and some without. In any case, assuming your customers are mostly retail -- that is, assuming you're not selling t-shirts to businesses -- your pricing is going to be fairly consistent. Black tees might be $20 and red tees might be $10, graphics might be $25 and plain tees might be $90 if you're Kanye West. Whatever your pricing might be, each thing that your store sells has a specific price: in other words, a discrete price.

This is the model that eCommerce software is built upon. For most businesses, this works perfectly fine, as this model matches up well with how their products are bought and sold. However, imagine for a moment that you sell jelly beans. Imagine also that you sell jelly beans to all sorts of customers, from individual gift baskets to massive corporate shipments.

You might think that pricing your jelly beans would become difficult quickly -- and you'd be right. The price of an individual jelly bean will vary drastically from order to order, depending on how many are ordered and by whom. Perhaps individual orders of jelly beans are more expensive because your jelly bean factory is geared up primarily for large customers. Or perhaps jelly bean orders above a certain threshold are much more expensive, as you have to acquire a special sort of jelly bean barrel to package and ship them. In this case, it's probably easier for you to think of your jelly beans in terms of a continuous price, where the price of each jelly bean rises or falls depending on the context of the order.

Now, as with most contrasts you can think of, the difference between discrete and continuous is not set in stone. Selling t-shirts could fit a continuous model at a certain scale, and jelly-beans could be thought of discretely if you narrowed down the range of options by which you sold them.

However, my experience in the field has shown me that the further your business model skews towards continuous pricing, the less well-served it is by traditional eCommerce solutions. Many clients I've worked with end up implementing an awkward combination of product variants and discount structures to make their continuous pricing model fit into a discrete model that can work with their platform of choice. This setup makes changing your pricing a difficult, time-intensive, and potentially dangerous endeavor, reducing your ability to adapt and increasing the likelihood that a competitor outmaneuvers you.

## What's the Solution?

I've implemented a continuous pricing model in Shopify and WooCommerce enough times to know there must be a better way.

The most straightforward solution I've thought of is to allow store owners to create their own price curve. In the simplest cases, you have one independent variable and one dependent variable, making it fairly simple to create price curves on a per-product basis. For example, for our hypothetical jelly bean vendor, the independent variable might be the number of jelly beans, and the dependent variable might be the price per jelly bean. If a customer orders 10 jelly beans, our vendor might charge 10 cents per jelly bean. Order 1,000 jelly beans, and the price drops to 5 cents per jelly bean.

This model is easy enough to replicate on a line chart. Use your independent variable for your x-axis, your dependent variable for your y-axis, draw your points on the graph, and let math take care of the rest.

In and of itself, this would solve our continuous pricing problem. The challenge is that such a model isn't possible in your average eCommerce solution, where every variant must have a specific price. So in order to embrace this continuous curve, vendors would have to strike it out on their own.

This got me to thinking: how can I take this idea to its furthest extent, helping business owners fully embrace their unique pricing models with all of their inherent quirks? Which led to my next thought: if we can chart prices, why can't we chart costs as well? We could chart how rapidly shipping costs increase per jelly bean, for example, or how producing jelly beans en masse reduces the cost of each individual bean. If we combined all of those cost curves together, we could arrive at a single curve that would represent the total cost of producing a jelly bean when taking into consideration every possible cost factor.

And while we're at it, why not use that cost curve to determine the price? If we know how much it takes to produce jelly beans at a specific number of beans, and we know how much profit we want to make, couldn't our cost curves determine our prices automatically? We'd just need to multiply our costs by a given number depending on how much profit we want to make, and we'd have the price we'd need to charge at each point in our curve in order to make the profits we're after.

So, this is the outline of what I want to make! At a super basic level, it'll calculate cost curves and allow store owners to set their prices on a continuous price curve. There will eventually be more to it than that, because a price curve alone does not an eCommerce store make, but one step at a time.