Bookmark Bukan Reading List — Tapi Operating System untuk Keputusan

Saya sering bookmark hal yang akhirnya tidak pernah saya baca.

Mungkin kamu juga begitu.

Setiap hari saya scroll X, Reddit, Hacker News, dan beberapa feed lain. Ada thread menarik tentang arsitektur database baru — bookmark. Ada repo yang punya pendekatan cerdik pakai WebAssembly — bookmark. Ada opini tajam tentang developer productivity — like, save, atau apa pun nama tombolnya di platform itu.

Dalam seminggu, bisa terkumpul 200+ item tersimpan di berbagai platform.

Dalam sebulan, jumlahnya bisa ribuan.

Yang benar-benar saya baca?

Mungkin 5%.

Awalnya saya menganggap ini masalah klasik: information overload. Terlalu banyak informasi, terlalu sedikit waktu.

Tapi belakangan saya merasa masalahnya bukan itu.

Masalahnya adalah saya memperlakukan bookmark sebagai daftar bacaan.

Padahal bisa jadi bookmark bukan reading list.

Bisa jadi bookmark adalah sinyal.

Masalah sebenarnya bukan terlalu banyak informasi

Kita sering menyalahkan information overload.

Tapi menurut saya, problem utamanya bukan jumlah informasi. Problem utamanya adalah cara kita memperlakukan semua informasi seolah-olah nilainya sama.

Seolah semuanya harus dibaca satu per satu.

Seolah urutan terbaik adalah urutan kapan kita menemukannya.

Model seperti itu cepat rusak ketika skalanya membesar.

Apalagi untuk orang yang bergerak di persimpangan engineering dan bisnis. Yang perlu dipantau bukan cuma "artikel menarik", tapi beberapa jenis sinyal sekaligus:

• Sinyal teknis — tools baru, arsitektur baru, pola engineering yang mungkin relevan untuk stack kita.
• Peluang build — ide yang bisa diubah jadi produk, fitur, internal tool, atau service baru.
• Wilayah konten — topik yang sedang sering muncul dan kita punya sudut pandang untuk dibahas.
• Gerakan kompetitif — hal yang sedang dibangun, dibicarakan, atau diadopsi orang lain di ruang yang sama.

Membaca bookmark satu per satu tidak membantu banyak untuk kebutuhan seperti ini.

Itu lebih mirip konsumsi pasif yang menyamar sebagai produktivitas.

Saya butuh sistem yang mengubah firehose informasi menjadi actionable intelligence.

Bukan read-later app lagi.

Bukan sekadar second brain.

Lebih tepatnya: operating system untuk keputusan.

Yang saya bangun

Saya bikin pipeline yang berjalan malam hari saat saya tidur.

Pipeline ini menarik item yang saya save, like, atau interaksikan dari X, Reddit, dan timeline lain. Setelah itu sistem melakukan scoring, kategorisasi, lalu sintesis menjadi tiga output yang benar-benar saya pakai:

1. Morning brief — ringkasan pendek tentang hal yang penting dari feed kemarin. Bukan sekadar daftar link, tapi analisis: apa yang sedang dibahas dan kenapa itu penting.
2. Build radar — daftar peluang build yang realistis, berdasarkan pola dari item yang saya simpan.
3. Ide konten — topik yang muncul dari cluster bookmark, terutama ketika ada gap atau sudut pandang yang belum banyak dibahas.

Tidak ada UI khusus.

Tidak ada app baru yang harus saya buka.

Hasilnya masuk ke Telegram setiap pagi.

Saya baca lima menit, lalu lanjut kerja.

Cara kerjanya

Bagian teknisnya justru bagian yang paling menarik.

Collection layer

Bagian tersulit bukan AI-nya.

Bagian tersulit adalah mengambil datanya.

X tidak punya bookmark API publik yang enak dipakai. Akses API Reddit juga sudah tidak sesantai dulu. Sebagian besar platform memang ingin kita tetap berada di UI mereka, bukan mengekstrak data dari aktivitas sendiri.

Jadi saya memakai CDP: Chrome DevTools Protocol.

Di kantor, saya punya Windows PC yang selalu menyala. PC ini menjalankan Chrome lewat Playwright dan Node.js. Setiap jam 2 malam, script berjalan, masuk ke akun yang sudah login, scroll bookmark, likes, saved posts, lalu mengambil data penting:

• teks;
• URL;
• author;
• timestamp;
• source platform;
• jenis interaksi.

Aksesnya lewat Tailscale. Jadi office PC dan VPS berada dalam private network yang sama. Tidak perlu buka port publik. Tidak perlu setup VPN ribet. Praktisnya: WireGuard network yang jalan begitu saja.

Collector script-nya sekitar 400 baris Node.js.

Sebagian besar bukan logic yang keren. Lebih banyak handling edge case: rate limit, perubahan DOM ketika X update frontend, pagination yang kadang random, dan session yang sesekali perlu disentuh ulang.

