Use Cases
Novice founder
First company, no prior knowledge. Matter resolves every default end-to-end through one declarative endpoint; the founder's job is to say what they want, then read back what was created.
Last updated
A first-time founder with no prior corporate-law knowledge. They give Matter the absolute minimum — a company name, their name and email, a one-line description — and trust the platform to resolve every other default. The whole API surface is intent-only: the founder declares a goal to POST /v1/intents, reads back the resolved plan with rationale for every default, and authorises with POST /v1/intents/{id}/execute. Two calls per action, every action.
Create
Bring the entity into existence — formation, founder equity, EIN, registered agent.
You become a real US Delaware C-Corp through one declarative goal: start_company. Matter resolves every default — entity kind, jurisdiction, share counts, par value, registered agent, founder vesting, bylaws clauses, 83(b) — and stands up the entire formation packet end-to-end on execute. Your only input is the company name, your name and email, and a one-line description of what you do.
POST /v1/intentsPass goal: start_company with your proposed_name, founder block, and a one-line description. The intent comes back with status: resolved, an execution_plan listing every step the resolver would take (Certificate of Incorporation, EIN application, founder stock issuance, 83(b) preparation, default bylaws, registered-agent assignment), and defaulted_fields[] — every default field comes back annotated with a one-line plain-English rationale. No side effects yet; this call is the read-back.
POST /v1/intents/{id}/executeAfter reading the rationale rows, authorise with the intent's ID. The cascade fires: filing goes to the Delaware secretary of state, EIN is requested from the IRS, founder stock is issued, the 83(b) notice is rendered with the 30-day deadline tracked, default bylaws are generated, and Matter's default registered agent is appointed. Every state transition emits a webhook; the entity flips through submitted → registered → active over the following days.
GET /v1/entities/{id}Retrieve the entity, list its stakeholders, list its documents, view the cap table, view the compliance calendar. Every nontrivial field carries an x-matter-explainer block with a layperson gloss — what an 83(b) is and why you must sign it within 30 days, what par value means, what franchise tax you owe and when. This is your only learning loop.
Manage
Operate the live entity — equity programs, board cadence, compliance, qualifications.
You don't configure anything. The compliance calendar populated itself; the reminder cadence is set; the franchise-tax method gets picked for you. Every operational action goes through POST /v1/intents with a different goal. Your first customer contract, your first angel cheque, your first board consent — same two-step shape every time: declare the goal, authorise the plan.
POST /v1/intentsPass goal: send_customer_contract with the customer's name, email, and the deal amount. Matter picks the contract template that matches the business kind you described in your formation intent — subscription agreement for a SaaS shape, marketplace ToS for a marketplace, services agreement for an agency shape. The resolved plan tells you which template was picked and why; on execute, Matter generates, sends, and captures the executed contract.
POST /v1/intentsPass goal: take_investment with the angel's counterparty and amount_usd. The resolver picks the instrument (post-money SAFE by default for angel cheques), derives the valuation cap from the cheque size (100x principal bucketed to the nearest $0.5M), and surfaces every choice in rationale[]. On execute, the SAFE is rendered, sent for signature, and the cap-table view updates to reflect the convertible.
POST /v1/intentsPass goal: hire_worker with the candidate, the engagement shape (employee or contractor), the comp, and an optional equity ask. The resolver classifies employee-vs-contractor (rejecting requests that smell like misclassification under the CA/MA/NJ ABC test), picks the grant kind (ISO if your equity plan is adopted and the 409A is current; NSO with a rationale otherwise), sets vesting, prepares the 83(b) notice with its 30-day deadline tracker, and bundles the IP-assignment agreement scoped to the worker's home state. On execute, the offer letter goes out, the grant is issued, and the cap table updates.
POST /v1/intentsPass goal: make_decision with an action_kind (appoint officer, declare dividend, approve grant above threshold, ratify action) and a one-line summary. The resolver picks the signing body (board only, stockholders, or both), the threshold (majority, supermajority, unanimous) per your bylaws and the DGCL, and the format (written consent for same-day; minutes-in-lieu when bylaws require meeting ceremony). The consent renders, the right people are routed for signature, and the resolution lands in your audit log.
POST /v1/intentsA year later you've done nothing. Pass goal: stay_compliant with the tax year. The resolver returns a per-filing line-item plan: DE annual report, franchise tax (with assumed-par-vs-authorised-shares method comparison and the cheaper one picked), BOI status check, foreign-state annual reports, 1099 dispatch per contractor, registered-agent renewal — each with its own rationale row explaining what the filing is and why it exists. On execute, every filing goes out and confirmations come back as webhooks.
Exit
Wind the entity down — dissolution cascade or M&A envelope.
A novice founder doesn't dissolve their first company on their first try. When you eventually wind down, pass goal: wind_down for the dissolution cascade (Form 966 → final franchise tax → Certificate of Dissolution → BOI closure) — same two-step shape, same rationale rows. Or switch to the solo bootstrap walkthrough if you want a guided asset-sale-then-dissolve envelope; by then you'll have learned enough to pick which path applies.