KISS atau Mati: Mengapa Insinyur Senior Gagal di Startup

Startup pertama saya adalah kegagalan, dan beberapa startup tetangga juga gagal. Kami memiliki: kredit GCP senilai $100K, insinyur pendiri yang telah membangun sistem di perusahaan besar, dan strategi go-to-market. Dan kami gagal, bukan karena kami membangunnya dengan salah, tetapi karena kami membangunnya dengan baik. Itulah masalahnya.

Sementara kami menghabiskan waktu bergulat dengan apa yang terasa seperti tech stack yang "tidak optimal", kami kehilangan hal yang paling penting: waktu, momentum, dan secara strategis sebuah peluang.

Cerita ini bukan tentang orang-orang tanpa akal sehat. Saya memiliki akal sehat, dan kami tahu kami harus menjaga agar semuanya tetap sederhana. Tetapi ketika model mental Anda tidak sesuai dengan situasi, semua akal sehat Anda tersapu. Anda membuat keputusan "benar" yang justru membunuh Anda.

Ini juga bukan cerita tentang rekayasa yang buruk. Ini tentang bagaimana rekayasa yang baik membunuh startup. Bagaimana pengalaman yang membuat Anda senior justru menjadi tanggung jawab terbesar Anda. Bagaimana "melakukannya dengan benar" atau bahkan "melakukannya dengan sederhana" seringkali adalah melakukannya dengan salah.

Artikel ini menyajikan model mental untuk membantu Anda membuat keputusan yang tepat dan menghindari kesalahan yang saya buat.

:::tip Untuk siapa ini: insinyur senior yang memulai atau bergabung dengan startup tahap awal. Jika Anda telah menghabiskan 5+ tahun di perusahaan besar atau Big Tech, ini adalah peringatan Anda.

:::

\

Model Mental #1 - Infrastruktur "Gratis" Adalah Yang Paling Mahal

Kredit GCP senilai $100K tampak seperti hadiah, tetapi itu adalah jebakan. Ini mendorong Anda ke arah over-engineering karena "sudah dibayar." Anda mendapatkan instance komputasi, load balancer, container registry, dan alat-alat enterprise yang memerlukan pengaturan enterprise. Apa yang Anda butuhkan? Tombol "push to deploy".

Tentu, Anda dapat membangun alur kerja "deploy dari GitHub ke VM" di GCP/AWS/Azure. Beberapa produk hampir mendekati. Tetapi itu memerlukan langkah tambahan: mengonfigurasi Cloud Build, menyiapkan peran IAM, menulis skrip deployment, mengelola rahasia, dan mengonfigurasi pemeriksaan kesehatan. Anda membakar waktu membangun infrastruktur deployment sebelum men-deploy produk yang sebenarnya.

Sementara itu, platform seperti Railway atau Fly.io memberi Anda apa yang benar-benar dibutuhkan startup: VM persisten dengan deployment start-and-go dari GitHub. Semudah mungkin: Anda push kode Anda, dan itu ter-deploy. VM siap pakai dengan variabel lingkungan, SSL, load balancer, log, dll. Ini tidak "gratis," tetapi siap pakai.

Kredit gratis mendorong Anda ke arah over-engineering karena "sudah dibayar." Anda meyakinkan diri sendiri bahwa Anda menghemat uang sementara menghabiskan sumber daya paling berharga Anda: waktu.

\

Model Mental #2 - "Minimal" <> "Sederhana"

Prinsip KISS tradisional memberi tahu kita untuk menjaga perangkat lunak kita tetap sederhana. Tetapi di startup, itu adalah target yang salah. Anda tidak harus menjaga SOFTWARE Anda tetap sederhana; Anda harus menjaga SOLUSI Anda tetap sederhana.

Kesederhanaan nyata harus diukur dengan total usaha, bukan kompleksitas kode:

Total Usaha = Pembangunan Awal + Pemeliharaan + Debugging + Penambahan Fitur + Pembaruan Keamanan + Perubahan Skala

