Improving a micro-SaaS Conversion: Email Automation

Blogs

January 21, 2026

Tl;DR

Congratulations, you got a micro-SaaS like this in front of people and even sold some.

You understood this is all about getting the OpEx right.

Now what?

Intro

Keeping in mind the level of repetitions that you need.

The number of people that is enough to try or to say no to try to be significative to then change something.

PROS advice to count in ~ thousands.

Im assuming for this post that you got the product delivery ready for sometime: yes, we come from here

With some decent and easy to disgest user journey workflow, like this one.

Slubne-Chwile - Leads ↗ Jan26 Slubne-Chwile ↗

Landing with proper loading times, above the fold, …
Ads or someway of people knowing you working
The product itself right in place, working as your features promise
Stripe or some way to get the ultimate feedback that what you do is valuable

And…this is it?

Cant I get better?

Of course you can.

And its all about asking these 3 questions:

Whats working
Whats not
~~Whats next~~: whats the biggest blocker to make my idea better in reality?

Some math first

Say your TAM is: 100k people every year

Then, 1% of them get to know that you exist when they are on a BANT state: that goes to…1k

You should know your LTV, and your conversion rate.

Making the income: LTVConversion1k = 1000,0011000 = 100$ a year

Wait…I get that little?

After all the tinkering, the building, the promotions…

Arent you even covering adquisition and operational costs?

Lets push the levers to change that.

With a very important one been the OpeX in growth, aka ads. Driven by psyc effects.

A Video Explanation

Im assuming you have a proper ATF (above the fold essentials configured) to minimize the Time to Value.

With proper atf instructions to Gemini you go from:

landing page vite

You can have cool videos embeded into your site, like these sites do:

https://www.okticket.es/
https://www.zoho.com/mail/
https://www.mrpresident.es/
https://flashhub.io/
Thanks to these I also learnt to ask about this and got it working at my genbi.jalcocertech.com

To: Your users on high-intent mobile searches will now see the headline + interactive input + video proof all in their first view

alt text

Or just friendly and converting desins https://kursy.ikliszcz.com/

A better FAQ

In general, a better copy.

You are paying ~1$ for 5 seconds of attention.

At least get the email via signup.

Emails to show that you are still there

Pros say that every email should contain: diversion, information, Venta.

Sell a transformation.

Not the vehicle, but the pain removal and dream outcome destination.

But send emails…to whom?

You should be able to query the registered at Firebase/Firestore: so I put together these scripts

You will need the firebase console SDK creds to get the service-account.json

This will also be useful to unsubcribe users:

alt text

git clone https://github.com/JAlcocerT/slubne-chwile-y26
#git pull
cd slubne-chwile-y26/slubnechwile
#docker compose -f docker-compose.cloudflare.yml up -d --build

# 1. Check Wedding Details (Firestore)
node --env-file=.env scripts/list-users.mjs #--csv

# 2. Check login accounts (Firebase Auth)
node --env-file=.env scripts/list-auth-users.mjs

│ (index) │ Email │ Names │ Paid │ Storage │ Created │ Last Seen │ ├─────────┼───────────────────────────┼──────────────────┼──────┼───────────┼─────────────┼──────────────────────────┤ │ 0 │ ‘@gmail.com’ │ ‘ba & do’ │ ‘❌’ │ ‘0.00 MB’ │ ‘1/13/2026’ │ ‘Never’ │ │ 1 │ ‘@gmail.com’ │ ‘Test1 & test2’ │ ‘❌’ │ ‘0.00 MB’ │ ‘1/13/2026’ │ ‘1/24/2026, 11:02:59 PM’ │

I was doing so first with the slidev Firebase branch version. Same here.

Then, get to know email DRIP.

It’s a descriptive metaphor for the slow, steady “dripping” of automated email messages over time, like water from a faucet, rather than a sudden flood.

The term evokes gradual nurturing of leads through timed sequences.

DRIP x Mailtrap ESP

Here https://github.com/JAlcocerT/make-landing/tree/master/mjml-email I tested Mailtrap API x Python and some templating.

But it was time to use it for: /slubne-chwile-y26/z-emails

Taking this to the project: I needed some orchestrator, but it wont be driven by CRON, but via GHA with hourly checks.

