Saya Butuh Follow-Up Email Otomatis, Jadi Saya Bangun Sendiri dengan AI — Ini Yang Terjadi

TL;DR

• Saya sudah punya Chrome Extension untuk inject HTML di Gmail compose.
• Kebutuhan marketing naik: saya butuh follow-up otomatis (pesan 1 → 2 → 3) jika client tidak membalas.
• Saya bangun app sendiri: Next.js, Supabase, Netlify, Gmail OAuth — dibantu Cursor AI dan agent.
• Yang paling bikin pusing
  • jika laptop atau mac saya mati, cron salah jadwal, follow-up jadi email baru
  • bukan satu thread email-pesan.
• jika laptop atau mac saya mati, cron salah jadwal, follow-up jadi email baru
• bukan satu thread email-pesan.
• Akhirnya berjalan dengan baik. Yang saya pelajari: masalahnya jarang di “UI”, lebih sering di infrastruktur yang tidak terlihat.

Saya pikir setelah bisa kirim email HTML yang rapi dari Gmail, workflow outreach saya sudah “cukup”. Ternyata belum.

Yang kurang justru bagian paling membosankan: follow-up. Pesan pertama sudah dikirim. Client belum balas. Dua hari kemudian saya lupa. Seminggu kemudian saya malu membuka thread yang sama Ditambah, untuk case saya follow-up message adalah kunci dalam email-marketing

Itulah titik di mana saya memutuskan: kalau saya butuh follow-up otomatis, saya akan coba bangun sendiri.

Kenapa Saya Tidak Langsung Pakai Tool Berbayar?

Saya tahu ada tool-tool follow-up email yang sudah keren namun selain mahal terasa berlebihan untuk skala saya yang kebutuhannya masih minim.

Kebutuhan saya sebenarnya lumayan sederhana:

• Kirim pesan 1 dengan jadwal.
• Kalau tidak ada balasan, kirim pesan 2 setelah jeda tertentu.
• Kalau masih tidak ada balasan, kirim pesan 3.
• Cukup untuk akun Gmail saya sendiri.
• Tidak perlu tracker “email dibuka atau belum”.
• Tidak perlu bulk blast ribuan penerima.

Jadi bayar platform besar atau tool-tool email marketing terasa seperti menyewa truk box untuk antar satu paket kecil.

Ide Ini Sebenarnya Lanjutan dari Project Sebelumnya

Sebelumnya saya sudah membuat Chrome Extension untuk menyisipkan HTML ke compose Gmail. Project itu lahir dari kebutuhan sederhana: ingin email terlihat lebih profesional tanpa pindah tool.

Setelah extension itu jalan, saya mulai melihat celah berikutnya. Extension membantu saya menulis pesan yang lebih rapi. Tapi ia tidak membantu saya mengingat follow-up.

Jadi saya tulis kebutuhan ideal di catatan:

1. Pesan 1 — isi email penerima, subject, HTML, lalu jadwalkan pengiriman.
2. Pesan 2 — simpan dulu; kalau tidak ada balasan dalam waktu tertentu, kirim otomatis.
3. Pesan 3 — sama seperti pesan 2, tapi mengacu ke pesan sebelumnya.

Kelihatannya sederhana. Di kertas, selalu sederhana.

Saya Mulai dengan Tech Stack yang Sudah Familiar

Saya tidak ingin belajar framework-framework baru hanya untuk satu workflow. Jadi saya pilih yang sudah saya kenal dan saya pengalaman serta tentu mudah di-deploy:

• Next.js — dashboard UI
• Supabase — database + Edge Function untuk cron
• Netlify — biar dashboard tetap online
• Google OAuth / Gmail API — kirim email lewat akun Gmail saya

Coding dibantu Cursor AI dan agent. Saya yang arahkan workflow, review UI, dan test. AI yang bantu terjemahkan ide ke kode, migration, dan perbaikan bug.

Saya sengaja membatasi fitur. Tidak ada open/click tracking. Tidak ada kampanye massal. Fokusnya satu: sequence follow-up 3 langkah yang benar-benar jalan dan sederhana.

Workflow Akhir yang Saya Pakai

Setelah beberapa iterasi, alurnya menjadi seperti ini:

1. Login app (hanya email saya yang diizinkan).
2. Hubungkan Gmail API (izin kirim/baca thread).
3. Buat sequence: penerima, subject, HTML pesan 1, jadwal kirim.
4. Tambah pesan 2 dan 3 dengan jeda (bisa menit, jam, atau hari).
5. Cron di cloud mengecek: apakah sudah waktunya kirim, dan apakah penerima sudah membalas.
6. Kalau sudah balas, follow-up berikutnya dibatalkan.

Di dashboard, saya bisa melihat status tiap pesan: terjadwal, antre, terkirim, dibatalkan, atau selesai.

Yang Saya Kira Mudah, Ternyata Paling Ribet

Saya mengira tantangan terbesar adalah UI form dan editor HTML. Ternyata bukan.

Yang paling sering bikin saya mengerutkan dahi adalah bagian yang tidak terlihat di layar:

1. Laptop mati ≠ email berhenti

Saya sempat mengira kalau laptop Ubuntu/Mac saya mati, pengiriman otomatis juga berhenti. Logikanya masuk akal… sampai saya sadar: UI boleh di localhost, tapi cron harus di cloud.

