Your customers didn’t pay to be your QA department

Your customers didn’t pay to be your QA department.

Imagine paying for an app, getting the receipt, and discovering that your account still says you need to upgrade. You try again. Then you check your bank. Then you spend your lunch break explaining the problem to the company that already took your money.

From the company’s side, that might be a ticket in the backlog. From your side, you paid for a service and got an errand.

This is an illustrative scenario, not a story about a particular client. It is also the kind of failure a founder should want to see before launch, while fixing it is still an internal conversation.

Small scope is reasonable. A broken promise isn’t.

I like a small first release. It gives a business a chance to learn whether anyone wants the product before paying to build every imagined feature. A basic interface, a limited catalogue or a clearly explained manual setup step can all be sensible choices.

But if the offer says customers can pay and start using the service, that whole journey belongs in the first release. Taking payment is only one part of it.

The founder can postpone a dashboard. The customer cannot postpone needing the thing they bought. Calling the product an MVP does not make that difference disappear.

There is a fair way to run an early pilot: explain the limits, agree what participants will try, give them a real support route and set expectations about recovery. People who knowingly join that experiment are in a different position from buyers who were promised a working service.

The industry is racing to make buying easier

In its September 29, 2026 Link announcement, Stripe described new help for shopping agents to handle checkout obstacles, including payment verification and changed totals. It also announced purchase protection for certain agent mistakes. These are vendor announcements about specific capabilities, not evidence that every AI shopping journey is dependable.

The direction is interesting: software is doing more of the buying on our behalf. My concern is what happens after the payment. An easier purchase can still lead to a locked account, a missing order or a customer who has no idea whether anything worked.

That gap deserves attention whether your product uses AI, a conventional web app or a mixture of both.

A receipt is not proof that the product works

In the paid-account example, the checkout and the application have to agree about what happened. One system recording a payment does not, by itself, prove that the right account received the right access.

Stripe’s fulfilment documentation describes a concrete trap: customers can pay and lose their connection before the return page loads. For automated fulfilment, it calls for server-side payment events rather than relying only on that page. It also requires the fulfilment logic to tolerate repeated calls for the same payment.

The buyer does not need to understand that plumbing. They need the product team to have tested what happens when the browser closes at an inconvenient moment.

For this example, I would want a demonstration using a test payment and an ordinary customer account. Complete the purchase, interrupt the return to the app, and come back later. Check the payment record, account access and customer message. Then repeat the relevant notification and check that it does not create a second fulfilment.

That test will not prove the entire product is reliable. It can expose a serious gap in one promise you are about to sell.

Test what customers stand to lose

Start with the journeys where failure costs someone money, access, saved work or a commitment they made to another person. For a booking product, that could mean paying for a slot that was never reserved. For a document tool, it could mean returning to work that was never saved. Choose the tests around your actual product.

Use a normal account with normal permissions. Include returning users and realistic mobile conditions. A developer who is already signed in as an administrator can miss the point where a customer gets stuck.

Ask the person doing the test to record the outcome, not just that they clicked the button. A green confirmation should correspond to something you can verify: a saved record, a reserved appointment, an entitlement or a completed delivery.

Also decide how the team will notice a mismatch and who can put it right. If a purchase succeeds but access fails, support needs enough information and an approved recovery action. Asking the customer to keep retrying can make an unclear situation worse.

No, you cannot test every possible failure

Software will have defects. Providers will fail. Tests can miss things. Pretending otherwise would be a strange sales pitch from someone offering to fix software.

The reasonable standard is to check the important promises, make known limits visible and have a workable response when something goes wrong. A cosmetic defect and a customer losing paid access do not deserve the same launch priority.

AI can help generate test cases and automate checks. It can also generate a test that faithfully confirms the same wrong assumption as the code. Someone still needs to compare the result with what the customer was promised. Faster development makes that judgment more valuable, because more changes can reach people in less time.

Customer feedback should teach you what to improve. It should not be your first evidence that the basic purchase journey was never checked.

Bring us the journey you’re nervous about

At Rosecraft, we build and improve web applications and customer-facing products. A focused review can start with one journey: sign up, pay, book, upload, save or return. We can agree what should happen, investigate where it breaks and scope the work needed to fix it.

Ready to hear what needs fixing before a paying customer has to tell you? Send us the journey that worries you, what you promised the customer and where the uncertainty is. Describe the issue without sending passwords or customer records. If a smaller release is the honest answer, we will say so.

Your customers can help shape the product. They should not have to fight it just to receive what you sold them.