Steward
All docs

Docs Running a business

Launch to first dollar

This is how to take a business from an idea to its first dollar with Steward. Open Launch in the sidebar and pick the business. You see 14 steps. Each one says whose turn it is:

You don't tick most steps by hand. Steward reads what the studio already knows (the charter, integrations, the page, the numbers) and marks them done. Tap a step to see how it's done, with links. Mark done and Not needed are there for anything Steward can't see.

Every three hours, the heartbeat tells @steward which steps are its own to do. It turns each owner step into one task on the board, and closes that task when the step is done.

The steps, and the keys each one needs

StepWhoWhat it needsDone when
1. Charter confirmedOwnerNothingThe charter has goals and a kill line
2. DomainOwner, @steward helpsNothing to check namesAn owner enters the domain here
3. Email on the domainBothCLOUDFLARE_API_TOKEN, the zone id, RESEND_API_KEYThe Resend records are live and Resend says verified
4. Landing page live@stewardNothingThe page is published at /p/your-business
5. Waitlist working@stewardNothingThe page has the signup form, or someone signed up
6. Analytics on@stewardNothingThe page is live (visits are counted as it's served)
7. Stripe connected, with a priceBothSTRIPE_SECRET_KEYA payment link exists
8. Terms and privacy publishedBothNothingTerms and privacy are live
9. Support inbox connectedOwnerNothing (a forwarding address)The support loop is on, with its inbound secret
10. Social handleOwnerBLUESKY_APP_PASSWORD_<SLUG> to postThe handle is entered
11. First content@stewardA social account, or the pageA post went out, or an extra page is live
12. Launch announcement@stewardSocial or email@steward marks it after posting
13. First customerBothStripeRevenue above 0, or a customers number
14. First dollar recorded@stewardStripeRevenue above 0

Keys are env vars on the server. A key ending in _<SLUG> is for one business only (STRIPE_SECRET_KEY_DOG_WALKS); the plain name works for every business. Integration settings and switches are on the Integrations and trust page.

Step by step

1. Write the charter. On Businesses, give the business goals with numbers and dates, and a kill line: the result that would make you stop. That line is the pass line every later test is judged against.

2. Pick and buy a domain. On Launch, tap Suggest names. Steward checks which names are free (through RDAP, the registries' public lookup). Buy one at a registrar. Cloudflare Registrar sells at cost, and it keeps the DNS in the same place. Enter the domain on the Launch page. Steward never buys a domain.

3. Connect Cloudflare and Resend.

Then @steward runs dns_preset resend. The records come from Resend itself: SPF, DKIM, the bounce MX, and a DMARC policy that only monitors. That's a decision card: you approve the exact records. Once they're live, dns_verify checks them on Cloudflare's and Google's resolvers, and Resend's own check, and marks the step done.

For the site itself, dns_preset railway points the domain (or app. or www.) at a Railway service. Copy the CNAME target and the _railway-verify value from the service's Networking settings in Railway.

4 to 6. The page, the waitlist and analytics. @steward writes the landing page and publishes it at /p/<slug>. The first publish is a decision card. The page has a waitlist form, and the studio counts visits and clicks as it serves the page: no scripts and no cookies.

7. Stripe. Set STRIPE_SECRET_KEY (see Integrations for the permissions a restricted key needs). @steward makes a payment link for the charter's price; that's a card too, since it takes real money. Revenue then syncs from Stripe every hour.

8. Terms, privacy and refunds. @steward drafts them from the charter (the refund policy when the business takes payments): what you sell, the data the studio collects (waitlist emails, support messages, Stripe payments, cookie-free visit counts) and the jurisdiction. The jurisdiction is set on the Launch page and defaults to the owners' location (STUDIO_JURISDICTION, or California). The pages drafted together go on one decision card, every time. Approving it publishes them at /p/<slug>/terms, /privacy and /refunds. If the business has its own site (a site address on the Releases page and a GitHub repo), nothing is published on the studio: the yes gives the build agent a task to add the pages to that site through a pull request and the security review, and where the site already has a page, the card lists the differences and the task suggests edits to it instead. Once the site's page is live, /p/<slug>/<page> redirects there. These are drafts, not legal advice: have a lawyer review them before you rely on them. You can read the drafts on the Launch page first, or tap Draft them to start yourself.

9. Support. On Support, switch the support loop on, make the inbound secret, and forward your support address to it. The contact form at /p/<slug>/contact comes with it. See The support loop.

10 to 12. Social, first content, the announcement. Make the account (Bluesky first) and enter the handle on Integrations and trust, with its app password on the server. @steward drafts the first post and the launch announcement; each goes through the gate.

13 and 14. First customer, first dollar. @steward works the waitlist; you close. The first Stripe payment shows up as revenue, and the checklist is done.

Company and accounts

Some steps only a person can do. They're under Company and accounts on the Launch page, each with a short how-to and links to official sources:

Mark each one done, or tap Get help to post a job for a person, with a budget. The job is a decision card first, like every job (see Jobs for people).

For builders