Ketika Anda membangun dari awal, Anda memiliki semua ini selamanya. Ketika Anda menggunakan layanan, sebagian besar dari ini menjadi nol. Layanan pihak ketiga yang "membengkak" sebenarnya adalah solusi sederhana karena meminimalkan total usaha.

Contoh OAuth Saya

Insinyur pendiri kami memutuskan untuk membangun OAuth dari awal alih-alih menggunakan "library yang tidak dikenal." Satu minggu kemudian, dia mengirimkan PR: implementasi OAuth yang bersih dengan token JWT, rotasi token penyegaran, manajemen sesi, dan kontrol akses berbasis peran. Tidak ada dependensi, tidak ada vendor lock-in, hanya kode yang kami kendalikan.

Saya tidak menolak PR tersebut. Dan ini adalah kesalahan. Membuang pekerjaan seminggu akan menghancurkan moral. Tetapi itu menciptakan kompleksitas kode dan menempatkannya pada jalur yang salah. Selain itu, tidak mendiskusikan pendekatan sebelumnya adalah kesalahan nyata kami. Kami membiarkan kebanggaan teknik membuat keputusan strategis.

Kemudian, klien membutuhkan OAuth Microsoft dan OAuth Google. Implementasi kustom berarti hari-hari refactoring, rotasi token penyegaran, kasus-kasus tepi, RBA, dan hal-hal lainnya. Setiap penambahan "sederhana" memerlukan pemahaman mendalam tentang auth kustom kami. Setiap pembaruan keamanan adalah milik kami untuk diimplementasikan. Setiap persyaratan baru adalah milik kami untuk dikodekan.

Prinsip

Kesalahan insinyur senior klasik: mengoptimalkan untuk kontrol alih-alih hasil. Di startup, realitas mengharuskan pembalikan total cara berpikir insinyur senior:

1. BERHENTI berpikir: "Ini hanya beberapa hari coding" \n MULAI berpikir: "Ini beberapa hari TIDAK mengkode produk saya yang sebenarnya"
2. BERHENTI berpikir: "Saya bisa membangun ini dengan sederhana" \n MULAI berpikir: "Saya bisa menyelesaikan ini dengan sederhana dengan tidak membangun"
3. BERHENTI berpikir: "Layanan pihak ketiga menambah kompleksitas" \n MULAI berpikir: "Layanan pihak ketiga menyerap kompleksitas"

\

\

Model Mental #3 - Pilihan Kenyamanan

Kami memilih Angular karena insinyur pendiri kami mengetahuinya secara mendalam. Keputusan cerdas, bukan? Gunakan kekuatan Anda, kirim kode berkualitas. Framework-nya baik, TETAPI masalahnya adalah ekosistemnya.

Jebakan Ekosistem

Angular sangat bagus dan insinyur kami bisa membangun apa saja dengannya.

Tetapi "apa saja" membutuhkan waktu hanya untuk memulai. Menyiapkan deployment, autentikasi, dan komponen UI dasar berarti konfigurasi tanpa akhir sebelum menulis satu fitur pun. Sementara kami men-debug tema Angular Material, pesaing dapat (dan akan) menggunakan Next.js + Vercel yang sudah melakukan onboarding pengguna.

Bandingkan saja dengan jalur Next.js + Vercel: deploy aplikasi kerangka dengan npx create-next-app pada hari pertama, tambahkan autentikasi Clerk dan komponen shadcn/ui, kirim fitur aktual pada hari pertama. Tujuan yang sama, perjalanan yang benar-benar berbeda.

Mengapa ini terjadi?

Perbedaannya bukan pada kualitas framework, tetapi pada optimasi ekosistem. Next.js/React dikelilingi oleh startup yang didukung venture yang membangun alat untuk startup lain:

• UI: shadcn/ui - salin, tempel, kirim
• Auth: Clerk/Supabase - konfigurasi dalam hitungan menit
• Deploy: Vercel - git push sama dengan produksi
• Semua yang lain: Jika startup membutuhkannya, seseorang telah membangun layanannya

