Own the Stack

Historical Archive

Own the Stack

Historical record

Earlier launch and implementation detail

This section preserves the build history. The Current Status, Roadmap, and Recent Changes sections above are the source of truth for work that is active now.

Checked off today:
Safe no-card test path built and tested.
Server-capacity fallback built and tested.
Fresh workspace build marks the paid portal customer active and records real server details.
Cancellation events mark existing portal customers cancelled with a cancellation date; repeats and unknown customers are safe.
Cancellation policy resolved: the team closes the workspace manually at the end of the paid month; automation comes later.

Verified building blocks

  • Live Stripe checkout accepted real $50 payments.
  • GoHighLevel reached n8n after three real-payload mapping defects were corrected.
  • Automatic setup, the safe no-card test path, and the server-capacity fallback are built and tested.
  • Cancellation portal status: real cancellation events now mark an existing paid customer as cancelled with a cancel date, and do not create another workspace. Closing the workspace itself remains manual.
  • A fresh 6.1-minute test build created a paid portal customer record, marked it active, and recorded the real server details; the test workspace was cleaned up.
  • Customer-facing preview and team-choice entry points were removed from the production portal.

Launch blockers found in QA

  • Renewal: the route and repeat-payment safety are proven. A real scheduled renewal still needs observation; it must never create another workspace.
  • Client portal and access email: the October 11 purchase proved the portal link and sign-in instructions are missing from the customer emails. Publish and verify the portal-first access message; then a paid customer must sign in and see only that customer’s real workspace, billing, help path, and workspace launch button.
  • Tool connection: if Connect remains customer-facing, one supported tool must complete and appear in the portal.
Customer email map:
Sender: Support Team; Reply-To: help@kimiwalker.com. The old duplicate Welcome Email step was removed and the workflow was read back clean. New paid customer: 1. Automatic receipt — payment itself, within seconds; 2. Subscription active — first paid Own the Stack payment, within seconds; 3. Workspace ready — only after the workspace answers, its owner account exists, and monitoring is added, usually 5–7 minutes after payment. The October 11 purchase confirmed all three emails arrive from Support Team, but also exposed the missing portal URL and sign-in instructions. The complete live copy and proposed fix are in the customer-journey document. Failed payment: existing notice must be reviewed as the customer sees it. Cancellation received: published and test-sent. The team closes the workspace manually at the end of the paid month; automation comes later. Renewal: confirm whether a customer email is sent; its routing must first be proven without creating a workspace.
Next test gate: first approve and publish the portal-first customer access email, then verify the paid-customer portal journey and one customer tool connection. Keep real-renewal observation separate. Check every screen and email before calling this launch-ready. The Visual Readiness Map is in Documentation & Resources.
Latest project update

What is complete and what comes next

Team update — October 11, 2026. Real purchase QA is now the source of truth. Historical build proof remains recorded below; it does not override the current launch blockers.

Service infrastructure

  • Dr. Hall's workspace, monitoring, nightly backups, retention, and encryption-key recovery are documented as working.
  • Post-pilot security, monitoring, notification, backup-freshness, and OS security-update checks passed through 30 September.
  • Uptime Kuma email delivery, TLS certificate alerts, 26-hour backup-freshness alerts, and recovery notifications are verified.
  • Final manual provisioning and recovery runbook completed 09/22/2026.
  • Second recovery drill passed in 36 minutes 31 seconds, under the 60-minute target.
  • Claude completed automatic provisioning and connected the paid-payment trigger. Two clean workspace builds finished in 5.2 and 7.0 minutes with no human involved; an interrupted build resumed without duplicating work; a payment-triggered build finished in 5.7 minutes.

