The storefront was never the hard part: four independent rules all had to resolve into one cart before a customer could be shown a price.
7 / 14 / 30
Day plan lengths
each priced separately
5
Ingredient exclusions
per customer, per order
1 pt / $1
Rewards programme
plus referrals
The problem
Customers pick a plan length of 7, 14 or 30 days, set up to five ingredient exclusions, and can only order at all if their ZIP code is in the delivery area. On top of that sits a points-based rewards and referral programme.
Each of those is simple alone. Together they are a pricing and availability problem that has to resolve before a customer can be shown anything, and getting it wrong means quoting a price for a meal you cannot deliver or cannot make.
What we did
Built on Next.js and React with a Node backend. The work started with the subscription and cart model rather than with the storefront, because the storefront is downstream of it: plan length, exclusions, delivery eligibility and reward balance all feed the same state.
That covers checkout and the account area where customers manage their preferences and track orders, which is where a subscription product actually lives after the first purchase.
The outcome
Plan length, exclusions, delivery area and rewards resolve into a single cart and subscription state, and customers manage their own preferences from the account area afterwards.
Frontend
Backend
Commerce
What we learned
When several rules interact, model the state before building the interface. A storefront built first will encode the rules by accident, in the wrong place, several times.
Check deliverability before you quote. Showing an unavailable price is a worse experience than one extra question.
Thirty minutes with the engineer who would lead the project. You will leave with an opinion on what to build, what to skip, and roughly what it costs, whether or not you hire us.
2 build slots open · Next start: early next month
What happens next