Ekosistem Angular melayani perusahaan besar: kuat, fleksibel, dapat disesuaikan tanpa batas. Sempurna(?) untuk tim dengan 50 orang dan racun untuk tim dengan 3 orang.

\

Model Mental #4 - Bangun Inti, Sewa Konteks

Tetapi bahkan dengan alat yang tepat, ada satu jebakan terakhir: dorongan untuk membangun sesuatu karena Anda bisa, bukan karena Anda harus. Jebakan ini membunuh tim yang kuat secara teknis dan lebih banyak startup daripada yang bisa kita bayangkan: membangun hal-hal yang tidak diminta oleh siapa pun karena Anda bisa, bukan karena Anda harus.

Kami menghabiskan setidaknya sebulan total untuk fitur yang tidak dibutuhkan siapa pun. OAuth kustom ketika Auth0 sudah ada. Antrian pekerjaan berbasis Postgres ketika Redis + Celery sudah ada. Terraform dari hari pertama, ketika konsol berfungsi dengan baik. Setiap keputusan terasa produktif, tetapi masing-masing adalah sabotase diri untuk menghadapi tantangan nyata seperti berbicara dengan pelanggan atau melakukan pengembangan pelanggan lainnya.

Polanya sederhana: jika pelanggan tidak akan memilih Anda karenanya, jangan membangunnya.

Aturan $50 Saya

Jika SaaS biayanya kurang dari $50/bulan, Anda tidak mampu membangunnya. Waktu Anda terlalu mahal.

Membangun OAuth kustom membutuhkan 1-2 minggu total pemeliharaan dan menambahkan penyedia OAuth yang berbeda. Pada tingkat pembakaran startup, itu $5.000-$15.000 dalam waktu rekayasa, atau dalam waktu kehilangan peluang. Auth0 gratis untuk hingga 25.000 pengguna aktif, kemudian $35/bulan. Anda bisa membayar Auth0 selama 35 tahun dengan biaya yang diperlukan untuk membangunnya sekali.

Jadi, ini bukan tentang uang tetapi tentang prioritas dan biaya peluang.

Pengecualian

Menurut pendapat saya, bangun hanya jika Anda tidak dapat belajar tentang pengguna tanpanya.  Contoh sederhana adalah ketika Anda perlu menguji apakah pengguna akan membayar untuk laporan yang dihasilkan AI. Bangun versi paling sederhana yang membuktikan permintaan. Dan semua hal lain mencoba untuk tergelincir. Ya, lewati infrastruktur, lewati "melakukannya dengan benar", lewati praktik terbaik yang tidak mengirimkan fitur, lewati pengujian. Sekali lagi, jadilah semalas mungkin dalam menulis kode.

Apa Yang Sebenarnya Saya Gunakan

• Auth: Clerk (React-native, DX lebih baik) atau Auth0 (fokus B2B, siap enterprise)
• Email: Resend (developer-first) atau SendGrid (teruji pertempuran)
• Analytics: PostHog (gratis sampai skala)
• Monitoring: Sentry (tak tertandingi untuk kesalahan)
• Hosting: Cloudflare atau Vercel (jika sepenuhnya menggunakan Next.js)

Ini bukan dukungan tetapi pilihan saya sendiri yang dioptimalkan untuk kecepatan. Saya kira stack Anda akan berbeda tetapi prinsip ini tidak akan berubah.

\

\

Kesimpulan

LLM telah mengkomoditisasi pembangunan. Setiap junior dengan Claude dapat membuat sistem auth kustom yang Anda banggakan. Nilai Anda bukan lagi pada apa yang dapat Anda bangun, TETAPI pada mengetahui apa yang tidak perlu dibangun.

Kepemimpinan adalah kemampuan untuk memisahkan sinyal dari kebisingan. Senioritas sejati berarti memiliki disiplin untuk mengabaikan 90% dari apa yang Anda ketahui dan mengirimkan solusi hari ini, bukan arsitektur masa depan.