Panduan Lengkap Memilih Technology Stack

Technology stack adalah seluruh teknologi yang dipakai untuk membangun, menjalankan, menyimpan data, mengamankan, dan mengoperasikan aplikasi. Pilihan yang baik bukan stack dengan nama paling banyak, melainkan kombinasi paling sederhana yang memenuhi kebutuhan wajib dan masih dapat dirawat oleh tim.

Prinsip utama: pilih dari kebutuhan produk, bukan dari tren atau vendor. Jika project berasal dari AI Blueprint, jadikan Technical Foundation, Database Schema, dan UI/UX Design sebagai sumber keputusan utama.

1. Hasil yang Harus Anda Dapatkan

Setelah mengikuti panduan ini, Anda seharusnya dapat menjelaskan:

• aplikasi apa yang dibangun dan siapa penggunanya;
• platform yang harus didukung: web, mobile, desktop, atau kombinasi;
• strategi frontend dan rendering;
• tempat business logic dijalankan;
• database utama dan layanan khusus yang benar-benar dibutuhkan;
• model hosting yang cocok dengan runtime;
• baseline security, backup, monitoring, dan deployment;
• alasan memilih stack, alternatif kedua, risiko, dan kapan pilihan perlu ditinjau ulang.

Stack akhir bukan sekadar daftar logo. Ia adalah keputusan arsitektur yang dapat diuji.

2. Peta Lapisan Technology Stack

Satu framework dapat mengisi beberapa lapisan. Next.js, misalnya, dapat menangani UI dan server code, tetapi browser dan server tetap memiliki batas keamanan berbeda. Secret tidak boleh masuk ke frontend hanya karena code berada dalam repository yang sama.

Engine, provider, dan framework adalah hal berbeda

• PostgreSQL adalah database engine; Supabase, Neon, RDS, Cloud SQL, dan self-hosted PostgreSQL adalah cara menyediakannya.
• React adalah UI library; Next.js adalah framework dengan routing dan kemampuan server.
• Docker adalah platform container; bukan bahasa, database, atau hosting.
• Node.js adalah runtime; npm, pnpm, dan Yarn adalah package manager.

Membedakan istilah ini membuat diagnosis dan migrasi jauh lebih mudah.

3. Mulai dengan Decision Brief

Jangan memilih provider sebelum pertanyaan berikut terjawab.

Produk dan tim

Traffic dan pengalaman user

• Seberapa penting SEO dan kecepatan halaman pertama?
• Apakah mayoritas halaman public atau berada di balik login?
• Apakah interaksi seperti aplikasi, realtime, offline, atau media-heavy?
• Dari wilayah mana user mengakses aplikasi?
• Apakah traffic stabil, musiman, viral, atau belum diketahui?

Data dan operasi

• Apakah data memiliki banyak relasi dan transaksi lintas tabel?
• Apakah ada payment, audit log, file upload, search, atau geospatial?
• Apakah consistency kuat wajib, atau eventual consistency dapat diterima?
• Berapa kehilangan data maksimum yang dapat diterima (RPO) dan waktu pemulihan maksimum (RTO)?
• Apakah ada data residency, compliance, private network, atau enkripsi khusus?
• Siapa yang melakukan deployment, monitoring, backup, dan incident recovery?

Jika jawabannya belum diketahui, tulis unknown dan pilih solusi yang mudah diubah. Jangan mengubah ketidakpastian menjadi arsitektur kompleks.

4. Gunakan Hard Gate sebelum Scoring

Hard gate

Eliminasi pilihan yang gagal pada kebutuhan wajib, walaupun populer atau murah. Contohnya:

• runtime atau protocol yang dibutuhkan tidak didukung;
• region yang diwajibkan tidak tersedia;
• transaksi, backup, restore, atau WebSocket wajib tidak didukung;
• jalur produksi, lisensi, compliance, atau data residency tidak sesuai;
• minimum biaya sudah melewati anggaran;
• database harus diakses dari browser tanpa model otorisasi yang aman.

Scoring setelah lolos gate

Beri nilai 0-5 untuk setiap kandidat. Bobot awal berikut dapat disesuaikan:

Untuk solo founder, naikkan bobot time-to-market dan beban operasional. Untuk enterprise, naikkan reliability, security, compliance, dan portability. Catat juga penalti untuk teknologi beta, region database yang jauh, workaround inti, atau skill tim yang tidak sesuai.

5. Sesuaikan Kompleksitas dengan Tahap Produk

Naik tahap karena bukti: antrean menahan request, query lambat, storage membesar, kebutuhan recovery berubah, atau organisasi membutuhkan boundary. Bukan karena arsitektur yang lebih besar terlihat lebih profesional.

6. Pilih Frontend dan Strategi Rendering

