How would you choose an architecture for a recurring-order web app?

November 14, 2026 5 answers
Asked by u58+keyhole_306

I'm planning a larger freelance project for a company that currently manages thousands of customers through spreadsheets and phone calls. It needs accounts, recurring orders, payments and admin pages, with fulfillment and delivery requirements still to be worked out.

My background is mostly PHP and MySQL, but I'm less experienced with server provisioning and maintenance. Would a PHP app on AWS make sense, or should I look at a managed platform instead?

Answers

w218~addrgate_3

I'd start with the fulfillment conversation, not the hosting diagram. Find out how recurring orders are scheduled, what happens when a payment fails, who changes an order, and how delivery staff get the information they need. Those answers could change the shape of the whole project.

Also pin down what has to be in the first release and what can wait. A customer count alone doesn't tell you much about traffic or operational complexity. Ask about expected order volumes and busy periods before sizing infrastructure.

u58+keyhole_306:

Fulfillment and delivery are still open questions, so those are going on the requirements list before I commit to a stack.

Reply to this answer
6c+sparehinge_73

Take a serious look at Shopify before building the commerce side yourself. Products, orders and payments are already part of the platform, though you'll need to check whether its recurring-order options and any extensions fit the actual workflow.

Don't assume it's just a frontend job either. Scheduling and fulfillment might need customization or a separate app. Check the limitations and costs against the requirements, and make the contract clear about what's included and how platform outages are handled.

p908!doorstop_6:

That comparison is worth doing even if the conclusion is a custom app. The delivery workflow could be the deciding factor.

Reply to this answer
w204__spoolclip_8

A PHP app with a managed database and Stripe is a reasonable option if the business rules call for custom software. Familiarity counts here. I'd favor managed hosting or a server management service over maintaining a bare server yourself, even if the monthly bill is higher.

Budget time for deployments, backups and restore tests, monitoring, security updates and payment webhook handling. Laravel Forge may be worth evaluating for server management, but it doesn't remove the need to understand who is responsible when something breaks.

Reply to this answer
a.39!tagboard_7

A single EC2 instance plus RDS can be a straightforward starting point, but that one app server is also a potential point of failure. Decide what downtime the client can tolerate and how quickly you need to restore service before promising availability.

For deployments, use a repeatable process with a rollback plan rather than manually pulling the main branch on the live server. CodeDeploy is one option if you're already comfortable with it.

Reply to this answer
_c82+valvecase

Cloudflare Workers and D1 are worth evaluating if you want to avoid managing servers, but I wouldn't pick them just because the smaller sites are already there. Check whether the application framework, database needs, background work and operational limits fit the order and payment workflows you discover.

Compare that learning and migration effort with a managed PHP setup you already know. The simplest choice is the one you can build and support for this client, not necessarily the one with the fewest services on a diagram.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions