Hover a bar for the full description and the matching vision-document clause. Use the bar code (LB-01 …) in email or chat.
Day 0 is the day we receive roadmap approval from Yunus and Fatih. Every week on this chart is counted from that day, not from the date of this file. If approval comes immediately, week 10 lands around late October; if later, the same weeks simply shift.
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.
We ship a guided advisor that outputs a short “why this state / why this entity” and a CTA to start formation. This is the same idea as the public site’s “where should you form” and “which structure,” turned into a working product step.
Security testingAdvisor prompts contain no PII. Secrets do not live in the frontend. The client does not leave for a third-party domain.
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.
The customer stays on LaunchBase the whole time. They do not fill a CorpNet form and they do not visit a Secretary of State website.
Security testingSSN/ITIN and passport scans are not written to logs or analytics. Fields travel over HTTPS. We check the intake never leaks to another site.
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. LaunchBase owns stable methods (create order, get order, documents, status). A thin adapter later swaps MockCorpnet for LiveCorpnet. Screens do not change. Status lives on the LaunchBase order: received, paid, queued, submitted, RFI, filed, rejected — needs staff, documents ready. Client sees a simple timeline; staff see route, errors, and PII.
Security testingMocks use fake people only. Order PII is not in the browser or logs. The client never sees the CorpNet name or the internal route.
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.
Staff can flip a state. In-flight orders keep their route; new orders follow the new switch. We do not migrate all fifty states to Direct. The long tail can stay on CorpNet. If a Direct channel is unavailable, that state goes back to CorpNet. Emailing a state is not a filing channel.
Security testingRoute switch is staff/admin only. Another staff member cannot move someone else’s orders. 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 demo: finish intake → test/mock payment → timeline moves → Articles and EIN letter appear as files. Staff queue filters by state, route, and status, and can push a mock status. CorpNet’s name never appears in the client UI.
Security testingA client sees only their own files. Staff and admin are split. Documents are not served to another account. CorpNet’s name does not leak even in an error.
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, 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.
Orders will contain names, addresses, ownership, sometimes SSN/ITIN or passport scans, and formation PDFs. HTTPS; roles client / staff / admin; no PII in the frontend or logs; files encrypted at rest; audit of view / generate / send; keys only on the server; outbound mail via corporate API. Prototypes use fake people.
App on a LaunchBase subdomain (for example app.golaunchbase.com). Backups and a production pass before live CorpNet keys.
Security testingThis is the final security pass before live keys: HTTPS, roles, encryption at rest, backups, view/generate/send 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.