Day 0 = Aug 20, 2026 (approval received). Weeks below are calendar weeks from that day. Click any bar to open the checklist, mark done items, and write detailed notes (saved in this browser).
Hover a bar for the full description · click to track progress. Use codes LB-01 … LB-21 in chat.
Day 0 is locked: August 20, 2026 — roadmap approval received from Yunus and Fatih. Every week on this chart is a calendar week from that day. Week 10 lands around late October / early November; Harbor and Skyrocket follow through late December.
Week 0 also locks the product domain (golaunchbase.com) and the rule that the client never sees the name CorpNet. Fulfillment partners stay behind the brand.
The original vision document says Phase 1 filings are powered by CorpNet as a silent fulfillment partner. The public CorpNet API page describes REST, JSON, a Bearer token, create order, documents, poll status (no webhooks yet), RFI, and cancel.
In week 0 Yunus and Fatih send the documentation request from LaunchBase corporate email (CorpNet’s interest / partner form). The goal is the technical API description so we can design the adapter. This is not a commercial close and not the start of production keys. Staging keys are plugged in later, once the product is already clickable on mocks (LB-12).
Security testingBright end of the bar: we read the docs; keys do not go into chat or the repo. The request leaves only from LaunchBase corporate email.
The vision document asks for state comparison (taxes, privacy, cost, compliance load) and entity recommendations (LLC, S-Corp, C-Corp, Nonprofit, Professional Corp) with visual helpers instead of legal walls of text. Education first: the user understands why, not only what to click.
On the stand: a clickable overlay guide (Get Started) with “why this state / why this entity” and a CTA. This phase plaque is delivered as a mock. Database and accounts are LB-13; CorpNet keys are LB-12. Customer demo is LB-21.
Security testingMock only: fictional scenarios, overlay on the demo domain. Real roles, PII isolation, and the database are LB-13. No secrets on the frontend.
The vision document requires a clean step-by-step intake whose questions change with entity type, state, and business purpose, plus real-time validation and progress. Packages follow golaunchbase.com: Basic / Standard / Premium, with state filing fees passed through at cost.
On the stand: a dynamic intake under the LaunchBase brand (the client never goes to CorpNet / SOS). Phase plaque delivered as a mock: state fees are copy. Live product is LB-13. Customer demo is LB-21.
Security testingOn the mock, intake fields live in the browser (localStorage). Real SSN/ITIN isolation, roles, and the HTTPS product are LB-13.
The vision document lists the catalog we must be able to order later without rebuilding the site: name search/reservation; LLC, C-Corp, S-Corp, Nonprofit, Professional Corp; articles; initial reports; EIN; DBA; S-election; foreign qualification; licenses; annual and bi-annual reports; registered agent; amendment; conversion; reinstatement; dissolution; certified copies; rush; payroll tax registration.
Until keys exist, both Direct and CorpNet hit a mock. On the stand: order methods, Phase 1 catalog, timeline. Phase plaque delivered; order data still sits in localStorage. Live CorpNet is LB-12 after the LB-13 security pass.
Security testingMocks use fake people only. In this demo the order lives in the browser. The client never sees the CorpNet name. Real PII isolation / database / accounts are LB-13.
There is no public table of “these states have a formation API.” Search APIs are not create-LLC APIs. So the default for all fifty states is CorpNet — that is how we cover the country without fifty integrations. Direct means LaunchBase skips CorpNet on that order because a real state channel (filer portal / API) was found and volume makes it worthwhile.
On the stand: a 50-state + DC table and a god-mode flip with no login. In-flight orders keep their route. This is not live Direct channels (LB-08 / LB-09) and not real staff roles (LB-13).
Security testingOn the mock the switch is god-mode, not a login. Real staff/admin roles and order isolation are LB-13. The client still never sees the partner name.
The vision document calls the dashboard the core differentiator, inspired by Harbor-class compliance platforms but simplified for non-experts: formation status, filed documents, registered-agent status, upcoming deadlines, state-specific obligations, compliance history and audit trail.
Week-4 stand: intake → mock pay → timeline → fake Articles / EIN. The cabinet reads localStorage; staff is god-mode. Phase plaque delivered as a mock. Harbor command center is LB-16; auth/DB is LB-13.
Security testingThe mock has no accounts: the cabinet does not isolate “mine.” CorpNet’s name stays out of the client UI. Real client/staff/admin roles and the database are LB-13.
Show the clickable stand (guide, intake, mock order, cabinet, god-mode staff). Get a written OK that the screens and flow are acceptable. This is not a ship to golaunchbase.com — the live path stays LB-13, then LB-12.
LB-03–07 are already closed as the mock phase. LB-21 is a separate check: “the customer saw it.”
Security testingThis gate is about screens. Live keys, PII, and roles are not this ticket; they are LB-13 before LB-12.
A public internet list of formation APIs does not exist. Gregory searches Secretary of State sites for filings, developer/API/XML/bulk, and registered-filer programs. Typical findings: human portal only, PDF, company-search API, or “partner program — write here.”
Research starts with Florida: that is the example we walked through on the first Microsoft Teams call (the Florida state website). Next are other states that already appear on golaunchbase.com. This is an internal routing table, not fifty live integrations. It runs in parallel with the mock product and does not block CorpNet.
Security testingThe routing table stays internal. Notes contain no client PII and no keys.
Where the deep-search (LB-08) finds a real door, official filer/API requests go from LaunchBase as the US company. States almost never issue production access to an individual developer. Gregory drafts the letter and the target list. Yunus and Fatih send it — from LaunchBase corporate email.
We do not send fifty letters on day one. Only states where a door was found. Who says yes can later get the Direct switch (LB-06). Everyone else stays on CorpNet.
Security testingThe letter leaves only from LaunchBase corporate email. The draft has no extra PII. Attachments and recipients are checked before send.
The vision document includes Federal Tax ID (EIN) in Phase 1. CorpNet can fulfill EIN in many cases. On the first Microsoft Teams call, using the Florida state website as the example, we discussed the gap: some government steps have no API. First template is IRS Form SS-4 (EIN application) in the context of a Florida for-profit corporation. SS-4 is federal; “Florida” is the entity setting, not a different IRS form.
Flow: structured fields in LaunchBase → fill the official PDF → preview and store on the order → send via secure corporate email API (not a personal mailbox) → statuses PDF generated, sent, awaiting EIN. We do not parse inbound government email as the system of record. Rejections go to needs-staff-review. Client can start the fields; staff always review.
Security testingThe EIN PDF is encrypted. Outbound mail goes only through the corporate API, not a personal inbox. Audit: who generated and who sent.
On the first Microsoft Teams call, using the Florida state website as the example, we discussed that these sites and PDFs exist beyond Florida. After SS-4, the same mapping engine takes the next official PDFs — Florida articles or annual report, then other state PDFs — without inventing a new product each time.
Still not “email the state as filing.” Still audit who generated and who sent the file.
Security testingSame pass as SS-4: file encryption, corporate mail, generate/send audit. No personal mailbox.
When CorpNet issues staging keys and LB-13 has passed (hosting, database, auth, security pass), we replace MockCorpnet with LiveCorpnet. Same LaunchBase UI. Authentication is a partner-issued Bearer token; status is polled. The documentation for this is requested in LB-02.
That is how we get real filings across fifty states without fifty homemade Direct APIs. Direct turns on only if a state actually granted a channel (LB-08 / LB-09); otherwise the state stays on CorpNet. We do not promise a state API we were not given.
Security testingThe Bearer token lives only on the server. Staging and production stay separate. Keys are not in the frontend, git, or logs.
The overlay + localStorage mock is not a product you ship to golaunchbase.com. LB-13: app at app.golaunchbase.com (not an overlay on the marketing site); a database for orders instead of localStorage; client / staff / admin logins; no PII in the frontend or logs; files encrypted at rest; backups; view / generate / send audit; keys only on the server.
The production security pass is signed off before live CorpNet keys (LB-12). Prototypes use fake people.
Security testingThis is the security pass before LB-12: hosting, database, auth, encryption, backups, audit, no PII in logs.
In this slice AI means: why this state/entity (education first), missing-field checks on intake, client-friendly status copy, drafts for staff. Later, on Harbor: reminder copy and queue triage.
The model does not file with a state and does not replace CorpNet or a PDF. Filing is API, official PDF, or a human.
Security testingPrompts do not receive SSN or keys. The model is not allowed to send a filing. AI replies do not write PII to logs.
Vision Phase 2: after formation the company keeps living. Harbor is the silent compliance partner, the way CorpNet is the silent filing partner. The client still sees only LaunchBase.
Week 11: Yunus and Fatih send the Harbor API documentation request from LaunchBase corporate email. Gregory reads the method contract and designs the adapter. Production keys land in LB-17, after the dashboard mock is in place.
Security testingSame as LB-02: request from corporate email only. Harbor keys do not go into chat or the repo.
Per the vision document the dashboard must show: a calendar of state obligations, upcoming deadlines, reminders, state-specific alerts, and compliance history. For holdings and founders — several companies in one account (multi-entity).
How: company data after formation (state, entity, formation date) → state rules + Harbor response (mock first) → deadline cards in the same dashboard as LB-07. The client sees “annual report due May 1”; staff see the overdue queue. AI (LB-14) writes the reminder copy; it does not file.
Security testingA client sees deadlines only for their companies. Staff access is by role. Another company’s EIN does not appear in the wrong dashboard.
Week 12: MockHarbor adapter — the same LaunchBase methods (company calendar, obligation list, mark complete). LB-16 screens do not change.
Weeks 13–14: when Harbor issues keys — LiveHarbor. LaunchBase polls status and writes it into the dashboard. If keys are not yet available, the dashboard stays on the mock plus state rules — the product does not stall. Done when the client sees real dates for their company, not a vague “later.”
Security testingHarbor keys live only on the server. The mock holds no production data. Staging and production stay separate.
Long-term vision: LaunchBase for formation and the legal lifecycle; Skyrocket for books, payroll, tax, projections. One login, one ecosystem, from idea to taxes.
Weeks 15–16: after formation, the LaunchBase dashboard shows a step “open books / taxes.” That step creates the company card in Skyrocket (name, state, EIN, owners, documents from LB-07). One account. Not a second site the client has to register for again.
Security testingOne login does not mix other people’s companies. The company card moves only inside LaunchBase → Skyrocket, not outside.
Per the vision document the financial loop is bookkeeping / accounting, payroll, tax filings, and projections. That is already Yunus’s practice; the product job is not to invent accounting from scratch, but to give the LaunchBase client the same loop without a break.
How: intake “which books / which payroll / which tax state” → dashboard status (books in progress, payroll registered, return in work) → files and statuses next to formation documents. Mock pipeline first, so screens and statuses are ready before the live loop.
Security testingPayroll and tax fields are PII: not in logs, not on the frontend beyond need, access by role.
When the internal Skyrocket loop (books / payroll / tax) can accept companies, the adapter switches from mock to live — the same move as LB-12 for CorpNet and LB-17 for Harbor.
Done when a company formed in LaunchBase is visible in Skyrocket with EIN and documents, the client uses one login, and staff run books and tax without a side spreadsheet. After week 18 this is an operating product, not a “phase someday.”
Security testingFinal security pass of the whole LaunchBase → Skyrocket loop: roles, keys on the server, PII, audit. After that it is an operating product.