Shopify vs Stripe Checkout: build with Opus

Have Claude Opus build your shop and use Stripe Checkout for payment. That's the route I recommend over starting with Shopify. Your shop should sell the way your business works: the product choices, the pickup rules, the details you need before making the order. Start there, rather than hoping those things fit a theme later.

Let the agent handle the implementation. Give the payment job to a payment service. Keep the site and the business-specific rules in your own project.

Shopify offers a lot. I still prefer building the thing you actually need, particularly when the website is more than a catalogue with a checkout attached.

Design the buying journey before the product grid

Imagine a bakery taking orders for celebration cakes. The customer needs to understand portions, choose a collection date, see the notice period and tell you what to write on the cake. A product photo and a quantity box don't explain the whole purchase.

Give Opus those requirements. Ask it to design the journey: make the size choices understandable, show the collection rules before checkout and collect the details the baker needs. Then have it build the pages, validation, order record and confirmation around that journey.

That's the argument for custom work. Your requirements drive the implementation. You don't have to reduce the business to whichever fields were easiest to put in the first template you tried.

This is a build brief, not a claim that Shopify cannot sell cakes. Shopify can be configured and extended too. I would rather commission the specific experience through the agent than start by adapting the business to a general-purpose storefront.

Path C is the store brief. The quality of what you tell Opus about the business matters as much here as it does in the main design brief.

Opus builds the shop. Stripe takes the payment.

Keep this division of labour clear. You want custom product pages and sensible order handling. You do not need a homemade form collecting card numbers.

Stripe Checkout supports a Stripe-hosted payment page. The site can send the customer there to pay, then handle the result. That's the approach this guide uses.

Opus, working through Claude Code, handles the project implementation: the storefront, the connection to checkout and the order workflow. Claude Code can edit files and run commands; your brief tells it what to build and the setup gives it the appropriate access. You still approve business decisions, supply correct information and check the finished flow.

I like this arrangement because the buying experience remains yours while a specialist handles payment entry. The point of having an agent isn't to rebuild every service on the internet. It's to make the services work together for your business.

Put your rules in the brief

“Add a store” leaves too much unsaid. Write down what a real order involves, including the awkward ones.

These are examples, not a checklist of features every shop should pay to build. Tell Opus which rules apply. Ask it to flag complexity and agree the approach before implementing something that changes how orders work.

For a frequently changing catalogue, add Path B's CMS. Staff can edit products in fields while the agent handles design and feature changes. Be explicit about the distinction: a Products collection manages content; stock, orders and refunds need their own working logic.

The benefit is a system shaped around your shop, not a bigger list of switches.

Keep improving the shop through prompts

Once the project exists, you can ask for changes in business language.

“The product page isn't explaining which size feeds twelve people.” “Show the collection deadline before they start choosing.” “Add a wholesale enquiry route that asks different questions from the retail form.”

Those requests may change several pages and bits of logic. Opus can work across the codebase to implement them, with a preview for you to check. You don't have to become the person who knows where every setting lives.

Keep the source in your GitHub account and the design decisions documented. If you later need another agent or a developer, there is a project to work on. That matters when the site grows beyond the first small catalogue.

Custom code doesn't make a complicated feature cheap by definition. It gives you control over what gets built and how it fits. That's why I favour this route. The after-launch workflow is part of the value, not an afterthought once the first payment lands.

Compare the real bill, not just the checkout fee

Stripe includes Checkout with its standard payments pricing. That is no additional Checkout charge under that arrangement, not free payment processing or a free complete shop. Fees depend on your location, payment methods and services used.

Shopify's pricing covers a store platform, with features and charges depending on the plan and region. Count its subscription, relevant payment fees and any apps or other services you need. Don't compare all of that with a single Stripe processing percentage and call it research.

For the custom route, count the domain, hosting, agent usage, email or other services, initial implementation and maintenance alongside payment fees. Check the guide's stack, then use current provider prices for your budget.

My recommendation doesn't depend on pretending every custom shop costs less. I'm favouring a site built around the business, with the implementation in your account and a direct way to keep improving it. That is worth comparing with the full platform bill.

Make the agent prove the order works

Taking payment is not the end of the job. The shop has to know what happened and give the right person the right instructions.

Stripe's fulfilment documentation calls for webhooks and safe handling of repeated fulfilment calls. In plain English, the payment service sends your site an event. The site must check it and record the order without treating a repeat message as a second purchase. Payment methods that complete later need the appropriate handling too.

Don't accept “the success page appeared” as the whole test. Have Opus demonstrate:

1. A successful payment creates one correct paid order.
2. A declined or abandoned payment doesn't become a paid order.
3. Closing the browser after paying doesn't lose the order.
4. A repeated payment event doesn't duplicate fulfilment.
5. Stock, dates and custom information survive the whole journey.
6. Staff can find the order, and the customer gets the right confirmation.
7. A refund leaves understandable records.

Ask it to test on staging with test payments, show you the results and fix failures before launch. You review the buying experience and the business facts. The agent does the implementation and checks. Forms and email and the launch process belong in that brief.

The reason you might still choose Shopify

Shopify's established store tools can earn their place when the business already depends on them: a large changing catalogue, staff workflows, in-person selling or integrations you would otherwise have to replace. Test those dependencies before moving an existing shop. A checkout component is not a replacement for every retail operation.

That concession doesn't change where I'd start a new, deliberately custom shop. I'd start with Opus, a clear brief and Stripe Checkout. Build the pieces the business needs, use established services where they make sense and keep the result under your control. Budget for updates and support; an agent is a way to do the work, not a promise that no work remains.

Start with your shop, not somebody else's template

Write down what you sell, how people choose it, how it reaches them and what staff do after payment. Gather the real product photos. Be specific about the buying experience you want.

Then set up the agent and use Path C's store prompt. Add a CMS if staff need to manage the catalogue. Make the test order work before accepting a real one.

The recommendation is simple: let Opus build your shop, let Stripe handle payment entry, and keep building on a project you control.