GHL sales and checkout

  • The Own the Stack product remains a $50 USD monthly recurring subscription attached to the published checkout.
  • The rebuilt checkout preserves Preferred Workspace Domain, Full Name, Email Address, and the required service-agreement checkbox.
  • The sales page now uses 9 focused sections. It leads with saved time and money, uses the original Own the Stack logo, and shows one simple automation example at a time in a swipeable carousel.
  • Verified 10/10/2026: the approved rebuild and its later checkout fixes are merged in the published funnel. The three live funnel pages—/start, /terms, and /welcome—are intact and serving.
  • The Automation Library is presented accurately as a growing set of starting points. Customers may choose a starting point, bring an existing workflow, or request custom help. No instant deployment or fixed implementation price is promised.
  • Technical customer-facing language and repetitive sections were removed. The published page was verified on desktop and mobile with no horizontal overflow, broken images, failed checkout links, or mobile-carousel sizing issues.
  • The $50 recurring purchase was completed in live mode on 10/03/2026. The page is live at start.ownthestack.io.
  • The agreement opens start.ownthestack.io/terms in a new tab. Successful checkout routes to the Payment Received page at /welcome.
  • Claude fixed the missing Full Name field and Start the Workspace button, then aligned the editor version of checkout with the live version.
  • The Own the Stack confirmation-email workflow is published. It triggers only on a successful Payment Received event for the Own the Stack product and sends from help@kimiwalker.com.
  • No testimonial is required for launch. The operating workspace, nightly backups, 60-second monitoring, customer portal, and documented recovery drill are the approved working-system proof.
  • The new Stripe account is verified, connected, and synced to the white-label GoHighLevel account. Its customer billing page is configured for card updates and end-of-period cancellation.
  • GoHighLevel now sends a standardized payment handoff to n8n. Successful and declined-card test events arrived with the customer name, email, preferred workspace domain, transaction ID, amount, product, and event type.
  • The sales page and the first historic $50 live purchase are complete. Claude confirmed 10/10/2026 that the public checkout is on the live Stripe connection and displays $50 monthly recurring. Declined payments now receive the ots-payment-failed tag. The notice workflow is published and live from Support Team <help@kimiwalker.com>. A declined card tags the contact, sends the notice, and clears the tag so a later decline can send again. A real cancellation event did not create another workspace. The cancellation notice and portal status are live. The team closes the workspace manually at the end of the paid month; automation comes later. A real renewal observation is also still open.
  • Own the Stack workflow messages will use help@kimiwalker.com. This is the approved shared sender decision.
Important correction: the customer-facing sales page, $50 product, service agreement, first live purchase, live checkout connection, manual provisioning runbook, recovery drill, workspace infrastructure, portal, automatic workspace setup, paid-payment trigger, and fleet-update rollout are complete. Claude built and proved the setup and update paths: two clean customer workspaces were created in 5.2 and 7.0 minutes without human intervention, an interrupted run resumed without duplicate work, a webhook payment event triggered a workspace build in 5.7 minutes, and a pinned n8n update was safely tested with rollback. Declined payments now receive the failure tag, and the customer notice is published and live from Support Team <help@kimiwalker.com>. Cancellation policy is decided: its notice email and portal status are live. The team closes the workspace manually at the end of the paid month; automation comes later. A real renewal observation is still open. The sender decision is complete: workflow messages use help@kimiwalker.com. Codex completed the paid-customer portal link: a payment creates the customer record, and a signed-in customer can attach only the paid record with the same email. The launch QA workspace has a real portal record and completed setup report. The client-connections service is complete. Unsupported portal controls now state plainly that no action was sent or created; the remaining customer proof is one completed supported-tool connection.
Client connections:

Operating and proven: the portal exposes 15 supported tools. Kimi connected GitHub in the portal, and the connection was used successfully from Kimi’s n8n through the isolated relay. The customer’s key stays inside Nango; neither n8n nor the team receives it.

New-workspace setup: new builds now create an isolated relay secret and an n8n credential named Own the Stack Connections. The first brand-new customer build remains a yellow verification item. Carl has a secret but no n8n credential yet because his workspace was left untouched; Dr. Hall has neither.

Portal controls: the Connect button and connected-tools list are protected by the signed-in portal session. The Team Connections view is also protected and does not expose customer connection data without a session.

Portal test monitors:

Passing — proven 12 October Eastern. The portal repository runs separate Playwright checks for the client and team portals every six hours, captures Puppeteer screenshots, and uploads the report artifact to GitHub. Each result reaches the Tech Hub through a protected token path; the dashboard stores the latest result privately and links to the GitHub run and its screenshots.