Kalau cron hanya jalan saat npm run dev aktif, follow-up akan selalu bergantung pada laptop saya. Itu bukan otomatis. Itu “otomatis selama saya online”.

2. Jadwal sudah lewat, status masih “Terjadwal”

Saya buat test: pesan 1 dijadwalkan jam 17.00. Saya kembali jam 20.00. Status masih Terjadwal.

Bukan karena kode kirim emailnya rusak. Processor sebenarnya sudah mendukung catch-up: kalau scheduled_at sudah lewat, cron berikutnya seharusnya langsung kirim. Masalahnya cron belum dipanggil dengan benar — atau frekuensinya terlalu jarang untuk jeda 30 menit.

3. Cron tiap hari tidak cukup untuk jeda menit

Awalnya saya sempat berpikir cron harian sudah “cukup”. Tapi kalau pesan 2 harus keluar 10 atau 30 menit setelah pesan 1, cron sekali sehari jelas akan meleset.

Saya akhirnya mengarah ke jadwal tiap 5 menit. Baru di situ jeda pendek terasa masuk akal.

4. Extension pg_net dan error SQL yang membingungkan

Saya pernah melihat error seperti schema "net" does not exist dan column "....token...." does not exist. Rasanya seperti database marah tanpa alasan.

Lalu saya paham: satu masalah karena extension belum aktif, satu lagi karena token berisi karakter + / = yang salah di-quote di SQL. PostgreSQL membaca string double-quote sebagai nama kolom. Error-nya terdengar teknis, tapi akarnya sepele: quoting.

5. Follow-up muncul sebagai email baru

Ini yang paling mengganggu secara produk. Pesan 2 dan 3 seharusnya berada di thread yang sama dengan pesan 1. Di inbox penerima, malah muncul sebagai percakapan baru.

Saya sudah mengirim threadId dan subject Re: .... Ternyata belum cukup. Gmail lebih andal menggabungkan thread kalau ada header In-Reply-To dan References yang menunjuk Message-ID pesan sebelumnya.

Setelah itu, follow-up baru terasa seperti balasan di conversation yang sama.

Perbandingan Singkat: Yang Saya Bayangkan vs Yang Terjadi

Tabel ini mungkin terdengar sepele. Tapi justru di situlah pelajaran terbesar saya: banyak “fitur gagal” sebenarnya adalah “infrastruktur belum siap”.

Apa Yang Benar-Benar Membantu?

Kalau saya ringkas, yang paling membantu bukan library baru. Lebih ke cara kerja:

• Batasi scope lebih dulu. Saya tulis dulu apa yang tidak saya bangun (tracker, bulk). Itu menjaga project tetap kecil.
• Pisahkan dua jenis auth. Login dashboard (siapa boleh buka app) beda dengan koneksi Gmail API (izin kirim email). Mencampur keduanya bikin bingung.
• Test dengan jeda pendek. Untuk debugging, jeda 2–5 menit jauh lebih berguna daripada “3 hari”.
• Punya tombol/cara trigger manual. Saat cron belum stabil, bisa memaksa processor jalan sangat menenangkan.
• Baca status di database, bukan hanya UI. “Menunggu” di layar bisa berarti pending yang belum pernah masuk antrean queued.
• Diskusi dengan AI seperti pair programming. Saya tidak minta “buatkan semua sekaligus”. Saya ceritakan gejala, screenshot, lalu minta perbaikan spesifik.

Frequently Asked Questions

Apakah harus pakai Gmail API untuk follow-up otomatis?

Kalau mau otomatis saat laptop mati, pada praktiknya iya — atau minimal ada service cloud yang memanggil Gmail API. Schedule Send native Gmail tidak cukup fleksibel untuk sequence follow-up dengan deteksi balasan.

Apakah vibe coding cukup untuk project seperti ini?

Cukup untuk memulai dan maju cepat, tapi bukan berarti tanpa paham. Saya tetap harus mengerti konsep dasar: OAuth, cron, status di database, dan perbedaan UI vs worker. AI mempercepat, bukan menggantikan keputusan.

Apakah saya perlu open tracking?

Untuk kasus saya, belum. Saya lebih peduli apakah penerima membalas atau tidak. Open tracking menambah kompleksitas privacy dan teknis yang belum saya butuhkan.

Penutup

Project ini lahir bukan dari keinginan “bikin SaaS email marketing”. Ia lahir dari rasa kemalasan saya karena lupa follow-up dan case saya dimana follow-up adalah penting dalam email-outreach, dan dari rasa ingin tahu: seberapa jauh kalau AI jadi partner coding harian dalam development.

Yang saya dapatkan bukan hanya app yang akhirnya kirim pesan 1–2–3 dengan benar. Saya juga dapat pemahaman lebih dalam tentang otomatisasi: otomatis itu mudah di demo, tapi sulit di detail — terutama di bagian yang tidak kelihatan.

Kalau Anda sedang menimbang membangun tool kecil untuk kebutuhan sendiri, saya punya saran sederhana: mulai dari workflow yang benar-benar Anda pakai setiap minggu. Jangan mulai dari daftar fitur yang bagus di landing page orang lain.

Bangun yang Anda butuhkan. Biarkan sisanya menunggu sampai benar-benar mengganggu.