A quick demo site usually eats an afternoon, and the build is maybe a third of it. The rest goes to the signup form, the verification email, the plan picker, and a second tab at a registrar, because each of those lives in a different dashboard.
WordPress.com is aiming at exactly that with its new Stripe Projects integration. From the terminal you can provision a site, register a domain, and activate a plan, all billed to the payment method Stripe already has on file. WordPress.com announced the provider on its blog. The whole flow is two commands.
I’d use it, with a few limits in mind. It provisions a site and then stops: the plan you pick mid-prompt, the card it bills, and the empty install you’re handed are still your problem. That’s fine for some jobs and not for others.
What the WordPress.com Stripe Projects commands do
With a Stripe account, the Projects CLI installed, and a project set up, the commands are:
stripe projects add wordpress.com/site
stripe projects add wordpress.com/domainThe site command walks you through plan options, including a free one, then creates the site and bills it to the payment method on file. The domain command takes a query or an exact name, shows 15 suggestions, and registers the one you pick the same way. If you don’t have a WordPress.com account, one gets created and linked to your Stripe account during the flow. That’s the part that makes this feel fast: you never open a browser, verify an email, or log in to a registrar.
For a throwaway site, that’s the entire value, and it delivers.
Where the workflow stops
The first limit is the plan. A free WordPress.com site is a real install with real restrictions: uploading your own plugins and themes only opens up on the Business tier, which you can check against the current limits on the WordPress.com pricing page. So the announcement’s line about a production-ready site in one command holds only if you pick a paid plan partway through the prompt. Decide the tier before you run the command, not while it’s waiting on your answer.
The second limit is billing and ownership. The site bills to your Stripe payment method, and the account created for you is linked to your Stripe account. That’s fine for your own demos, but it’s backwards for client work, where the client should own the site and the subscription from day one. Site and billing can be transferred later, but the transfer is dashboard work, so you hand back a lot of what the CLI saved you. I haven’t run a transfer on a Stripe-provisioned site yet, so I’d treat that as the open question before promising this flow to a client.
The third limit is that nothing deploys. You get an empty WordPress install. The part that makes a build repeatable, installing your theme, your plugins, and your settings, still runs through the REST API or WP-CLI, or through WordPress.com’s developer tools like GitHub Deployments on a Business site. Provisioning is a small slice of any real project, and if the script ends at an empty site, you’ve automated the easiest ten minutes of it.
And if your clients run self-hosted WordPress, none of this touches their servers. Which WordPress.com features reach a self-hosted site is a separate question, and this one lands only on the hosted side.
Where I’d use it
For me the fit is demos, sandboxes, and internal experiments, places where speed matters and ownership doesn’t. It’s also a decent test bed for agents, since a workflow that stands up a real site and a real domain without anyone clicking through a signup tells you a lot about what the agent can finish alone. Remember that the command carries your billing. If an agent is allowed to run it, it deserves the same guardrails as anything else that spends money, along the same lines as what agents should be allowed to run against client sites in the first place.
For client production sites I’d still provision the ordinary way: the client’s account, the client’s card, or an agency arrangement where ownership and billing are answered in advance. The Stripe flow solves setup friction, and setup friction was never the expensive part of a client build.
If you want a hand with the unglamorous half of this, scripting the post-provision setup with WP-CLI or getting billing and ownership straight before a handover, that’s work I do.
If you have a Stripe account, install the Projects CLI from projects.dev and run the site command with the free plan. Time how far you get before you need a browser. That number decides whether it belongs in your workflow.