First live proof: GitHub run 38325785671 passed Client sign-in, Client Home, Automations, Team-admin sign-in, Fleet, Connections, screenshot capture, artifact upload, and both Tech Hub report posts. A failed real run reads Failed; a result older than the six-hour cadence also reads Failed.

Coordination snapshot — October 12:

Billing — Codex: the active Stripe subscription is linked to the correct portal client through metadata, and the renewal date is visible. The active work is fixing the separate portal invoice/receipt history and connecting manual GHL/FastPayDirect payment results to the correct client portal record.

Portal monitoring: passing. The six-hour Client and Team browser checks, screenshots, GitHub artifacts, and Tech Hub report path are live; the first successful run is linked above.

Connections — Claude Code: complete for the existing Kimi GitHub connection: portal → Nango relay → Kimi’s n8n. New builds now include the isolated relay secret and n8n credential; the next new-customer build is the first full build verification.

Manual payment automation — current status:

Preview only, no client action: the Team portal now shows Kimi's full reusable $50/month customer-facing payment-request preview. It cannot create a customer, payment link, subscription, invoice, charge, or email. The earlier Team “Create Stripe invoice” action is disabled in both the screen and server because it could invoke Stripe invoice-email behavior.

When approved and enabled: the automation will create one unique Stripe Checkout link for the selected existing portal client; metadata binds the resulting subscription to that client ID and workspace slug. GoHighLevel will automatically send the approved payment-request email from one verified Own the Stack sender—no staff copy/paste. The client enters the card on Stripe Checkout. Stripe takes the first $50 and automatically charges that payment method monthly afterward. The webhook then records the paid status, renewal date, and receipt in that exact portal account. The exact email From line, customer-facing email, checkout preview, and receipt-email behavior still require Kimi's review before anything is enabled.

Newest payment and portal update — October 11:

Fresh build proof completed: the safe qa-active build finished in 6.1 minutes, marked the paid portal customer active, and recorded real server details. The workspace was removed and its test row marked cancelled. Sender and duplicate-email cleanup: configuration verified. GoHighLevel now uses Support Team with help@kimiwalker.com as Reply-To; the old Welcome Email step was removed and the workflow read back with 14 steps. A normal purchase will passively confirm the automatic receipt’s displayed sender and the complete three-email sequence.

The first $50 launch QA purchase created a real workspace in 5.3 minutes. Claude verified the workspace is live. Codex then completed the missing portal link: paid setup creates the customer record and the signed-in customer can claim only the matching paid record by email. The launch QA workspace has a real portal instance record and completed setup report.

Cancellation portal status is proven. Real cancellation events mark an existing paid customer cancelled with a cancel date, repeat events are harmless, and unknown customers are unchanged. Closing a workspace remains manual. Still open: real-renewal observation, the paid-customer portal journey, and one customer tool connection.

Manual client portal update — October 12:

Rasheeda Hall, M.D. has an active portal record linked to the live drhall.ownthestack.io workspace. The remaining links are her portal sign-in/profile, an actual n8n version report, and backup records reporting into the portal. The blank backup/version cells do not prove that infrastructure is absent; they prove the portal has not received those facts.

Carl Gray is fully active: carl.ownthestack.io, n8n owner, client portal login/profile, AI Biz server, monitoring, reported n8n version, and first backups are all linked to the active portal record. The manual path intentionally sent no customer emails.

Manual provision path: the reusable provisioner now accepts a manual/no-email run. It performs the same server, DNS, Coolify, n8n, TLS, owner, monitoring, backup, portal-login, and reporting steps as a paid run while skipping customer email delivery. Next: add the protected team-board action that launches this path from a manual client entry; no direct server work should be needed for the next manual customer.

Fleet board requirement: show each customer’s connection state plainly: connected and healthy, portal login missing, workspace not yet provisioned, backup not reported, or version not reported. The board must read from verified records only; it must never invent a backup or version.

