Fast (Fast AF, Inc.)

Model Fast menaruh tombol checkout di situs merchant beragam (WooCommerce, BigCommerce, tema/plugin custom). Sampel acak 50 situs merchant menemukan 19 tak menampilkan tombol Fast sama sekali, dan sebagian penjual melaporkan integrasi tidak selalu berfungsi. Produk yang seharusnya 'universal' justru tidak andal di lapangan.

Produk embed/widget pihak ketiga punya matriks lingkungan yang nyaris tak terbatas: setiap situs host adalah kombinasi CSS, JS, urutan load, dan checkout flow yang berbeda. Keandalan bukan properti kode-mu saja, tapi interaksinya dengan lingkungan yang tak kamu kontrol — dan itu hanya terbukti lewat pengujian di lapangan nyata, bukan di demo terkurasi.

• Demo selalu mulus tapi keluhan 'tidak muncul/tidak jalan' dari merchant nyata
• Tidak ada monitoring render-rate & success-rate tombol per merchant di produksi
• Metrik yang dibanggakan adalah 'jumlah integrasi', bukan 'persentase integrasi yang benar-benar berfungsi'
• Tidak ada suite pengujian lintas-lingkungan (matrix testing) atas situs host populer
• Tim tak tahu berapa banyak tombol yang gagal render sampai pihak luar yang mengukurnya

• Instrumentasi render-success-rate & checkout-completion-rate per merchant sebagai SLO kelas satu, pantau di produksi
• Bangun matrix testing atas platform & tema host paling umum; jadikan syarat rilis
• Sediakan health-check/telemetry per integrasi sehingga kegagalan terdeteksi tim, bukan oleh jurnalis
• Ukur adopsi dari integrasi yang berfungsi, bukan sekadar yang terpasang

Versi pertama produk yang dipakai mendemokan Fast ke VC disebut dibangun oleh engineer outsourcing di Nigeria yang kemudian dipecat dan 'dihapus' dari narasi perusahaan (klaim eks-engineer). Pengetahuan tentang fondasi awal tidak dipertahankan bersama orang-orang yang membangunnya.

Ketika kode/arsitektur inti lahir dari tim yang lalu dilepas tanpa transfer pengetahuan terstruktur, perusahaan mewarisi sistem yang 'ada tapi tak dipahami penuh'. Ini menaikkan bus factor sejak awal dan menanam utang: keputusan desain awal jadi kotak hitam bagi tim penerus, dan konteks 'kenapa dibangun begini' hilang.

• Fondasi produk dibangun kontraktor/tim yang segera dilepas tanpa handover terdokumentasi
• Kredit atas kerja teknis tidak transparan (klaim 'diambil alih' oleh pimpinan)
• Tidak ada dokumentasi arsitektur/runbook yang bertahan melampaui individu
• Perputaran tim inti tinggi di fase paling formatif produk
• 'Siapa yang paham komponen X?' tak punya jawaban jelas

• Perlakukan transfer pengetahuan sebagai deliverable wajib saat mengganti tim/kontraktor, bukan afterthought
• Dokumentasikan keputusan arsitektur (ADR) & runbook yang hidup independen dari orang tertentu
• Jaga kesinambungan kepemilikan teknis pada komponen inti; hindari 'reset' tim di fase formatif tanpa jembatan
• Bangun budaya kredit yang jujur — retensi engineer kunci adalah risiko bisnis, bukan sekadar isu HR

Fast adalah lapisan identitas/UX satu-klik di atas rail pembayaran Stripe. Nilai teknisnya terkonsentrasi di tombol + pengenalan pengguna lintas situs — kapabilitas yang bisa direplikasi pemain berekosistem besar (Shop Pay dengan basis Shopify, Apple Pay, Bolt). Tanpa volume transaksi & lock-in merchant, tak ada penghalang kompetitif teknis.

Di pembayaran, moat sejati adalah skala (volume, basis pengguna, integrasi mendalam, data risiko/fraud), bukan lapisan UX tipis. Startup yang menjual 'pengalaman lebih mulus' di atas infrastruktur orang lain rentan: begitu incumbent menyalakan fitur setara di atas basis pengguna yang sudah ada, keunggulan pendatang menguap.

