What a ?prototype=1 Flag Could Not Protect in Our Checkout

Near 1 a.m., the checkout page was the only bright thing in the room. We had been changing it since 6:30 that evening, and by then we had made 23 small saved changes. A card lifted a little when a pointer passed over it. A missing category picture showed a readable label instead of a broken icon. One option wore a small “MOST POPULAR” ribbon.

Those changes were satisfying because we could see them right away. The number at the bottom of the page was different. It had to be right before anyone could pay.

Two costs on one screen

The old checkout put two different costs on one screen: the monthly membership and the price of running one event. The redesign needed to separate them without throwing away the existing way that payment happens.

We did not start by replacing the live page. We used a query-string flag, which is just a small extra note added to the end of a web address. With ?prototype=1 on the address, we could see the new checkout. Without it, the old checkout stayed in place. It was like putting a new sample kitchen behind a staff-only door while the old kitchen kept serving dinner.

That gave us a place to work and let controlled reviewers see the new layout. Hiding it from the normal page did not make it safe, though. A different door does not change what happens in the same kitchen underneath it. The temporary view still needed proper access limits, a person responsible for it, and a clear point when it would either become the real thing or be taken away.

The part that took hours

At first, we worked on what was easiest to judge with our eyes. The ribbon, the softer unpaid badges, the hover effect and the empty state all moved forward in small pieces. Many of those visual changes took minutes. The hours went into making two different kinds of charges add up correctly in the same purchase.

We only understood that by being wrong about it. The new page showed the full balance in the bar at the bottom, and the check we had been given said everything was wired up correctly. We took that to mean the pay button led to a page that agreed, so we treated the page as good enough and moved on to the next screen. Then we clicked pay and it said the total was zero. The checkout page read its numbers from a record that the new cart never wrote to, so it had no idea what we were buying.

A customer could be buying a monthly membership and paying for an event at the same time. The new event cart could not simply replace the older membership path. Both needed to feed one order, one final total, and the existing handoff where payment happens. The membership also involved real proration, meaning the price needed to account for the part of a billing period already used. A made-up number would have looked fine on the screen and been wrong where it mattered.

Think of a grocery cart at the kitchen table. One person has a recurring pantry delivery and a one-time birthday cake in the same cart. The receipt still has to show one total that is correct. You cannot decide that the cake total is close enough because the box has a nice ribbon on it.

The page could show two paths at once, but the two paths still had to share the same money math. The web-address trick separated what people could see. It did not separate the work underneath. Before the new version could ever be used more broadly, the expected totals and the different account situations had to be checked, along with the point where payment passes from the cart to the existing checkout.

Why the 23 small changes still mattered

They made the work easier to inspect. If the card lift felt wrong, we could remove that one change without touching the price work. If the image fallback caused trouble, we could find the small change that introduced it. Weeks later, a question about why a toggle was arranged a certain way would have a real answer instead of a vague memory of a late night.

Ending the night with a written record

We also did not want the temporary view to become permanent merely because it was there. So the night ended with a written record instead of another visual tweak. We wrote down how different account situations should be handled, what capacity warnings were needed, what a downgrade should do, why this direction had been chosen, and what other choices had been considered. The record also named the assumptions behind putting it into use and the conditions that would mean the temporary path needed to be revisited or removed.

That part sounds less exciting than a shiny new checkout card. It is what keeps a useful experiment from becoming a permanent promise. A temporary path needs an owner and an exit plan, because memory is a poor system for keeping a promise.

The zero at the bottom cost more hours than all 23 small changes combined. The ribbon, the hover lift and the image fallback could each be judged by eye and removed one at a time. The zero could only be caught by pressing pay and watching the handoff.

If someone builds you a redesigned checkout, do not call it finished because it looks right. Ask them to show that the totals for membership proration and event charges come out correctly through the handoff to payment. And give any flagged preview an owner and a written condition for when it becomes the real page or is removed.

dxdev LESSON · paste into your AI coding agent
LESSON: A prototype behind a query-string flag is still a live purchase path that has to add up
SOURCE: dxdev.com/everyday-ai/number-at-the-bottom-of-the-checkout
WHAT HAPPENED: A checkout redesign was built behind a query-string flag so visual changes could be reviewed without touching the live page. The visual work was straightforward; the real difficulty was making a new event-purchase cart and the existing membership and proration logic feed one correct total into the existing payment handoff. A false confidence moment: the new checkout displayed a full total and appeared wired up correctly, but clicking pay charged nothing, because the payment step read its numbers from a record the new cart had never written to.
THE RULE: Hiding a redesign behind a flag controls who sees it, it doesn't separate the underlying money or data logic from the live system. Before trusting a new purchase flow, verify the actual payment step reads from the same record the new UI writes to, not just that the displayed total looks right.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any feature-flagged or prototype checkout or purchase flow where the displayed total and the actual charge are computed from different data sources; verify they are the same record.
  2. Any UI element, a total or a badge, presented as evidence a feature works without confirming the value all the way through to the actual transaction it precedes.
  3. Any temporary or prototype code path, such as a query-string flag, with no written owner, exit plan, or condition for becoming permanent or being removed.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.