AI review requirement: preserve direct read-only data access and add a repeatable protected visual check of the signed-in team board. Database access tells an agent what was recorded; the visual check confirms the board displays it clearly. Neither path may create, change, or delete client data.

Part 5

Build documents

The technical plan and the client-facing agreement live with this business now. Open either document inside the app, copy the original Markdown, or download the .md file.

Technical plan

Build Specification

The developer implementation plan for infrastructure, provisioning, portals, backups, monitoring, security, and launch phases.

Updated 15 September 2026
Download .md
Business-input draft · not lawyer-reviewed

Client Service Agreement

The business, pricing, restoration, backup, and Florida jurisdiction details are filled in. The agreement is live as the GHL terms step and linked from the required checkout acceptance checkbox.

Updated 28 September 2026
Download .md
Validated implementation source

Manual Provisioning and Recovery Runbook

Jason's audited manual provisioning and recovery process, including post-pilot security, monitoring, notification, backup-freshness, and OS-update verification.

Audited 30 September 2026
Download .md
Workflow build source

Dr. Hall Workflow 1 Roadmap v1.1

The current content-workflow plan covering YouTube, OpusClip, approval branches, and draft-only WordPress and Wix outputs.

Latest workflow update 8 October 2026
Source attachment retained in the internal project record
This page is the plain-language companion to the technical build plan. Both source documents are included above and travel with this app.
Buildout status

Where the build actually is

Service build checklist, sorted by owner. Crossed out means documented as finished. The latest-update section above also lists workflow progress and additional verification gaps. This is a snapshot, not a live tracker, so it changes when the page is updated.

Current launch gate · payment lifecycle and portal validation
Build direction

The $50 monthly service covers the private workspace and managed infrastructure. Workflow building is optional and quoted only after the team reviews the request. No fixed starting price or public price range is promised, and no additional work begins until the customer approves the quote. Customers never choose hour blocks and no money sits in a portal ledger.

Kimi Accounts, cards, and decisions. Nobody else can do these.
  • ✓
    Create the control serverDone In DigitalOcean: Create, Droplets. New York. Ubuntu newest. Basic, Regular, the $24 box (4 GB, 2 vCPU). Name it control. Done. 4 GB, 2 vCPU, New York, Ubuntu 24.04.
  • ✓
    Open a Backblaze B2 accountDone B2 Cloud Storage, pay as you go at $6.95 per terabyte with the first 10 GB free. Done. Bucket kwagency-automation-backups, private, US East.
  • ✓
    Turn on two factor in DigitalOceanDone Every customer server lives in this one account. It is the account worth locking down. Done.
  • ✓
    Complete the client agreement detailsDone Kimi supplied the provider name, Florida jurisdiction, Okaloosa County, $50 monthly price, 24–48 hour restoration target, 30-day backup and cancellation terms, 90-day backup purge, 30-day notices, and the three-month liability cap. The working Markdown draft stays in the private Owner Hub project. Completed 28 September 2026. GHL publication and checkout acceptance are tracked separately below.
  • ✓
    Send Jason the email address for Dr. Hall's workspace loginDone The owner account for the workspace needed an email address to belong to. Done 11 September. Sent to Jason.
  • ✓
    Get Jason into Uptime KumaDone Uptime Kuma was already installed and running. The agency Resend notifier now delivers email alerts and TLS certificate-expiry reminders. Verified 30 September. Email delivery passed through Resend on SMTP port 2465. The sender domain is kwagency.team; the key remains in the approved secret store.
