The problem
Proxy plans vary across several dimensions at once — type, location, bandwidth allowance and subscription term — and every combination is a different price. A customer who is shown all of them at once cannot choose, and a customer who is shown too few cannot find what they came for.
The second constraint is delivery. This is a market where customers expect access immediately after payment, at any hour, and a delay converts directly into a support ticket.
What I built
A plan selection flow that narrows by one dimension at a time and never presents a combination that cannot be sold, backed by a schema that treats a configuration as a first-class row rather than a variant bolted onto a product.
An automated checkout and fulfilment flow, so payment confirmation and access are one sequence rather than two steps with a person in the middle.
A lean front end in Tailwind CSS on PHP and MySQL, sized to run on the shared hosting the business already pays for rather than requiring an infrastructure upgrade to sell a $10 plan.
Decisions worth explaining
The catalogue model was written down before any interface was designed. That is the step most stores skip, and it is the one that decides whether the site can carry the business in a year.
Nothing was reused wholesale from the earlier proxy build. The pattern transferred; the code did not, because the two businesses price and package differently and a shared template would have forced both into the same shape.
Want something like this?
If you are looking at this because you need the same thing built, send me the brief. You will get a reply within one business day and a fixed-scope quote before anything starts.