Project at a glance

A pricing system, not another discount rule.

  • Problem Last-minute ticket pricing needed to react to stock, event timing, and demand without relying on fixed discount bands.
  • Build We delivered the pricing endpoint, Postgres tables, outcome logging, short-lived price locks, and dashboard controls.
  • Handover The system starts with safe assumptions, learns from live sale and no-sale outcomes, and supports A/B measurement once enough data exists.

The client needed last-minute ticket pricing that could make better decisions than a static discount schedule. The useful signal was already in the booking context. How much capacity remained, how close the event was, and how quickly tickets were selling.

The work was to turn that context into a production pricing system. It had to integrate with the existing API and Postgres database, behave sensibly before a large sales history existed, and create the measurement trail needed to prove whether dynamic pricing was increasing revenue.

The pricing decision

The engine does not move prices randomly. For each request, it estimates how likely a ticket is to sell at different candidate prices, then selects the price with the strongest expected revenue within the limits the client controls.

expected revenue = ticket price × probability of sale

That distinction matters. The highest possible price is rarely the best price. A higher price can improve revenue per sale but reduce the chance of selling at all. The engine's job is to find the balance point for the current event context.

Pricing flow Every shown price becomes a decision record.
Customer requests price

The product asks for the ticket price to show for a specific event.

Context snapshot

Remaining stock, event capacity, time until event, and recent sales velocity.

Price guardrails

Floor, ceiling, and cost or wholesale price keep every recommendation inside the allowed range.

Pricing engine

Demand estimate scores sale probability across candidate prices, then selects the strongest expected revenue.

Price returned

The API returns a bounded price and creates a short-lived lock for consistency.

Learning safely from day one

The system starts with sensible assumptions so pricing is controlled before the model has seen much data. As outcomes arrive, it shifts from assumption-led pricing toward demand-led pricing.

We used Thompson sampling to balance exploration and exploitation. When the model is uncertain, it tests carefully inside the permitted range. As evidence builds, it concentrates on the prices that are more likely to produce revenue. Because the model learns from context rather than memorising individual events, new events benefit from what previous events have taught the system.

  • Starts controlled: launch pricing is bounded by explicit floors, ceilings, and ticket cost inputs.
  • Explores cautiously: Thompson sampling tests prices when the model is uncertain, then commits more strongly as evidence builds.
  • Protects the customer experience: short-lived price locks stop a returning customer seeing a different price during the same decision window.

What we delivered

The build centred on the operational pieces the client needed to run dynamic pricing inside the existing product, not as a separate demo.

  • Pricing endpoint Integrated with the existing API so the client can request the price to show for a specific event and context.
  • Demand model Scores candidate prices against current context and returns the bounded recommendation with the strongest expected revenue.
  • Postgres data model Stores every price shown, the outcome, model state, and short-lived price locks for repeat visitors.
  • Monitoring dashboard Shows learning progress, revenue performance, experiment status, and the active limits the business controls.

How value is measured

Dynamic pricing is only useful if it improves the commercial result. The measurement plan is an A/B test. One group sees standard pricing and the other sees dynamic pricing. The revenue difference between the groups is the measured uplift.

The timing of that test matters. Running it before enough sales accumulate would understate the value of the system because the model would still be learning. The delivered dashboard gives the client the view needed to monitor learning progress, performance, and when the test is ready to run with a reliable read.

Pricing inputs stock, capacity, event timing, sales velocity
Decision mode bounded dynamic price per request
Learning method Thompson sampling
Data capture price shown plus sale or no-sale outcome
Value test standard pricing vs dynamic pricing A/B test

The practical change is that pricing becomes an instrumented decision, not a rule somebody has to keep revisiting manually. Every request creates a price, a control record, and a learning signal for the next decision.