Empat produk berjalan di atas ini, setiap hari

IndoHRM

Platform HR dan payroll untuk perusahaan Indonesia. Multi-tenant, berumur panjang, dengan logika payroll yang diatur regulasi dan tidak boleh berubah diam-diam.

IndoHRM adalah pengguna terdalam. Payroll adalah jenis kode yang pertanyaan 'kenapa begini?'-nya harus punya jawaban bertahun-tahun kemudian — jadi spesifikasi, requirement, dan keputusan di baliknya hidup di samping test yang membuktikannya.

Yang dipakainya di Oprex

• Spesifikasi & requirement — setiap aturan payroll ditelusuri ke regulasi di baliknya
• Rencana & hasil test — perhitungan payroll diverifikasi ulang sebelum tiap rilis
• Matriks cakupan — aturan payroll mana yang belum punya test adalah kueri, bukan rapat tinjauan
• Pelacakan bug dengan severity — defect payroll dan defect tata letak tidak pernah satu antrean
• Rencana rilis & changelog publik — pelanggan melihat apa yang berubah dan kapan
• Autopilot pada repositori hrm di GitLab

Liqaa

Platform AI percakapan dan customer engagement. Menjalankan live chat dan helpdesk untuk seluruh keluarga produk Kinexa.

Liqaa adalah tempat support dan engineering bertemu. Percakapan menjadi tiket, tiket menjadi bug, bug rilis dalam sebuah versi, dan pelanggan diberi tahu nomor versinya — satu rantai, tanpa rekonsiliasi.

Yang dipakainya di Oprex

• Tiket helpdesk — percakapan pelanggan nyata dinaikkan menjadi defect yang terlacak
• Knowledge base — jawaban disimpan di samping rilis yang membuatnya basi
• Pelacakan bug & diskusi — percakapan yang melahirkan perbaikan tetap menempel padanya
• Rilis & changelog — versi yang rilis diumumkan ke produk yang menyematkannya

Nidaa

Infrastruktur pesan dan notifikasi WhatsApp. Pengiriman volume tinggi, di mana kegagalan senyap tak terlihat sampai pelanggan mengeluh.

Infrastruktur pesan gagal dengan cara yang tidak melempar exception. Nidaa mengandalkan field bug yang diabaikan kebanyakan tim — environment, reproduksibilitas, versi produk — karena di situlah polanya benar-benar muncul.

Yang dipakainya di Oprex

• Pelacakan bug dengan field environment & reproduksibilitas — kegagalan pengiriman jarang bisa direproduksi sesuka hati
• Milestone — pekerjaan keandalan pengiriman dikelompokkan dan dilacak sampai selesai
• Catatan & Memori — keanehan penyedia dan perilaku rate-limit ditulis, bukan dipelajari ulang
• Rencana rilis — perubahan pesan dijadwalkan dengan sengaja, tidak pernah rilis hari Jumat

Wafraa

Platform commerce dan storefront. Menghadap pelanggan, sering berubah, dan rusaknya mahal.

Pekerjaan storefront itu cepat dan tak kenal ampun. Jalur rilis bertahap ada karena perubahan harga yang keluar tanpa pemberitahuan pada hari Jumat adalah cara sebuah akhir pekan lenyap.

Yang dipakainya di Oprex

• Spesifikasi, requirement & test case — perilaku checkout dispesifikasikan sebelum dibangun
• Rencana rilis dengan rollout bertahap — Staging → RC → Stabil
• Matriks cakupan — tidak ada requirement checkout yang rilis tanpa test
• Tag & manajemen aset — aset produk dan kampanye disimpan bersama project

Bagaimana catatan rilis muncul di dalam produk secara otomatis

Saat salah satu produk ini rilis, orang yang memakainya tahu dari dalam aplikasi — tidak ada yang menulis pengumuman terpisah. Mekanismenya cukup kecil untuk dijelaskan lengkap:

Menyambungkannya ke produk Anda sendiri

Aplikasi apa pun yang autentikasinya lewat SSO yang sama bisa melakukannya dalam beberapa baris. Dua endpoint, tanpa SDK.

// saat aplikasi dimuat, setelah pengguna terautentikasi
const r = await fetch("https://api.oprex.id/api/v1/releases/whats-new", { credentials: "include" });
const { data } = await r.json();

if (data) {
  showReleasePopup(data);           // title, version, notes[]
  await fetch("https://api.oprex.id/api/v1/releases/whats-new/seen", {
    method: "POST", credentials: "include",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ releaseId: data.id }),
  });
}

Changelog publik dihasilkan dari catatan yang sama, jadi popup di aplikasi dan halaman publik tidak pernah bercerita berbeda.

Yang kami pelajari dengan menjadi pelanggan sendiri

• Statistik bisa bocor. Jumlah bug kritis dari project yang tidak bisa Anda buka tetap memberi tahu bahwa project itu ada dan sedang terbakar. Karena itulah agregat pun dikontrol aksesnya.
• Pemilik null itu nyata. Pekerjaan yang belum di-triage belum punya project — menyembunyikannya berarti menyembunyikan antrean dari orang yang tugasnya men-triage.
• Integrasi fire-and-forget mati diam-diam. Kami menemukan salah satu integrasi kami diam-diam tidak melakukan apa pun sejak hari ia ditulis. Panggilan lintas layanan kini gagal dengan suara keras.
• Agen tanpa memori mengulang dirinya. Inilah seluruh alasan lapisan MCP ada.