REEZN
Log inGet started
●  See it working

Read a real blueprint.

Below is a complete example of what REEZN hands a team: the ask exactly as product wrote it, the blueprint the AI drafted from it, the review that pushed back, and the sign-offs that gate delivery. Read it the way a reviewer would. The things worth noticing are flagged along the way.

The ask · written by product, in plain language
Guest checkout

Let shoppers complete a purchase without creating an account. We are losing carts at the sign-up wall, and the drop is worst on mobile. Offer account creation after the order instead of before it.

In scope
Card payments. Mobile and desktop web.
Out of scope
Loyalty points for guests. Saved addresses.
Acceptance criteria
  • AC-1 A shopper completes checkout without registering, providing only email, shipping, and payment.
  • AC-2 The guest order confirmation email includes a tracking link that works without logging in.
  • AC-3 After purchase, the shopper can convert the guest order into an account in one step, and the order attaches to it.
  • AC-4 Guest checkout conversion is tracked separately from registered checkout.
AI drafts the analysis, the team approves it, and each service gets a blueprint. This one is for checkout-service.
Blueprint · Guest checkout · checkout-service · v1Awaiting approval

Guest Checkout

01Requirements

Shoppers must be able to complete a purchase providing only an email address, shipping details, and payment, with no account creation before or during checkout. Guest orders remain fully trackable without a login, and a guest can promote their order into an account in a single post-purchase step. The business goal is recovering the checkout conversion currently lost at the sign-up wall, which the analysis identifies as most acute on mobile.

Assumption: returning shoppers who have an account but are not signed in may also check out as guests. The ask does not specify this; it is stated here so a reviewer can confirm or correct it.

NoticeWhere the ask was silent, the AI guessed, and said so. Correcting a written guess takes seconds; finding a buried one takes a production incident.
PSPriya SharmaProductResolved
Does "email only" conflict with the marketing-consent checkbox legal wants on every email capture?
Jonas Weber · Tech lead
No conflict: consent is a separate optional checkbox and its absence never blocks checkout. Added under Operations, task 2.

02Entities

Order and Cart already exist in checkout-service and are extended, not forked. GuestSession and OrderAccessToken are new.

Rendered from the blueprint's entity diagram. New entities are drafted alongside the ones that already exist in checkout-service.

03Approach

1. Guest identity as a short-lived session, not a shadow account:

  • A GuestSession keyed by email is created when guest checkout starts and expires after 30 days. No password, no account row, so there is no half-registered account state to clean up later.
  • Post-purchase conversion (AC-3) promotes guest orders to the new account by verified email match, never by token possession.

2. Technical implementation in checkout-service:

  • Extend the existing POST /checkout path to accept a guest session: shopperId becomes nullable on Order with a new guestSessionId, and a database constraint enforces exactly one owner.
  • Order tracking links (AC-2) use signed, single-purpose access tokens scoped to one order, stored hashed, expiring with the session. The token grants read access to that order only, never to an account.
  • Payment reuses the existing Stripe Elements tokenization path unchanged. The guest flow introduces no new payment surface.

3. Business rules:

  • Guest checkout is rate-limited per email and IP to blunt card-testing abuse, mirroring the limits already applied to registered checkout.
  • Checkout analytics events carry checkout_mode: guest or registered (AC-4), so conversion is comparable between the two paths.
AI Red TeamAdversarial reviewUnresolved · blocks approval
AC-3 says the order attaches to the new account, but the Approach converts by verified email match only. A shopper who used two different emails across guest orders will see partial history after converting. Either scope multi-email reconciliation into the definition or state it as a known limitation.
NoticeThis is the optional adversarial pass doing its job: a second AI attacking the plan before any code exists.

04Structure

checkout-service is a TypeScript and Express service backed by PostgreSQL. The change adds two focused components and extends one; nothing else in the service moves.

Component relationships

  • CheckoutController (extended): accepts guest or registered checkout and routes ownership accordingly.
  • GuestSessionRepository (new): creates and expires guest sessions.
  • OrderAccessTokenService (new): issues and verifies tracking tokens.
  • ConversionService (new): promotes guest orders to a newly created account after email verification.
  • OrderRepository, PaymentGateway (unchanged): reused as they exist today.