#node --env-file=.env scripts/orchestrate-drip.mjs
node --env-file=.env scripts/orchestrate-drip.mjs --dry-run

Creating and testing the templates is simple:

alt text

node scripts/test-email.mjs --step welcome --name "JAlcocerT" --email "test@example.com" #this one creates a local html

But hey, make it match your web/product UI/X for consistency:

alt text

#node --env-file=.env scripts/test-email.mjs --send
node --env-file=.env scripts/test-email.mjs --step welcome --name "Jul" --email "sometestmail@gmail.com" --send
node --env-file=.env scripts/test-email.mjs --step social --name "Jul" --email "othertestemail@gmail.com" --send

Now just orchestrate the bulk sent, as per their current DRIP status:

#node --env-file=.env scripts/list-drip-status.mjs
node --env-file=.env scripts/orchestrate-drip.mjs

And anyone trying the free tier should have opted-in for this

#node --env-file=.env scripts/test-email.mjs --step welcome --name "Jul" --email "sometestmail@gmail.com" --send
#every email contains a reference the the firebase UUID https://slubnechwile.com/unsubscribe?email=jesalctag%40gmail.com&uid=YOUR_REAL_FIREBASE_UID
node --env-file=.env scripts/test-email.mjs --step welcome --uid YOUR_REAL_FIREBASE_UID --send #this connects them to the email autom
node --env-file=.env scripts/toggle-unsubscribe.mjs --resubscribe
###docker compose -f docker-compose.cloudflare.yml up -d --build
#docker logs slubnechwile-app

No email DRIP, unsubcribed and erased from DB. Simple.

I needed to add a docker volume with the `` for the container to pull data from Firestore

cd slubnechwile/scripts
nano service-account.json
#git pull
#node --env-file=.env scripts/list-drip-status.mjs #now you can see Unsubscribed as YES
#node --env-file=.env scripts/orchestrate-drip.mjs --dry-run #and no action will be taken around email marketing for such user

FireStore

MailTrap Orchestrated via GHA

So, am I going to be orchestrating who to send what?

No way.

This:

cd ./slubnechwile
node --env-file=.env ./scripts/orchestrate-drip.mjs

Is going to be ran by github actions: hourly and free, with this config

Whatever your user journey is, most likely than not you will send after a follow up.

Same for upsales.

Workflow Stage	Primary Metric	Purpose
Attract & Convert	CAC	Measuring the efficiency of your sales and marketing “engine”.
Delivery	Gross Profit	Measuring the efficiency of your production or service “engine”.
Retention	LTV	Measuring the long-term value of the customer relationship.

So consider this email DRIP orchestration as a way to keep CaC constant and move up the LTV.

The Goal: You want a “Deliver” workflow so efficient (high Gross Profit) and a “Convert” workflow so effective (low CAC) that you reach the Payback Point as quickly as possible.

Private Repositories: GitHub provides 2,000 free minutes per month.

This script takes about 30-45 seconds to run.
Running hourly (24 times/day) = ~720 runs per month.
720 runs * 0.75 minutes = 540 minutes per month.
This is well within the 2,000-minute free allowance.

All working with this architecture around the email marketing.

graph LR
    A[User Sign Up] --> B[Firebase Auth UID created]
    B --> C[Wedding Doc created with ID = UID]
    C --> D[marketing_status initialized]
    E[GitHub Actions - Every 1h] --> F[orchestrate-drip.mjs]
    F --> G[Query Firestore for pending leads]
    G --> H[Check marketing_status]
    H --> I[Send Email via Mailtrap API]
    I --> J[Update Firestore marketing_status]

One of the biggest advantages of this custom approach is that you own the logic.

In traditional marketing SaaS:

When an email doesn’t send, you don’t know why (API limit? Filter? Logic error?).
You can’t easily “dry run” how changes will affect 1,000 existing leads.

In this Lean Drip:

Total Transparency: Every decision made by the engine is logged. You can see exactly which condition was met (or not) in your GitHub Actions history.
Safe Testing: The --dry-run flag allows you to test logic changes against your real database without actually sending a single email or changing a single record.
Easy Debugging: If something breaks, you get a standard Node.js stack trace. You are debugging “code,” not a proprietary UI tool.