Jason Dr. Hall content automation, separate from the managed-workspace launch gate.
  • ✓
    Retrieve a completed episode and its clipsDoneDr. Hall’s first public YouTube episode was processed in OpusClip. The 40-minute episode produced 34 clips. n8n now reaches Dr. Hall’s OpusClip workspace through MCP/OAuth, selects the latest completed project, and retrieves its clips without a direct OpusClip API key.Completed 10/08/2026. The 34 clips are normalized in n8n as individual items with title, rank, virality score, duration, preview link, and thumbnail.
  • ✓
    Prepare approved clips for captions and schedulingDoneThe workflow narrows the episode to the Top 15 clips by OpusClip rank and virality score. OpenRouter now generates a Facebook caption from a real transcript, writes it to a reliable caption field, and the scheduling logic selects the next 10 AM or 5 PM Central slot instead of a time in the past.Completed 10/07–10/08/2026. The approval check stays before publishing.
  •  
    Approval-based clips workflowBuilt inactive 10/14A preserved copy, Hall Health Live 01 - Clips with Approval, now selects the top 15 OpusClip clips, provides a checkbox approval email, uses the 80-and-up fallback at 5 AM Central Thursday, and assigns 8 AM and 5 PM Central posting times.Safety state: the workflow, approval-email step, social-account lookup, and Opus scheduling step remain off. The original workflow was not changed.
  •  
    Finish sender and Facebook-page bindingThe approval email needs the intended sending credential, and the disabled Opus scheduling step needs Dr. Hall’s Facebook post-account ID selected from the connected Opus accounts before either step is enabled.Required before a real run. No email or social post can be sent from the draft as it stands.
Kimi Codex The selling side, built in code and connected to GoHighLevel.
  • ✓
    Build and optimize the responsive GoHighLevel sales pageDone The published page uses 9 focused sections: an outcomes-first hero using the original Own the Stack logo, a one-example-at-a-time automation carousel, three ways to start, workspace ownership, working-system proof, monthly value, checkout, FAQ, and final CTA. The Automation Library is described only as a growing starting point. Technical customer-facing language and fixed implementation pricing were removed. The $50 recurring product, required workspace-domain field, and agreement acceptance remain unchanged. The sales page is live and its public checkout is confirmed on the live Stripe connection. Updated 10/04/2026. The published page was verified on desktop and mobile with no horizontal overflow or broken images. The carousel advances on a phone-sized screen, every sales-page CTA reaches checkout, and the agreement link remains correct. A real $50 recurring payment completed in live mode on 10/03/2026.
  • ✓
    Require the preferred workspace domain before checkoutDone The GHL draft uses its company field for Preferred Workspace Domain, with an example such as tracys-bakery.ownthestack.io. The native preview blocks checkout while that field is blank and accepts a completed domain. Completed 09/13/2026; reverified 10/04/2026. The required domain field remains in the rebuilt checkout. The first live order was completed; payment-event automation still needs to confirm that the value reaches the provisioning record.
  • ✓
    Create the subscription product and attach the checkoutDone The Own the Stack product is configured as a $50 USD monthly recurring subscription and attached to the funnel's One Step Order form. The workspace-domain, name, and email fields remain in the checkout. Completed 09/28/2026; reverified 10/04/2026. Own the Stack remains $50 per month recurring. The first live purchase was completed on 10/03/2026. The page is live at start.ownthestack.io.
  • ✓
    Add the client agreement to the GHL checkoutDone Triuni added the agreement as a separate GHL step, linked it from the required checkout checkbox at start.ownthestack.io/terms, and completed the custom-domain handoff after Kimi's approval. Use the completed agreement wording; do not rewrite the legal terms. Completed 10/03/2026; reverified 10/04/2026. The required agreement checkbox and terms link remain in the rebuilt checkout. The published page is live at start.ownthestack.io.
  • ✓
    Build the secured GoHighLevel payment-event workflowDone The workflow captures Preferred Workspace Domain from the checkout, uses the ots-subscriber tag to distinguish a first subscription from renewal, and sends standardized event data to n8n. Successful and renewal events include event type, product, transaction ID, amount, full name, email, and preferred workspace domain. The secured handoff also receives failed payments and a separate subscription-cancelled event is required. Built and corrected 10/07–10/08/2026. Field mappings, tag order, dynamic amount, transaction ID, webhook data, and shared-secret authentication were tested and corrected.
  • ✓
    Confirm the public checkout’s live connectionConfirmed The $50 recurring product, required fields, agreement acceptance, confirmation workflow, and Payment Received destination are confirmed. The public checkout uses the live Stripe connection. Confirmed 10/10/2026 by Claude. The public checkout displays $50 monthly recurring and is on the live Stripe connection. No payment or account-level settings change was needed.
