Your first 100 signups don't need automation. Here's the line where that changes

Go and open the welcome sequence of any seed-stage company that bought a platform early. Somewhere in message three there is a reference to a feature that shipped in a different quarter, a link to a docs page that redirects and a sign-off from someone who left. It has been sending, uninterrupted, to every signup, the whole time. Nobody has noticed because nobody replies to it, and nobody replies to it because nobody reads it.

That is the actual risk of automating early. It is not the monthly fee. It is that automation converts a message you were paying attention to into a message you have stopped paying attention to, and email is the one channel where the failure produces no visible symptom. A broken landing page gets reported within a day. A stale welcome flow will happily run for two years.

So the question is not "am I big enough to automate yet". It is "is this message finished enough to run without me". Those have different answers, and only one of them is about your user count.

The advice you will find most often is a threshold: automate at 100 users, or 500, or when manual sending takes more than an hour a week. It is popular because it is easy to check and it sounds like a rule. It is wrong for two reasons.

The first is that volume is not what makes manual sending fail. Timing is. A hundred signups a month arriving evenly is entirely manageable by hand; a hundred arriving the day after a launch is not, because the thirty that needed a same-day reply got one on Thursday. The failure mode is a missed window, and windows are a function of clustering, not totals. If your product has an activation moment early in the first week — most do — a late message is close to a wasted one, and the 72-hour window is the reason why.

The second is that a signup threshold tells you to automate something without telling you what. That gap is exactly where the template gallery gets opened. A founder who has decided it is time to automate but has no message they already trust will build the flow the platform suggests. That flow was written for a generic SaaS company by someone who has never used your product. It is not a starting point, it is a placeholder that will outlive your attention.

Do the sum before the vibe. It is short.

Time the manual version honestly — look up the account, read what they did, write four sentences, send. Call it four minutes if you are fast and know the product. At twelve signups a day, that is forty-eight minutes a day, or roughly four hours a week. At three signups a day it is twelve minutes. That is arithmetic, not a benchmark: put your own two numbers in.

Now the other side, and this is where founders under-count. The automated version costs you a setup afternoon, plus a recurring ownership cost that never goes to zero — someone re-reading the copy each quarter, checking the trigger still fires after an engineer renames an event and confirming the flow stops sending when a user converts or churns. Call it a couple of hours a quarter if you are disciplined, and considerably more the one time it breaks and you find out six weeks late.

Four hours a week clears that bar comfortably. Twelve minutes a day does not — and at twelve minutes a day you are still getting replies, which is a benefit that disappears the moment the message is automated. That is the trade you are making: you are exchanging learning for consistency. Make it when you have finished learning, not before.

Most teams hit one of these before the hour-a-week line. Any single one is sufficient. Four, not three, because the fourth is the one people forget.

You missed the window more than once this week. Signups that sat two or three days before you got to them. This is the strongest signal on the list, because a late message is not a slightly worse message — the context it depended on is gone. You are now sending a cold email to someone who was warm on Tuesday.

You have sent the same words three times running. If you have stopped editing, you have stopped learning and the manual send is no longer buying you anything the automated one would not. This is the happiest reason to automate — the message is finished. Copy it verbatim into the tool, including the bits that feel too plain.

The trigger is something you cannot see."Signed up yesterday" is visible in your admin list. "Hit the integration screen twice and bounced both times" is not. It is a far better trigger. When the message you want to send depends on a behaviour inside the product rather than a row in a list, you need a system that watches events and no amount of diligence substitutes for that.

Someone other than you would have to send it. The manual program works because the founder has full context and a personal stake. Hand it to a new hire and it degrades within a fortnight — not from carelessness, but because the judgement calls are unwritten. If the send is about to change hands, it needs to be a documented flow before it changes hands, not after.

This is the whole discipline — the part that survives contact with every tool.

Your first automated flow should be a message with a history: you have sent it forty times, you know what people reply, you have three versions of the subject line and a view on which one works. Rebuilding that in a platform is a transcription job. It takes an afternoon and it works on day one, because the hard part — knowing what to say — was done in your sent folder.

The failure pattern is the opposite order. Buy the tool, open the flow builder and build a five-message onboarding sequence you have never sent a single instance of. Every message in it is a hypothesis, all five hypotheses launch simultaneously and when the flow underperforms there is no way to tell which of the five was wrong. You will not go back and find out, because by then you are shipping something else.

One message. Live for a month. Then the next. It feels absurdly slow for about six weeks and then it is the only lifecycle program in your peer group that anybody trusts. The three emails in the manual starting set are the natural candidates, in whatever order they crossed the tripwire.

Which flow to build after that one is a settled question rather than a matter of taste, and getting the order wrong costs a quarter. The choosing lifecycle programs guide gives you the selection framework — what your business model leaks, what your data actually supports and the programs worth actively keeping off the queue. Orbit's Program Brief skill turns the one you pick into a spec before anything gets built, which is how you avoid the template-gallery version.

Three costs, all of them ongoing, none of them on the invoice.

Silent failure. An automated flow that stops firing looks identical to an automated flow with no eligible users. There is no error, no alert, no bounce — just an absence. Absences are invisible on a dashboard that only plots sends. The cheap defence is a recurring calendar entry: once a month, open the flow, look at the send count for the last thirty days and check it is not zero. That is a five-minute job that catches nearly everything.

Drift. Product ships, feature gets renamed, the event your trigger listens for changes its name in a pull request nobody flagged to marketing. The flow keeps running against an event that no longer fires. Write down which events each flow depends on in the same doc your engineers read, or the first you will hear about it is a quarterly number that dropped for no visible reason.

The message that keeps sending to the wrong person.The one that genuinely damages you. A "finish setting up" nudge going to someone who finished setting up, or a trial reminder to a paying customer. Every automated flow needs an explicit exit condition — the state that removes someone from it — and the exit is the part that gets skipped, because building it requires deciding what "done" means. Decide before launch, not after the first complaint.

The tool question is downstream of your data, which is why comparing feature lists is mostly wasted time. At this stage one question decides it: whether the platform can receive the events your product already emits and act on them. If it cannot, you have bought a newsletter tool with a flow builder attached, and every behavioural trigger you wanted will remain out of reach.

The verdict: buy the cheapest thing that reads your product's events. Buy it for the next twelve months rather than for the company you intend to be at Series B. The enterprise platform you will "grow into" costs you a setup you cannot maintain and a contract you cannot exit. You still end up migrating, just later and with more history to move. The ESP comparison covers the trade-offs by stage if you want the longer version.

One rule when you do move: never migrate a mess. Whatever is broken in your manual process gets faster and less visible in an automated one, so fix the message first and port it second. A migration is the cheapest moment to delete something, and the most expensive moment to discover you kept it.

Keep a tally. One line per lifecycle email you send by hand, for five working days — which message and whether it went out on the day it should have. It takes about ten seconds a send and it answers the question this whole post is about with your numbers instead of somebody's threshold.

At the end of the week: if nothing was late and you are still editing the copy, do nothing. Run it another month. If two or more went out late, or one message has stopped changing, that specific message is your first automation — and only that one.

The honest failure mode to watch for is neither too early nor too late. It is automating five things at once because you finally bought the tool and felt like you should use it.