GetEYT — the plan

The servers, live

Both boxes arrived on the 28th and the platform is running on both of them. This section is what changed, what it cost to find out, and the one thing still standing between it and a working web address.

Locked down before anything was installed

• Production had 265 failed root logins waiting when it was first opened, which is exactly why this came first
• Key-only logins, firewall closed by default, automatic banning, automatic security updates on, everything patched, and both boxes restarted and re-checked because a protection that does not survive a restart is not a protection

Texting, explained properly

This is the thing that has bitten you before, so here is the whole picture rather than a checklist. The short version: the reason the applications keep failing is that you do not have an EIN, and an EIN is free, takes about ten minutes, and does not require an LLC.

What is actually being asked of you

Since 2021 every business that sends texts from an ordinary ten-digit US number has to register two things with the carriers before a single message goes out: the brand (who is sending) and the campaign (what the messages are and how people agreed to get them). Both go to a single industry registry that every carrier reads. Skip it and messages get silently filtered or blocked, which is the worst possible failure because nothing errors, the texts just quietly stop arriving.

There is no way around the registry. Twilio, Telnyx, Bandwidth, Plivo and Sinch all submit to the same place. Any service claiming to make it disappear is doing one of two things: using toll-free numbers instead, which is a legitimate different route covered below, or sending your messages under their own registered brand, which means the messages are legally theirs, a complaint lands on their account, and you have no standing when they cut you off.

Your four routes, compared honestly

Whose name should it be registered in

• NetRyse, once the entity exists. Correct long term, because NetRyse operates the platform and holds the contracts. This is the target.
• You as a sole proprietor, with an EIN pulled today. Legitimate, instant, and it starts the propagation clock. It can be moved to the entity later, which is a resubmission, not a disaster.
• EYT's entity. Jessica's business already has an EIN and is the actual network owner, so registering under it would work today. I would not do it, the messaging asset and its reputation would sit under her entity rather than the platform you are building, and unpicking that later is worse than waiting.

What to do, in order

1. Get an EIN today, as a sole proprietor
   Ten minutes on irs.gov, free, issued at the end of the session. Save the confirmation letter as a PDF, every later form asks for the legal name exactly as it appears on it, character for character.
2. Keep pushing the trust entity in parallel
   Once it exists it becomes the registrant, and it also unblocks Stripe, the insurance named insured and the signature page. The EIN above is a bridge, not a replacement.
3. Open the platform account and fill in the business profile
   Separate from your existing NetRyse account. You will need:

   • Legal name exactly as printed on the EIN letter, no trading name
   • The EIN itself
   • Entity type, and a street address, never a PO box
   • A live website that describes the business, netryse.com is fine
   • An authorised representative with a business title and a direct phone
   • A support email and phone that a person actually answers
4. Register the brand
   A few dollars, one time. Usually approved the same day. If it fails, it is almost always the legal name not matching the EIN letter exactly.
5. Register the campaign, this is the part that gets rejected
   It needs, and reviewers actually read these:

   • A plain description of what the texts are for
   • Two real sample messages, written the way they will actually send, including the business name and the opt-out line
   • Proof of how consent is collected, a live URL or a screenshot of the real form, showing the unticked checkbox and its exact wording. The platform's own lead forms already produce this
   • STOP to opt out and HELP for help, in the footer of the message
6. Start a toll-free verification at the same time
   Costs nothing to have both in flight. If the campaign gets stuck in a rejection loop, this is what keeps August 12 intact.
7. Buy one number, send one real text, watch it land in the Inbox
   End to end, with the reply threading back to the right client. Nothing counts as done until this happens once.

1 · Your list

GetEYT only. The Chat EYT items, the passwords, her insurance, the cohort-expiry deploy, sit on a separate list and are not mixed in here.

Blocking, in this order

Worth doing, not blocking

2 · My list, before the server

Everything here can be built with no box, no keys and nothing from anyone else. It is ordered so that the last thing finished is the last thing needed.

Running right now