Claude Done from the VPS. Nobody needs to do or watch any of this.
  • ✓
    Lock down the control serverDone Firewall, fail2ban, SSH key only with no password login, automatic security updates. Done. Firewall on, password logins off, fail2ban running, security updates automatic.
  • ✓
    Install CoolifyDone The thing that installs and manages n8n on every customer server, routes each web address, and handles the HTTPS padlock. Done. Version 4.3.15, live at coolify.ownthestack.io with HTTPS.
  • ✓
    Install Uptime KumaDone Checks every customer workspace every 60 seconds and emails the team when one stops answering. Verified 30 September. Running with the agency Resend notifier, TLS certificate-expiry reminders, and tested email delivery.
  • ✓
    Set up the nightly backupsDone restic and the key escrow, pushing encrypted backups to Backblaze on a schedule. Done. Test backup ran and the integrity check passed. The encryption passphrase is in Kimi's password manager.
  • ✓
    Create the control plane databaseDone A Supabase project with the tables for customers, servers, backups, tickets, and portal access. Done. 12 tables, row level security on all of them, security scan clean.
  • ✓
    Point the web addressesDone Domain is ownthestack.io, DNS at Porkbun. The control server address is live. Done. Loads over HTTPS with a valid certificate. Customer addresses get created by the pipeline.
  • ✓
    Build the client-connections serviceDone Claude built the secure client-connections service: Nango for customers to connect supported tools and Vaultwarden for the agency’s internal credentials. Completed 10/10/2026 by Claude. The client-connections service is ready for the first real customer connection.
  • ✓
    Create protected Nango access for the portalDone Claude created and tested the protected access the portal needs to open customer Connect sessions and read connected-tool status. Completed 10/10/2026 by Claude. Codex used that protected key only to wire the portal controls.
