At work: Head of Engineering 2025-now
Pricing, offers and rule engines
Right offers, rates and monthly payment plans on every customer site, set by staff rules
Decides which offers and monthly payments each customer site shows, from makers' programs and staff rules, with exact money math.
- Role
- Creator and main developer
- Years
- 2025-now
- Scope
- Offers, rates, payment plans, rules
- Used by
- Customer staff and their websites
01 The problem
Prices and offers change all the time and come from many places: makers' programs, staff edits and bulk rules. A wrong number on a public site costs trust, and staff edits must not be lost on the next import.
02 Result
- Makers' new programs arrive daily with no manual entry, and staff edits are never lost.
- Staff set prices and offers for many items with one rule, not one by one.
- Public sites show monthly payments with the shopper's own down payment.
03 What I built
- 01
Offers engine
Walks ordered rules to pick the cheapest in-stock offers for each site. If a stock count fails, offers freeze and nothing is deleted.
- 02
Monthly payment plans engine
Shows correct monthly payment plans on customer sites, and also works backward from a monthly budget to a price.
- 03
Bulk rule engine
Staff write 'if this, then that' rules that change many items at once, and each rule is explained back in plain English.
- 04
Rate finder
Works out the makers' rates from their published monthly payments with exact fraction math, and keeps a rate only when exactly one answer fits.
- 05
Around the offers
Product bundles in their own service, and banners and videos made from design templates.
04 Why it was hard
- 01
Staff edits locked
Makers' programs sync every day. Each part, field or single table cell that staff edited is locked, and the sync fills in only the rest.
- 02
Exact money math
Each rate is rounded by its own fixed rule, and an exact copy of the makers' calculator math is used to test the rate finder.
- 03
Rules into search queries
Include, exclude and range rules from staff turn into one search, and a rule that cannot be read never matches every item by mistake.
- 04
Rule preview and ranking
Staff see how many items a rule will touch before it goes live, and ranking rules can pick the best few items in a group.
05 Risks I handled
- Risk 01
Paid AI calls
Offers use paid AI for headlines and pictures, and a retry could pay twice. Paid AI calls are never retried, so a customer is never billed twice.
- Risk 02
Updates during a refresh
An update could arrive while an offer refresh is running and get lost. Now it marks the customer for one more run at the end, so no update is lost and no work is doubled.
- Risk 03
Wrong pick on live sites
A bad final pick could reach public sites. The whole pick runs first in memory and only offers that would really show are imported. Fine print is filled from templates that match the offer numbers.
06 Stack
- Python
- FastAPI
- PostgreSQL
- OpenSearch
- Redis
- Celery
- Kafka
07 How it works
- 01Makers' programs and staff rules come in.
- 02Rules run in a fixed order.
- 03Engines work out the offer, rate and monthly payment.
- 04Sites read the result from fast search.
Get in touch.
Hiring an engineering lead, or building a platform or AI agents? Tell me about it.