Each is in its own worktree with a pre-assigned database migration number so they cannot collide when they merge. Each has to pass type checking, linting, the test suite and the tenant-isolation gate before I look at it.

The second wave, closing the wishlist gap

Then, still with no server

• Stripe round trips against mocked keys, so the day the real keys arrive it is a formality rather than a discovery
• A feedback widget on every screen landing in the HQ queue with the screen attached. Her starred item, and the fastest way round one gets fixed after August 12
• The self-healing operations layer, watching and reporting only. Write access earned one permission at a time, never root and a spending limit on day one
• Rehearse the demo against seed data twice, all the way through, and write down every place it stutters

3 · The server, in order

Written as a runbook rather than a to-do list. When the login lands there is nothing to work out, only to run, top to bottom. Nothing here can start early.

Hour one, lock the box before anything is installed on it

1. Non-root deploy user, key only, passwords off
   Create the user, install the key, then disable password authentication and root login entirely. Do this before the box has been reachable long enough to be found, because it will be found within minutes.
2. Firewall default-deny, then open exactly three things
   SSH, 80 and 443. Postgres is never open to the internet, not even "temporarily to test something". Add fail2ban on the SSH jail.
3. Unattended security upgrades
   So the box patches itself without anyone remembering to. This is also a question on the cyber insurance application, and answering it yes is worth real money.
4. Tailscale, then close SSH to the public internet
   Admin access stops touching the open internet at all. The staging box joins the same network.

Hour two, get it running

5. Docker and compose, clone, environment variables, first boot
   Secrets go in as environment variables, never into the repository. Bring the web app and the background worker up together, the worker is what makes a lead text feel instant, and a stack without it looks fine and quietly does nothing.
6. Caddy, TLS and the content security policy
   Certificates issue automatically. Verify the policy actually blocks what it claims to, rather than assuming the header is enough.
7. Cloudflare in front, origin address never public
   Then confirm the box refuses traffic that has not come through Cloudflare, otherwise the protection is decorative.
8. Backups every night to object storage, off the box
   Then restore one into the staging box and open it. A backup nobody has restored is not a backup, it is a hope. This step is not optional and it is not deferred.
9. The staging box, same build
   So a database migration is never first tried on the machine that holds twenty studios' member records.
10. Health checks and alerting
    Something that shouts on Telegram when the site, the worker or the nightly backup fails. Test it by breaking something on purpose.

Then, connecting the outside world

11. Stripe end to end, in test mode
    Charge, refund, a dispute, and a webhook delivered twice on purpose to prove it does not double-charge anybody.
12. Texting, per studio
    A sub-account per studio provisioned through the API. Send one real message, reply to it from a real phone, watch it thread into the right client's inbox. Then test STOP and confirm it silences every automation and not just the one that sent it.
13. Email sending from each studio's own domain
    The sending records per studio, so a studio's newsletter arrives from them rather than from us. Verify one lands in a real inbox and not in spam.
14. Seed the eight demo studios and walk the whole demo twice
    On the real box, at the real speed, with the network as it will be on the day.
15. A link for Jessica and two trusted licensees
    Early August, quietly. The point is to be told the obvious thing that nobody who built it can still see.

The automations, grouped

What already runs on its own, sorted by what sets it off. This is the real catalogue from the codebase, not a wish list, fifteen automations and thirty-two message templates are written and working, waiting on a phone number and a payment key to leave the building.

A new lead arrives

Classes and bookings

A member's life at the studio

Money

Teacher training

Underneath, where nobody sees it

• The schedule tops itself up so a recurring class always has bookable dates on the horizon, without anyone extending it by hand
• The waitlist promotes itself the moment a cancellation lands, day or night
• Every message passes one gate before it leaves, consent, opt-out list, quiet hours in the recipient's timezone, and whether this message type is one they agreed to. Nothing sends around it
• Failed work retries with backoff and then gives up loudly rather than silently, so a broken integration surfaces instead of rotting
• Old records prune themselves on an hourly loop, so the database does not quietly grow forever