Tidak cantik.

Tapi jalan.

Storage layer

Semua data masuk ke SQLite.

Satu database. Beberapa tabel sederhana:

• items — konten mentah yang disimpan atau dilike, lengkap dengan source, URL, text, author, dan timestamp;
• scores — hasil scoring multi-dimensi;
• briefs — morning brief yang digenerate per hari;
• radar — entry untuk build radar.

Menurut saya SQLite adalah pilihan yang paling benar untuk use case seperti ini.

Saya tidak butuh database server.

Saya tidak butuh framework migrasi.

Saya tidak butuh ORM yang membuat query sederhana jadi drama.

SQLite itu file di disk. Bisa dicopy, dibackup, diquery dengan SQL biasa, dan dipindahkan antar mesin tanpa ceremony.

Untuk sistem single-user yang memproses mungkin 500 item per hari, memakai database server besar justru overengineering.

Intelligence layer

Di sini Hermes Agent masuk.

Setelah proses collection selesai, script Python mengambil item baru hari itu dan mengirimkannya ke Hermes dalam beberapa batch. Untuk setiap item, sistem meminta score di lima dimensi:

• Worth to read — apakah ini benar-benar layak dibaca?
• Worth to build — apakah ini bisa diubah menjadi sesuatu?
• Worth to use — apakah tools atau pendekatan ini layak dipakai?
• Worth to copy — apakah ada pola yang layak ditiru?
• Worth to brainstorm — apakah ini memantik ide yang perlu dieksplor?

Setiap score wajib punya alasan satu kalimat.

Ini penting.

Angka saja tidak cukup.

Sering kali justru alasan di balik score lebih berguna daripada scorenya sendiri.

Setelah scoring selesai, ada second pass untuk menghasilkan tiga output:

1. morning brief;
2. build radar;
3. ide konten.

Prompt-nya berbeda untuk tiap output.

Morning brief tidak saya minta sebagai summary. Saya minta sebagai synthesis:

Tema apa yang muncul? Apa sinyal di dalam noise ini?

Build radar memfilter item dengan score build/copy tinggi, lalu bertanya:

Dengan konteks menjalankan perusahaan engineering di Indonesia, mana yang realistis untuk dibangun?

Ide konten mencari cluster dan gap:

Di mana beberapa item bertemu pada topik yang belum dijelaskan orang dengan jelas?

Bagian terakhir ini penting. Saya tidak mau ide konten generic. Saya mau ide yang muncul dari curiosity trail saya sendiri.

Delivery layer

Output akhirnya diformat menjadi teks bersih dan dikirim ke Telegram.

Itu saja.

Tidak ada dashboard.

Tidak ada web app.

Tidak ada sistem notifikasi baru.

Telegram adalah UI-nya.

Ini keputusan yang sengaja saya ambil. Dashboard memang terdengar lebih impressive. Tapi Telegram brief dibaca setiap hari. Dashboard biasanya dibuka saat kita sedang merasa rapi dan produktif — alias jarang.

Meet the user where they already are.

Dalam kasus saya, tempat itu adalah Telegram.

Yang benar-benar saya dapatkan

Morning brief

Dulu saya bisa habiskan 30 sampai 45 menit pagi-pagi untuk scroll feed dengan alasan "catch up".

Sekarang saya cukup baca brief 300 kata yang menjelaskan apa yang penting dan apa maknanya.

Ini saja sudah menghemat sekitar satu jam per hari.

Kuncinya adalah membuat brief yang content-first.

Versi awal sistem ini hanya membuat daftar link dengan summary. Tidak berguna. RSS reader juga bisa melakukan itu.

Perubahan besar terjadi ketika saya minta AI untuk menganalisis, bukan mendeskripsikan.

Kalimat seperti ini jauh lebih berguna:

Tiga orang di network kamu sedang membangun pola yang mirip dari arah berbeda.

Dibandingkan:

Ini tiga post tentang topik X.

Yang pertama membantu mengambil keputusan. Yang kedua cuma menambah daftar bacaan.

Build radar

Ini bagian yang paling mengejutkan.

Saya tidak menyangka bookmark saya menyimpan sinyal build yang kuat.

Tapi ternyata iya.

Ketika saya menyimpan empat atau lima hal tentang problem space yang sama dalam dua minggu, itu sinyal. Build radar hanya membuat sinyal itu terlihat.

Bulan lalu, sistem ini menangkap bahwa saya cukup sering menyimpan hal tentang local-first software dan offline-first pattern untuk konteks Indonesia, di mana koneksi internet tidak selalu stabil.

Saya tidak sadar sedang memperhatikan pola itu.

Sistemnya sadar.

Sekarang kami sedang mengeksplorasi arah produk dari cluster tersebut.

Ide konten

Saya menulis di blog mungkin dua kali sebulan.

Dulu bottleneck-nya adalah mencari topik.

Sekarang saya punya daftar ide yang muncul dari sinyal rasa ingin tahu saya sendiri.

