Michael BILLING CHANGES. APP ACCESS. ONE WORKFLOW. Plan a test ↗
PRIVATE PROTOTYPE / TEST MODE ONLY

SUBSCRIPTION WORKFLOWS FOR DEVELOPERS

Meet Michael.
Keep access
in sync.

A prototype for keeping subscriptions and app access in sync. Built for indie Next.js developers.

Explore the workflow See the code ↗

A hands-on browser illustration. No account, keys or payments.

Example workspaceSYNTHETIC
Your appVerified identity
MichaelState + recovery
StripePayment provider
invoice.paidRecord the event. Refresh the facts.
TEST
PREMIUM FEATUREGranted
ReceiptWorkerFresh factsAccess
Ready

Synthetic illustration. No provider connection.

01 / SUBSCRIPTION → APP ACCESS

Change the state.
See the decision.

Try a lifecycle change. Your app's example response updates instantly.

Synthetic demo · No API calls, connection or payments.

SIMULATED SUBSCRIPTIONsub_demo_018
Choose a lifecycle state
Think membership card

Your app is the venue. Subscription facts are the membership card. The access check helps your server decide whether to open the door.

WHAT YOUR APP COULD SEE DEMO DATA
?
SUBSCRIPTION STATUS

Select a state

The example response will appear here.

PREMIUM ACCESSNot checked
—
Inspect the synthetic event
EVENT LOGWAITING FOR INPUT
Choose a state above to simulate an event
No event has been simulated.

Test policy: past-due and stale facts deny access. Scheduled cancellation can retain access through the eligible paid period.

02 / FAILURE IS PART OF THE WORKFLOW

Break it.
Then recover it.

Deliver twice. Fail a worker. Replay the job. Every counter below is synthetic.

Enable JavaScript to run this synthetic example

Illustrates policy. It does not verify a Stripe signature, run a real worker, or claim a payment succeeded.

03 / YOUR SERVER STAYS IN CONTROL

One integration shape.
Server-side first.

Your server verifies the customer, creates checkout and asks about feature access. Stripe remains the payment provider.

Local, unpublished TypeScript SDK

Real local method names, shown as excerpts. The site executes no API call. Real Stripe sandbox validation is pending.

Michael keeps the existing FlowAPI and @flowapi/sdk interface names for compatibility.

↳ Keep server keys out of client components.

Explore what's supported →
app/actions/billing.ts
Server-only SDK examples load with JavaScript. Never put a server secret in a client component.
Server action · authenticated customer identity

04 / GO A LITTLE DEEPER

Less mystery.
More working examples.

Compare the current scope, or watch a short Node.js lesson. Open only what you need.

Which workflows are in scope?Explore provider and payment boundaries.

There is no provider connection or credential input on this page.

HONEST SUPPORT STATUS

Stripe subscriptions — local test prototype

Local checkout, verified-event intake and feature checks exist with provider doubles. Real sandbox validation remains pending. Enable JavaScript to compare workflows.

    One event. Two deliveries.A 43-second silent, captioned Node.js lesson.

    Duplicate webhooks and the limits of memory-only deduplication. Generated fixtures, not real payments or a production recipe.

    Archived FlowAPI teaching draft, recorded before the Michael branding. Silent; narration and public publication are not included.

    Next.js + Supabase Auth reference exists locally. Clerk and other providers are later work.

    05 / START SMALL. LEARN SOMETHING REAL.

    Your next step?
    A clearer plan.

    Choose one app, one subscription plan and one gated feature. Prepare a private test brief, or save the general checklist.

    A planning resource. No signup or information is submitted.

    Public contact setup is pending before invitations open.

    Private test prototype

    Self-hosted PostgreSQL. Workflows tested with synthetic events. Real payment sandbox, security and operations reviews are still in progress.

    © Michael · early prototype.

    Build your private test brief

    Your answers stay on this page until you save a file. Nothing is submitted or saved to the CRM. Keep credentials and customer information out.

    Start with synthetic data. This does not request access or book a pilot.

    YOUR FIRST SANDBOX SCENARIO
    1. 01Map the customer and feature.
    2. 02Simulate a subscription change.
    3. 03Check the resulting app access.
    4. 04Fail, recover, and inspect the trail.
    Read the checklist here
    1. Choose one app, one subscription plan, and one gated feature.
    2. Describe how your server verifies customer identity.
    3. List activation, cancellation, past-due, duplicate-event, and recovery scenarios.
    4. Use fake facts first. A real sandbox needs authorized setup and reviewed permissions.
    5. Agree what a successful test should demonstrate and what would still be missing.
    6. Keep production data, live payments, and credentials out of discovery notes.

    Before you wire anything up

    What does Michael handle alongside Stripe?

    Stripe processes payments and sends subscription events. Michael focuses on the workflow between billing events and app access. Its private backend runs in fake mode. A Stripe-test implementation exists locally; real sandbox validation is pending.

    Where is the backend data stored?

    Michael uses its own self-hosted PostgreSQL database. No Supabase account is needed for Michael’s database. Supabase Auth is used in the local customer reference, not as Michael persistence.

    Does this demo take a payment?

    No. It changes local example content in your browser. There is no Stripe connection, checkout, account creation, or data submission.

    When will Michael be available?

    There is no promised launch date. The private console is for owner access; real sandbox verification is still pending. A private pilot depends on implementation, security review, and external configuration.