Tentukan rendering terlebih dahulu

Pilih framework dari karakter produk

TypeScript biasanya membantu kontrak data dan refactor. Component library seperti shadcn/ui, Material UI, atau library internal mempercepat aksesibilitas dan konsistensi, tetapi tetap perlu design tokens, responsive states, empty/error/loading states, dan visual QA.

Record frontend yang perlu disimpan di knowledge base

Jangan simpan frontend sebagai nama framework saja. Satu record minimal memuat:

Untuk setiap upgrade besar, jalankan build, route smoke test, server/client boundary test, dan screenshot regression pada screen penting.

7. Tentukan Strategi Web dan Mobile

React Native + Expo cocok bila tim kuat di TypeScript/React. Flutter memberi kontrol UI lintas platform dengan Dart. Native memberi akses device dan performa terbaik, tetapi biaya skill, testing, dan release dua platform lebih tinggi.

Game real-time, grafis berat, AR/VR, audio intensif, dan simulasi fisik perlu jalur khusus seperti Unity, Unreal, Godot, atau native graphics stack. Jangan memaksa framework web bisnis menjadi game engine.

8. Pilih Backend dan Model Hosting Bersama-sama

Bentuk backend

Model hosting

Framework dan hosting harus kompatibel. Static export tidak menjalankan server action. Worker edge tidak selalu kompatibel dengan package Node.js. Serverless yang membuka banyak koneksi PostgreSQL perlu pooler. Container yang menyimpan file lokal perlu strategi persistent volume atau object storage.

Matriks evaluasi hosting provider

Untuk Coolify atau VPS, ownership operasi berada pada tim: patch OS, kapasitas disk, backup, firewall, certificate, log rotation, monitoring, dan recovery harus memiliki runbook. UI deployment yang mudah tidak menghilangkan tanggung jawab server.

9. Pilih Database dari Bentuk Data

Database utama

PostgreSQL adalah default yang kuat untuk banyak aplikasi bisnis karena transaksi, relasi, constraint, query, JSON, full-text, dan extension. Namun “default” bukan berarti selalu benar.

Tambahkan database khusus hanya untuk tugas khusus

Arsitektur yang sehat dapat menggunakan:

• PostgreSQL untuk source of truth transaksi;
• Redis untuk cache, rate limit, session, atau queue;
• object storage untuk file besar;
• search engine untuk pencarian kompleks;
• pgvector atau vector database untuk semantic retrieval;
• warehouse/columnar database untuk analytics berat.

Jangan menjadikan cache sebagai source of truth atau database analytics sebagai OLTP utama. Pastikan ownership, sinkronisasi, retry, dan recovery setiap salinan data jelas.

Managed atau self-hosted

Bandingkan backup, point-in-time recovery, pooling, branching, replica, region, encryption, observability, support, dan biaya keluar data. Managed service mengurangi pekerjaan operasi; self-hosted memberi kontrol tetapi memindahkan patching dan recovery kepada tim.

Matriks evaluasi database provider

Sebelum production, buktikan koneksi dari runtime target, jalankan migration di staging, uji restore ke instance terpisah, dan ukur query penting dengan volume data realistis.

Skema record knowledge base

technology_id: postgresql-managed-example
category: primary_database
lifecycle: active
capabilities:
  transactions: true
  point_in_time_recovery: true
  connection_pooling: verify_plan
constraints:
  - region availability depends on provider
  - extensions depend on plan and engine version
cost_model:
  units: [compute, storage, backup, transfer]
verified_at: 2026-09-07
official_sources:
  - provider documentation URL
review_triggers:
  - engine major version changes
  - pricing or plan limits change
  - RPO or data residency requirement changes

Snapshot JSON yang tampil setelah artikel adalah katalog edukasi. Katalog Blueprint di config/knowledge/technology tetap authority untuk generation karena mempunyai version, hash, status approved/proposed, dan compatibility rules.

10. Pola Stack Berdasarkan Use Case

Baseline adalah titik mulai, bukan template yang ditempel tanpa analisis. Payment finansial, healthcare, government, dan data anak membutuhkan review keamanan/compliance khusus.

11. Hitung Total Cost of Ownership

Jangan hanya membandingkan harga paket awal. Hitung:

• compute dan function invocation;
• database compute, storage, backup, replica, dan connection pooling;
• object storage dan bandwidth/egress;
• log, tracing, error monitoring, dan retention;
• email, SMS, payment fee, search, AI token, dan third-party API;
• waktu engineer untuk patching, deployment, incident, dan recovery;
• biaya migrasi dan vendor lock-in.

Harga provider berubah. Simpan model penagihan, unit, kelas biaya (very_low sampai enterprise), risiko lonjakan, tanggal verifikasi, dan URL pricing resmi. Jangan hardcode angka yang cepat kedaluwarsa ke keputusan arsitektur.