Postingan yang lahir dari sistem seperti ini biasanya lebih enak ditulis dan lebih kuat. Karena topiknya bukan hasil mengarang demi publish.

Topiknya berasal dari hal yang memang cukup menarik bagi saya sampai saya simpan.

Itu bedanya konten yang dipaksa dengan konten yang punya territory.

Pelajaran yang saya dapat

1. Scoring lebih berguna daripada sorting

Insting pertama saya adalah mengelompokkan bookmark ke folder atau tag.

Ternyata itu pendekatan yang salah.

Kategori itu statis. Ia memaksa satu item masuk ke satu axis organisasi.

Padahal satu item bisa punya nilai yang berbeda di dimensi berbeda.

Contoh:

• tidak terlalu layak dibaca dalam-dalam, tapi pattern-nya layak ditiru;
• tool-nya tidak cocok dipakai, tapi business model-nya menarik;
• thread-nya terlalu panjang, tapi problem statement-nya bagus untuk ide produk.

Folder tidak bisa menangkap nuansa seperti ini.

Scoring bisa.

2. Alasan lebih penting daripada angka

Score "7/10 worth to build" tidak banyak membantu.

Yang membantu adalah alasan seperti ini:

7/10 — ini menyelesaikan pain point nyata di operasional SME, cocok dengan market kamu, tapi pendekatan teknisnya masih mentah.

Score membantu ranking.

Reasoning membantu keputusan.

Jadi kalau membangun sistem seperti ini, jangan cuma minta angka. Minta juga alasannya.

3. Pipeline sederhana menang

Saya sempat tergoda menambahkan vector embedding, semantic search, RAG pipeline, dan semua buzzword second brain lainnya.

Tapi saya tahan.

Query SQL sederhana dengan filter dasar sudah menangani 90% kebutuhan:

• score threshold;
• rentang tanggal;
• source platform;
• tema yang berulang;
• overlap antara high build dan high copy score.

AI melakukan heavy lifting di tahap analisis, bukan di tahap indexing.

Hasilnya sistem lebih mudah didebug dan lebih murah dijalankan.

4. CDP rapuh, tapi worth it

Collector saya rusak ketika platform mengubah DOM.

Ini terjadi beberapa minggu sekali.

Saya sudah menerima itu sebagai maintenance cost.

Alternatifnya adalah tidak punya data sama sekali.

Jadi tradeoff-nya sederhana: sisihkan satu jam per bulan untuk memperbaiki selector, lalu lanjut.

5. Cara delivery lebih penting daripada yang terlihat

Saya bisa saja membangun dashboard yang cantik.

Tapi saya memilih Telegram.

Dan itu keputusan yang benar.

Versi Telegram dibaca setiap hari. Dashboard kemungkinan besar hanya dibuka seminggu sekali, kalau ingat.

Kalau tujuannya membantu keputusan harian, delivery harus masuk ke channel yang sudah dipakai setiap hari.

6. Mulai dari satu output

Saya tidak membangun tiga output sekaligus.

Saya mulai dari morning brief.

Setelah stabil, baru tambah build radar.

Setelah itu baru tambah ide konten.

Setiap output mengajarkan sesuatu: cara prompt yang lebih baik, dimensi scoring yang lebih tepat, dan data apa yang sebenarnya perlu dikumpulkan.

Begitulah cara membangun personal automation yang tidak jadi proyek hobi kosong: satu useful loop dulu.

7. Sistem ini untuk keputusan, bukan konsumsi

Ini shift paling penting.

Saya tidak memakai sistem ini supaya bisa membaca lebih banyak.

Saya memakainya supaya bisa memutuskan lebih baik:

• apa yang perlu dibangun;
• apa yang perlu ditulis;
• apa yang perlu diperhatikan;
• apa yang bisa diabaikan.

Itu hubungan yang berbeda dengan informasi.

Bukan konsumsi.

Keputusan.

Berikutnya apa?

Saya sedang menambahkan Hacker News dan beberapa newsletter source ke collection pipeline.

Saya juga mulai eksperimen dengan weekly trend report, bukan cuma snapshot harian. Jadi yang dilihat bukan hanya item apa yang menarik hari ini, tapi bagaimana score dan tema bergerak dari waktu ke waktu.

Ada juga rencana untuk membuka build radar ke tim Radian, supaya opportunity bisa ditriage bareng, bukan cuma jadi insight pribadi.

Tapi jujur, sistem ini sudah melakukan hal utama yang saya butuhkan.

Big win-nya datang dari 20% effort pertama:

• kumpulkan data;
• score dengan dimensi yang benar;
• kirim ke tempat yang pasti saya baca.

Sisanya optimasi.

Dan optimasi biasanya kalah menarik dibanding membangun hal berikutnya.

Kalau kamu sedang membangun sistem serupa atau mau ngobrol soal detail teknisnya, saya ada di X: @fanani.