Jason The actual engineering. The first customer is broken into its real steps, so the status is visible at a glance.
  • ✓
    Build the customer server templateDone The n8n and database setup that gets installed on every customer server, with the n8n version pinned. Done. Reusable template, n8n pinned at 2.38.5 with PostgreSQL 16, deployed through Coolify. Both came up clean on the first real server.
  • ✓
    Create the AI Biz project in DigitalOceanDone A home in DigitalOcean for the control server and every customer server after it. Done 8 September. Created, and the control server moved into it.
  • ✓
    Build Dr. Hall's serverDone The first customer server ever made. Its own 2 GB machine, labeled so the admin dashboard and the cost reporting can find it. Done 8 September. Built, tagged, and firewalled.
  • ✓
    Deploy the template to Dr. Hall's serverDone Installing the workspace itself onto the new server through Coolify. Done 9 September. n8n 2.38.5 and PostgreSQL 16 both running clean.
  • ✓
    Point Dr. Hall's address and turn on HTTPSDone The web address at Porkbun, aimed at the new server, with the padlock. Done 10 September. drhall.ownthestack.io resolves and HTTPS is on.
  • ✓
    Create Dr. Hall's workspace loginDone The owner account for Dr. Hall's private n8n workspace. Confirmed 09/17/2026. The account is active, its credentials are stored in NordPass, and owner access was verified during the restore drill.
  • ✓
    Set up agency-managed workspace registrationDone No step in signup waits on a customer. n8n mails the free Community Edition key to whoever requested it, so the request goes out on the agency email address, never the customer's. One key covers 5 workspaces, and provisioning applies it at build time through N8N_LICENSE_ACTIVATION_KEY rather than the settings screen. Registering only adds folders, debug in editor, and custom execution data, so a workspace goes live either way. Confirmed 09/17/2026. Dr. Hall's workspace is activated with an agency-managed key, and the runbook includes the process. Applying it automatically to future workspaces remains part of the automatic setup.
  • ✓
    Put Dr. Hall's workspace on the monitorDone Adding it to Uptime Kuma so it gets checked every 60 seconds. The login is in NordPass. Confirmed 09/17/2026. Availability and HTTPS monitoring are active in Uptime Kuma.
  • ✓
    Add Dr. Hall's workspace to the nightly backupDone The backup job already runs on the control server. This adds the new workspace to what it picks up. Verified 30 September. PostgreSQL and n8n data are backed up to Backblaze B2 through Restic. Retention, weekly prune, B2 access, and 26-hour backup-freshness monitoring were tested, including DOWN and recovery notifications.
  • ✓
    Protect and test the n8n encryption keyDone The key needed to open a restored workspace is encrypted separately from its backup so credentials can be recovered after a disaster. Confirmed 09/17/2026. The key is encrypted with SOPS and age, stored separately in Backblaze, and was recovered and decrypted successfully from the control server.
  • ✓
    Write the runbookDoneJason completed the final manual provisioning and recovery runbook, then audited the post-pilot security, monitoring, notification, backup-freshness, and OS-update checks.Audited 09/30/2026. The updated Markdown file included above is the current validated baseline for future automation.
  • ✓
    Prove a backup actually restoresPassed Take a backup, rebuild it onto a brand new server, log in, confirm a workflow still runs. A backup nobody has restored is not a backup. Passed 09/17/2026. Dr. Hall's environment was restored on a fresh DigitalOcean server. Database, n8n data, encryption key, owner access, health, and a safe workflow run were verified. Production stayed untouched, and the temporary server was removed.
  • ✓
    Bring the restore below the 60-minute targetDoneThe second complete restore took 36 minutes 31 seconds, meeting the 60-minute target. The original drill took 1 hour 28 minutes 40 seconds.Passed 09/22/2026. Fresh-server recovery, owner login, health checks, safe workflow execution, and cleanup were validated. Production stayed untouched.
  • ✓
    Build the automatic setupBuilt and proven Claude built the automatic setup. It creates the customer workspace from the validated runbook in one resumable run. Two clean builds finished with no human involved, and an interrupted build resumed where it stopped without duplicate work. Proven 10/10/2026. The two clean runs finished in 5.2 minutes and 7.0 minutes, inside the ten-minute promise. A webhook payment event then triggered a third workspace build in 5.7 minutes. Test cleanup is confirmed. Still open: renewal, cancellation, and failed-payment customer notice handling.
  • ✓
    Connect payment to automatic setupBuilt and proven The secured n8n handoff receives the needed customer and payment data. Its first-payment route now calls the finished automatic setup; failed, renewal, and cancellation routes do not create a workspace. Proven 10/10/2026 by Claude. A webhook payment event triggered a workspace build that finished in 5.7 minutes with nobody involved. All test resources were removed afterward.
  •  
    Complete subscription lifecycle: renewal and cancellationOpen Renewal and cancellation are subscription lifecycle checks, not new-workspace triggers. The cancellation notice and portal status are proven. Closing a workspace remains manual under the current policy. Renewal routing and repeat-payment safety are proven; a real scheduled renewal still needs observation. Updated 10/11/2026. Claude corrected two pre-existing workflow defects: the webhook had no downstream connection, and the new-subscription gate was case-sensitive. Structural testing proves only a first $50 Own the Stack payment reaches provisioning; renewal, cancellation, failed payment, wrong product, and wrong amount stop. A real cancellation then reached the live route and created no workspace. The notice and portal status are live and tested. A safe repeat-payment test also built no second workspace. Next: observe a real scheduled renewal, keep workspace closure manual under the current policy, and verify the customer-facing email/portal journey.
  • ✓
    Build the update rolloutBuilt and proven Claude built the fleet update rollout. It moves workspaces through a pinned n8n update in batches, snapshots first, and stops on the first failed health check. A workspace is healthy only when it answers and is actually running the requested version. Proven 10/10/2026. A throwaway workspace updated from 2.38.5 to 2.43.3, then rolled back with its account and data intact. Dr. Hall’s workspace was protected and untouched.