Dependencies

  • CheckoutController depends on GuestSessionRepository and the existing OrderRepository and PaymentGateway.
  • ConversionService depends on the accounts service email-verification flow, which already exists.
  • OrderAccessTokenService is used by the order-tracking endpoint and the confirmation-email composer.

05Operations

Extend the order model for guest ownership

WhatNullable shopperId, new guestSessionId, and a check constraint enforcing exactly one owner per order.
WhyAC-1: an order must be able to exist without a registered shopper.
HowOne reversible migration adding the column and constraint; ORM model and order queries updated to handle either owner.
ConstraintsBackward compatible: existing orders and all registered-checkout queries are untouched.

Create the guest checkout flow

WhatGuest session creation at checkout start and a guest branch through the existing POST /checkout path.
WhyAC-1: checkout completes with email, shipping, and payment only.
HowGuestSessionRepository with a 30-day TTL; CheckoutController resolves owner from session; the optional marketing-consent checkbox is captured but never blocks checkout.
ConstraintsThe Stripe Elements tokenization path is reused unchanged; no new payment surface (safeguard 1).

Tokenized order tracking

WhatA signed, order-scoped access token issued at order creation and embedded in the confirmation email link.
WhyAC-2: tracking must work without a login.
HowOrderAccessTokenService signs and hashes tokens; the tracking endpoint verifies against the hash and expiry; tokens are never written to logs.
ConstraintsToken grants read access to exactly one order; possession never converts into account access.

Post-purchase account conversion

WhatA one-step conversion from the order confirmation screen that creates an account and attaches the guest order.
WhyAC-3: guest orders convert to accounts in one step.
HowConversionService triggers the existing email-verification flow, then re-parents orders whose guest session email matches the verified address.
ConstraintsConversion is by verified email match only. Multi-email reconciliation is flagged in review and pending a scope decision.

Guest analytics and rate limiting

Whatcheckout_mode tagging on checkout events and per-email-plus-IP rate limits on the guest path.
WhyAC-4, and the card-testing abuse rule from the Approach.
HowExtend the existing analytics emitter and reuse the rate-limit middleware with a guest-specific bucket. Emails are hashed in analytics payloads.
ConstraintsEvent schema change is additive; existing dashboards keep working.
MCMaya ChenReviewerUnresolved · blocks approval
What happens when the cart expires mid-checkout? The guest session outlives the cart TTL, so a guest can return via the tracking link with a dead cart. Do we re-price and rebuild the PaymentIntent, or fail the checkout explicitly?

06Norms

  • API errors follow problem+json (org norm): both new endpoints return RFC 7807 problem details, matching the rest of checkout-service.
  • Reversible migrations (org norm): both schema changes ship with tested down migrations.
  • Checkout changes behind a feature flag (project norm): the entire guest path sits behind the guest_checkout flag, default off, so rollout is gradual and reversible.
NoticeNobody pasted these in. The team's standards and hard limits are applied to every blueprint automatically.

07Safeguards

  • PCI scope must not expand: card data never touches our servers. This blueprint reuses the existing Stripe Elements tokenization; no new component receives, logs, or stores card data. Any change to payment capture is out of bounds for this feature.
  • No PII in logs or analytics: guest emails are hashed in analytics events, and tracking tokens are never logged.
The sign-off
Priya SharmaProduct · Approved
Jonas WeberTech lead · Approved
Maya ChenReviewer · Reviewing
Approve · blocked by 2 open comments
NoticeApproval is blocked while review comments are open. That is the product working, not the example failing.
What happens when it clears

When Maya's comment is resolved and she approves, this blueprint stops being a document. REEZN's agent implements it in checkout-service, runs the test suite, and opens a pull request with a verification report the team approves like everything else. Here is how this one ends.

The verification report is approved by a human before the feature counts as delivered.
This example was produced with the same structure and rules REEZN uses in production. The team, service, and repos are fictional.

Want one of these for the scariest ticket in your backlog?

Describe the feature in plain language and review the blueprint in minutes. Free to get started, no card required, bring your own AI key.

Start freeExplore all features