• Nilai produk hampir seluruhnya di UX/tombol, bukan kapabilitas yang sulit dibangun
• Bergantung penuh pada satu vendor rail (Stripe) untuk fungsi inti
• Tidak ada lock-in merchant; tombol mudah dicopot dan diganti
• Kompetitor punya ekosistem tertutup + basis pengguna jauh lebih besar
• Ekonomi fee-per-transaksi hanya jalan pada volume masif yang belum ada

• Uji sejak awal: 'apa kapabilitas teknis kita yang sulit direplikasi incumbent dalam 6–12 bulan?' — kalau tak ada, moat-nya rapuh
• Kejar lock-in yang sah (integrasi mendalam, data yang makin berharga seiring pemakaian) alih-alih hanya UX
• Di pasar volume, prioritaskan jalur ke volume transaksi nyata sejak dini, bukan jumlah integrasi
• Pertimbangkan niche/vertical yang defensible ketimbang bertarung 'universal' melawan raksasa berekosistem

Fast merekrut ~150 engineer (dari >400 total karyawan) untuk produk yang tombolnya di-render <500.000 kali/hari dan menghasilkan ~US$600K/tahun. Biaya tim jadi komponen terbesar burn ~US$10 juta/bulan, sementara beban teknis nyata bisa dilayani infrastruktur sangat kecil. Aset yang tersisa saat tutup adalah tim itu sendiri (~100 diserap Affirm).

Modal murah menggoda perusahaan menstaff untuk skala yang diproyeksikan, bukan skala yang terbukti. Tapi headcount engineering adalah biaya tetap yang berat: ia tak hanya menambah gaji, tapi kompleksitas koordinasi & proses. Tanpa product-market fit, 'kesiapan skala' menjadi burn yang mempercepat kematian, bukan pertumbuhan.

• Jumlah engineer/karyawan dipakai sebagai proxy kemajuan, bukan throughput/pendapatan
• Rasio kapasitas terbangun terhadap beban produksi nyata sangat timpang
• Biaya tim jadi mayoritas burn tanpa metrik utilisasi yang membenarkannya
• Rekrutmen agresif mendahului bukti permintaan
• 'Kita bangun untuk skala' dipakai membenarkan kompleksitas & headcount sebelum ada trafik

• Skalakan tim mengikuti beban & pendapatan terbukti, bukan proyeksi optimistis
• Pantau rasio kapasitas-vs-beban dan burn-per-unit-throughput sebagai metrik disiplin
• Utamakan arsitektur sederhana yang bisa dijalankan tim kecil sampai PMF jelas
• Tetapkan milestone throughput/pendapatan sebagai syarat sebelum menambah headcount besar

Produk Fast menyimpan identitas dan kredensial pembayaran pengguna serta mengenalinya lintas situs. Saat tutup mendadak, layanan dimatikan dan data pengguna dijadwalkan dihapus dalam wind-down ~10 hari. Tidak ada bukti breach — tapi model datanya memikul kewajiban privasi yang serius. Inferensi defensif, bukan tuduhan kebocoran.

Sistem yang menyimpan data sensitif harus dirancang tidak hanya untuk hidup, tapi untuk mati dengan tertib: penghapusan data yang teruji, revocation kredensial, dan portabilitas keluar. Startup jarang menganggarkan 'skenario penutupan' dalam desain data — padahal justru di momen krisis, kegagalan offboarding data menimbulkan risiko hukum & kepercayaan terbesar.

• Menyimpan kredensial pembayaran/PII lintas situs tanpa jalur penghapusan yang teruji
• Tidak ada rencana data offboarding/deletion untuk skenario shutdown atau merchant churn
• Wind-down mendadak memaksa keputusan penghapusan data secara improvisasi
• Ketergantungan pada 'kebijakan privasi' tertulis tanpa mekanisme teknis yang membuktikannya
• Tidak ada audit trail bahwa data benar-benar terhapus & kredensial dicabut

• Rancang data deletion & credential revocation yang teruji sebagai bagian arsitektur sejak awal, bukan tempelan
• Minimalkan data sensitif yang disimpan; manfaatkan tokenisasi/vault vendor agar permukaan risiko kecil
• Siapkan runbook 'graceful shutdown/offboarding' (ekspor, hapus, cabut akses) sebelum dibutuhkan
• Simpan bukti/audit penghapusan untuk memenuhi kewajiban privasi & menjaga kepercayaan