Kimi Codex The two portals. The full technical spec has been sent separately.
  • ✓
    Build and deploy the client portalDone Deployed: branded production app at portal.ownthestack.io, with a private GitHub repository, light and dark modes, Supabase login, protected live reads, secure ticket submission, and private attachments. The customer hour-selection page and balance card were removed 13 September. Completed 09/18/2026. The custom domain, Porkbun DNS, and Vercel HTTPS are connected.
  • ✓
    Build and deploy the team portalDone Deployed: Fleet, Customer Detail, New Signups, Tickets, and Money & Versions are live behind the protected team role and read from Supabase. Secure ticket submission is active. Completed 09/18/2026. Client and team views share the same protected production app and sign-in.
  • ✓
    Connect Stripe hosted billing to the portalDone The first paid Own the Stack order is a pending portal customer and linked client account. The production portal billing connection is configured and live. Update Payment Method and Cancel Subscription can create a Stripe-hosted billing session without changing a price, payment, or subscription. Completed 10/10/2026. The production endpoint confirms the protected Stripe connection is configured.
  •  
    Verify the first real customer portal accessFinal portal proof Client sign-in is proven on the real portal domain. The portal now uses a standard password-first path: a protected administrator or provisioner gives an approved account a temporary password, and the first successful sign-in stops at Create a private password before any portal page opens. The public sign-in screen defaults to email and password, with separate Forgot password and optional secure-link routes. The temporary-password guard and the protected issuer are live; no portal sign-in email is required for normal first access. Next: issue temporary passwords privately for Kimi, Carl Gray, and Dr. Rasheeda Hall, then confirm each first sign-in reaches the private-password screen. The team view, support-ticket path, Stripe-hosted billing page, and a recovery journey still need their own proof. Do not create a workspace, backup, health record, or ticket until those facts exist.
  • ✓
    Deploy customer connection controlsDone The production-only Nango API key is scoped only to opening Connect sessions and listing connection metadata. It is secured in the portal deployment, not in GitHub or browser code. Codex deployed the customer Connect button and connected-tools list on 10 October. Completed 10/10/2026 by Codex. The live endpoint requires a signed-in portal customer and does not expose the Nango key.
  •  
    Prove the first customer tool connectionFinal MVP proof Use a real signed-in customer to open Connect, finish one supported-tool connection, and confirm it appears in the customer portal. Done when: a customer can click Connect, finish one supported tool connection, and see that connection in the portal. Not in this MVP: team views, texted links, n8n wiring, or per-tool rules.

What blocks what

Things further down cannot start until the ones above them are finished.

1

Kimi creates the control server and opens Backblaze. Done 2 September.

2

Claude sets the server up: locked down, Coolify, monitoring, backups, database, web addresses. Done 3 September.

3

Jason builds the customer template and sets up one customer by hand, then proves a backup restores. Completed 09/17/2026. The final runbook and optimized second restore are complete as of 09/22/2026; recovery took 36 minutes 31 seconds.

4

Claude completed and proved automatic setup and its first-payment trigger: two clean runs finished in 5.2 and 7.0 minutes, a broken run resumed without duplicate work, and a payment-triggered run finished in 5.7 minutes. The cancellation safety route is proven only to create no workspace; its customer notice and portal status are live, and the team closes the workspace manually at the end of the paid month until automation is added later. Triuni verifies the remaining GoHighLevel renewal signal; Jason verifies its n8n renewal route. Renewal must remain unable to start another workspace.

5

Codex completed the protected Stripe billing connection and the customer connection controls. Client sign-in at the real portal domain is now proven. Codex must verify the team, ticket, hosted-billing, and first connected-tool views.

Right now

Launch work continues. Checkout, payment routing, the safe test path, capacity fallback, customer activation, email delivery, and cancellation status are proven. The October 11 purchase exposed that the emails do not tell a customer how to enter the portal. The cancellation policy is manual closure at the end of the paid month until later automation. The remaining work is the portal-first access message and paid-customer portal journey, real-renewal observation, and one customer tool connection if Connect remains customer-facing.

Team update — October 11, 2026. This page is not calling the service launch-ready. The current readiness gate above supersedes older narrow-proof summaries: real-renewal observation, one full paid-customer portal journey, and one customer tool connection if Connect remains customer-facing must be complete and reviewed.

AI Biz Launch document

Document

Download