How to Actually Draw a Price Elastic Demand Curve
Most people learn the textbook version of this — a flat, almost horizontal line sloping downward from left to right. But drawing it on paper is one thing. Building one you can actually use in a spreadsheet or a pricing model is something else entirely. I'm going to walk through how I built one for a SaaS pricing analysis last year, and what tripped me up along the way.Price Elastic Demand Curve
The core idea is simple enough: as price goes up, quantity demanded goes down. "Elastic" means that drop in quantity is proportionally large relative to the price change. If you raise price by 10 percent and lose 30 percent of your customers, that's elastic demand. The curve itself is just a visual representation of that relationship across a range of prices. Here's how I approached building one in practice, step by step.
The Method I Use
Start with real data points, not made-up numbers. I had a product at three price points: $19, $29, and $39 per month. At each price, I had actual conversion rates from a landing page test — roughly 8 percent, 4 percent, and 1.5 percent of visitors signing up. Those three points are enough to sketch a rough demand curve, though more data is always better. I plotted price on the y-axis and quantity (conversion rate, which proxies for demand) on the x-axis. The resulting shape was noticeably flatter than a standard demand curve you'd see in an economics 101 textbook. That flatness is the signal that demand is elastic in this price range. Then I fitted a linear regression line through those points to get a clean equation. In Excel, that's just a scatter plot with a trendline and "display equation on chart" checked. The equation came out to something like Q = -0.42P + 9.6, where Q is the conversion rate and P is the price. The negative slope is the demand curve in algebra form.
What Beginners Miss
The biggest mistake I see is treating the entire curve as one single elastic relationship. It isn't. In my SaaS example, the demand was highly elastic between $19 and $29 — a $10 jump cut conversions in half. But between $29 and $39, the drop was less dramatic in percentage terms because the remaining customers were already the hardened ones willing to pay more. The curve actually steepens as you move right. One demand curve does not describe every price segment. Another issue: elasticity isn't a fixed property of a product. It shifts with context. The same $19-to-$29 jump in a completely different market segment — say, enterprise teams rather than individual users — produced almost no churn. The Price Elastic Demand Curve for that segment was nearly vertical in the same range. You need to segment your data before you fit one curve to it.
Get the Full Details
A Problem I Hit That Weren't In Any Textbook
When I tried to use the regression equation to predict revenue at a price point I hadn't tested — $24 — the model suggested we should price there. Revenue projection looked best. But when we actually tested $24, the conversion rate was about 5.8 percent, while the model predicted 7.2 percent. We were off by over a full percentage point, which at scale is a meaningful amount of lost revenue. The workaround was to switch from a linear fit to a log-linear model. Instead of fitting Q = a + bP, I fit ln(Q) = a + bP. This accounts for the fact that percentage changes in demand tend to respond more consistently to price changes than absolute changes do. The log-linear fit brought the prediction error down to under 1.5 percent at the $24 test point. If you're working with small datasets and wide price ranges, this matters more than people admit.
Common Pitfalls
One pitfall is confusing arc elasticity with point elasticity. Arc elasticity measures the average responsiveness between two price points. Point elasticity measures responsiveness at a single price using a derivative. For a straight-line demand curve, these will give you different numbers. I used arc elasticity when comparing two tested prices because it's more honest about what the data actually tells you. Point elasticity is fine once you have a fitted curve and want to estimate at untested prices, but the approximation gets worse the further you move from your data range. Another pitfall is ignoring the time dimension. Demand elasticity measured over a one-week promotional period will look very different from elasticity measured over a full year. People react differently to price changes when they're surprised versus when they've had time to adjust their habits. My initial elasticity estimates were based on a two-week flash sale, and they overstated true long-run elasticity by roughly 40 percent. The fix was to run a follow-up test at the same prices for eight weeks and recalculate.
When This Approach Breaks Down
A Price Elastic Demand Curve built from observational data — like scraped competitor prices and your own traffic — is not trustworthy without heavy caveats. Price and quantity move together, but correlation isn't causation. If you raised prices during a period when your marketing also improved, the demand shift you attribute to price may be partly attribution error. The cleanest way to isolate price elasticity is a controlled experiment: show the same audience different prices and measure the response. Even a simple A/B test with two price variants gives you a far more reliable elasticity estimate than any regression on historical data. For products with network effects — social platforms, marketplaces, communication tools — the standard demand curve framework is almost useless. The relationship between price and demand isn't a simple downward slope. More users can make the product more valuable, which changes the entire shape of demand. I spent two weeks trying to fit a conventional demand curve to a marketplace product before giving up and switching to a two-sided model that treats buyer and seller sides separately. It took longer to set up but was dramatically more accurate.
What You Need to Get Started
You need three things: price points, corresponding demand measurements at each price, and a tool to fit the curve. A spreadsheet handles the basic case. Python with scipy or statsmodels handles the log-linear model and confidence intervals. R is overkill unless you're doing this repeatedly across many products. The actual drawing part — the visual curve — is a scatter plot with a trendline in any reasonable plotting library. I kept a simple Notion database with columns for product, price point, date, observed conversion rate, sample size, and whether the data came from an experiment or observation. That last column turned out to be critical when I was reviewing a year's worth of estimates and needed to separate the reliable ones from the noisy ones. The noisy ones — mostly observational data from periods with concurrent marketing changes — were the ones I learned to discount.