12. Security dan Reliability Minimum

Security

• Secret hanya berada di server-side environment atau secret manager.
• Authorization diperiksa di server untuk setiap resource; menyembunyikan tombol bukan security.
• Gunakan least privilege, MFA untuk admin, rate limit, validasi input, dan audit log untuk tindakan sensitif.
• Aktifkan HTTPS, security headers, dependency scanning, dan upload validation.
• Jika client mengakses managed data API, aktifkan dan uji row-level access policy.

Reliability

• Backup harus disertai restore drill; backup yang belum pernah dipulihkan belum terbukti.
• Migration harus versioned, reviewable, dan memiliki forward-fix atau rollback plan.
• Gunakan health check, structured log, error monitoring, uptime alert, dan correlation ID.
• Job harus idempotent, memiliki retry terbatas, dan tidak menagih atau mengirim dua kali.
• Pisahkan local, preview, staging, dan production berikut database serta secret-nya.

13. Decision Tree Praktis

Mulai
├─ Hanya konten public dan form sederhana?
│  └─ Ya → static/SSG + CDN; database mungkin tidak diperlukan
├─ Web app dengan login dan transaksi bisnis?
│  └─ Ya → full-stack app + relational database + server-side authorization
├─ Mobile adalah pengalaman utama?
│  ├─ Butuh cepat, satu tim JS/TS → React Native + Expo
│  ├─ UI lintas platform sangat custom → evaluasi Flutter
│  └─ Integrasi device/performance ekstrem → native
├─ Proses berlangsung lama atau dapat diulang?
│  └─ Ya → queue + worker + idempotency
├─ Search/analytics/vector menjadi beban khusus?
│  └─ Ya → tambah specialized store; pertahankan source of truth
└─ Banyak service dan tim platform tersedia?
   └─ Baru evaluasi orchestration yang lebih kompleks

14. Kontrak Hasil Keputusan

Untuk setiap project, tulis hasil dalam format berikut:

product_stage: mvp
target_platforms: [responsive_web]

recommended_stack:
  frontend: Next.js + TypeScript
  rendering: hybrid
  backend: Next.js server modules
  primary_database: PostgreSQL
  hosting_runtime: container_paas

rationale:
  - mendukung halaman public dan area login
  - satu codebase sesuai kapasitas tim kecil
  - transaksi dan relasi membutuhkan SQL

hard_gates_passed:
  - target region tersedia
  - backup dan restore memenuhi kebutuhan
  - runtime mendukung background worker

alternatives:
  - option: Nuxt + PostgreSQL
    trade_off: baik untuk tim Vue, tetapi skill tim saat ini tidak sesuai

risks:
  - koneksi database harus menggunakan pooling
  - proses email dan AI perlu queue sebelum traffic naik

review_triggers:
  - p95 latency melewati target selama 14 hari
  - background jobs mulai menghambat web request
  - kebutuhan data residency berubah

Kontrak ini membantu coding agent memahami alasan dan batasan, bukan hanya menyalin nama teknologi.

15. Anti-pattern yang Harus Dihindari

• Memilih stack karena viral atau karena coding agent paling mengenalnya.
• Menambahkan microservices, Kubernetes, Redis, atau vector database sejak hari pertama tanpa requirement.
• Menggunakan data production untuk local atau preview.
• Membuat lockfile kedua atau mengganti package manager tanpa keputusan eksplisit.
• Mengakses database langsung dari browser dengan credential istimewa.
• Menyimpan file user di filesystem container sementara.
• Menaruh pekerjaan panjang di request synchronous tanpa timeout dan retry design.
• Menganggap free tier sebagai kapasitas production yang dijamin.
• Memilih provider tanpa region, backup, exit plan, dan estimasi TCO.
• Mengganti fondasi Blueprint tanpa memperbarui requirement, schema, dan acceptance criteria.

16. Checklist sebelum Stack Disetujui

• Tipe produk, tahap, platform, user, dan workflow utama tertulis.
• Requirement wajib dipisahkan dari preferensi.
• Semua kandidat lolos hard gate runtime, region, security, dan budget.
• Rendering dipilih per kebutuhan SEO, freshness, dan personalisasi.
• Engine database dipilih sebelum provider database.
• Hosting kompatibel dengan runtime, connection model, worker, dan storage.
• Auth, authorization, audit, secret, backup, dan restore dirancang.
• Estimasi biaya mencakup egress, observability, backup, dan operasi tim.
• Alternatif kedua, risiko, exit plan, dan review trigger terdokumentasi.
• Tim dapat menjalankan, menguji, men-deploy, dan memulihkan stack.
• Technical Foundation dan Database Schema AI Blueprint tetap konsisten.