06 · Pipeline Pengembangan

Fondasi Sekali Jadi, Frontend Bertahap

Prinsip eksekusi: database dan tulang punggung backend dirancang penuh untuk semua modul di awal, supaya tidak ada perombakan struktur di tengah jalan. Frontend digarap bertahap dalam dua gelombang. Gelombang A wajib selesai lebih dulu: INTERNAL, SPAREPART, CUSTOMER, VENDOR. Gelombang B (MEKANIK, RENTAL, integrasi kemitraan) tersimpan sebagai backlog terencana: tabelnya sudah ada di database, pengerjaannya menunggu gelombang pertama stabil. Angka "tahun" pada roadmap bisnis adalah asumsi; yang mengikat adalah urutan dan kriteria selesai.

Dua hal yang mengubah bentuk rencana ini (revisi 2026-08-05). Pertama, timnya 3 orang — 2 web developer + 1 mobile developer; pembagian aplikasinya dikunci pemilik 2026-08-06: ahramadhani (fondasi + API internal + marketplace), npkevin7 (aplikasi staf + portal vendor), daniramdhani01 (mobile). Kedua, sebagian kriteria selesai terkunci kalender, bukan effort: "satu bulan penuh stok bergerak" dan "satu siklus PO import ±2 bulan" tidak bisa dipercepat dengan menambah orang. Konsekuensinya urutan tidak lagi berantai penuh — hanya "INTERNAL duluan" yang benar-benar dependensi data; sisanya diparalelkan.

Peta Alur Lengkap

fondasi sekali jadi → Gelombang A (prioritas) → gerbang kualitas → Gelombang B (backlog) — garis putus-putus = belum dikerjakan

Ctrl/Cmd + scroll untuk zoom. Drag untuk geser. Klik dua kali untuk fit.

Memuat...

Gelombang A — Prioritas, Wajib Finish Dulu

urutan mengikuti dependensi data · kriteria selesai = kontrak yang bisa ditagih

Fondasi — Sekali Jadi

schema penuh · sebelum fitur pertama

Monorepo newpt-platform (nama kerja) berisi apps/api (Express 5 + TS), apps/worker (Go, antrean job Postgres untuk kerja CPU-berat), tiga aplikasi web, dan aplikasi React Native. Auth dengan peran, entitas legal KMT/PUM, Caddy untuk TLS, VPS dengan backup harian, SeaweedFS (container) untuk penyimpanan file, dan migrasi database lengkap untuk SEMUA modul. Struktur berhenti berubah di sini.

Lima hal yang wajib benar sekarang karena mahal permanen kalau terlewat: idempotency dengan penyimpanan respons (retry di sinyal buruk tidak boleh melahirkan baris ledger ganda — dan di ledger append-only baris itu tidak bisa dihapus); kolom aktor created_by/device_id; tabel sesi, refresh token, dan device; opname disimpan sebagai event dengan server yang menurunkan delta; serta REVOKE UPDATE, DELETE pada stock_movements supaya sifat append-only dijamin engine, bukan disiplin orang.

Selesai berarti: seluruh schema termigrasi dan teruji; login cookie (web) dan Bearer (mobile) sama-sama menghasilkan Principal yang sama; kirim request tulis dua kali menghasilkan satu baris ledger dengan respons kedua replay 200; backup pernah diuji restore; satu perintah deploy dari commit ke server.

Modul INTERNAL

prioritas 1 · sumber data semua modul lain

Operasional dua CV pindah ke sistem, dengan sub-urutan: katalog + cross-reference → ledger stok + opname perdana dari Excel → penjualan per entitas (stok keluar otomatis, dashboard, ekspor pembukuan) → purchasing + histori harga supplier (IDR/USD/RMB). Pesanan telepon/WA tetap diinput di sini; kanal lama hidup, datanya terpusat.

Selesai berarti: stok bergerak sendiri mengikuti transaksi nyata sebulan penuh tanpa koreksi di luar opname; satu siklus PO import (±2 bulan) tercatat utuh; dashboard dipakai rapat mingguan. Dua kriteria pertama terkunci kalender — menambah orang tidak mempercepatnya.

App Staf Opname & Penerimaan Barang

mobile · JALUR KRITIS, paralel dengan INTERNAL

Aplikasi React Native untuk staf gudang: scan dan hitung opname, terima barang dari PO, toleran sinyal buruk lewat antrean lokal dengan retry idempoten, sinkron delta katalog. Menghitung stok fisik di gudang sambil memegang laptop adalah alur kerja yang salah bentuk — ini alur paling mobile-native di seluruh sistem, dan pasangan alami dari ledger append-only.

Ini juga pilihan aman untuk aplikasi mobile pertama: basis terpasangnya HP staf sendiri, terkendali dan bisa dipaksa update, jadi risiko versioning jauh lebih rendah daripada aplikasi pelanggan. Sekaligus memberi API konsumen nyata lebih awal, sehingga bentuk payload distabilkan oleh pemakaian, bukan oleh tebakan.

Selesai berarti: opname pertama dilakukan sepenuhnya lewat HP dan hasilnya cocok dengan hitungan manual; request tulis yang di-retry di sinyal buruk tidak pernah menghasilkan baris ledger ganda.

Modul SPAREPART

prioritas 2 · etalase publik pertama

Katalog yang sudah terkurasi modul INTERNAL dibuka ke publik: pencarian part dengan cross-reference nomor alternatif, harga dan ketersediaan real-time dari ledger yang sama, dan checkout yang menulis ke sales_orders berkanal marketplace. Tidak ada duplikasi data; etalase hanyalah pintu baru ke fondasi yang sama.

Selesai berarti: pembeli menemukan part lewat nomor apa pun yang ia tahu; pesanan marketplace pertama dari pelanggan nyata Kalsel selesai sampai barang terkirim dan tercatat di ledger.

Modul CUSTOMER

prioritas 3 · boleh PARALEL dengan SPAREPART

Akun publik (external_accounts — ADR-003, satu kolam untuk pembeli/vendor/mitra) dengan riwayat pembelian dan servis, armada unit (customer_units: brand, model, nomor seri) sebagai dasar rekomendasi part yang pasti cocok, invoice rapi, dan status garansi. Riwayat per unit inilah switching cost yang membuat pelanggan menetap.

Selesai berarti: pelanggan lama dua CV punya akun berisi riwayatnya; pencarian part bisa difilter "cocok untuk unit saya"; invoice bisa diunduh tanpa minta ke admin.

Modul VENDOR

prioritas 4 · penutup Gelombang A

Distributor dan supplier lokal bergabung: onboarding dengan kurasi, listing produk yang menempel ke katalog pusat (vendor_listings → products, bukan katalog liar), dashboard penjualan, dan penyelesaian pesanan yang dipenuhi stok vendor. Dari sinilah supply chain Level 2 dan 3 (supplier lokal, vendor darurat) berubah dari strategi menjadi fitur.

Selesai berarti: vendor pertama di luar dua CV menyelesaikan pesanan lewat platform; listing vendor tampil di pencarian sparepart dengan pembeda jelas dari stok CV.

Gerbang Kualitas & Finishing Gelombang A

syarat membuka Gelombang B

UAT bersama staf dan pelanggan pilot, pelatihan pengguna, dokumentasi cara pakai, monitoring dan alert server, gladi resik restore backup. Empat modul prioritas harus dipakai transaksi nyata, bukan sekadar selesai dibangun.

Selesai berarti: operasional harian dua CV plus marketplace berjalan tanpa pendampingan developer; insiden punya jalur lapor; angka sistem dipercaya pemilik.

Gelombang B — Backlog Terencana

MEKANIK · RENTAL · KEMITRAAN — tabel DB sudah menunggu

MEKANIK (booking teknisi, jadwal, tracking, estimasi biaya) dan RENTAL (listing unit, kalender, GPS, pembayaran) dibangun di atas tabel yang sudah ada sejak fondasi; menyusul integrasi kemitraan (financing, asuransi, logistik). Tiap modul mendapat sesi perancangan dan kriteria selesai sendiri sebelum baris kode pertama. Rincian scope tersimpan di dokumen plan pengembangan lanjutan.

Pemicu mulai: gerbang kualitas Gelombang A lolos, dan ada permintaan nyata (booking servis / sewa unit) dari pelanggan platform — bukan sekadar jadwal kalender.

Keputusan yang sudah dikunci di halaman ini: schema database dan tulang punggung backend dibuat penuh di fondasi; frontend bertahap dengan urutan INTERNAL → SPAREPART → VENDOR, dengan CUSTOMER boleh paralel dan app staf opname berjalan bersamaan sejak awal; MEKANIK dan RENTAL menunggu di backlog terencana dengan pemicu yang jelas; "tahun" pada roadmap bisnis adalah asumsi — yang ditagih adalah kriteria selesai; dan setiap modul membawa finishing-nya sendiri (UAT, pelatihan, monitoring), bukan ditumpuk di akhir proyek. Keputusan arsitektur yang mengikat ada di adr-001-arsitektur-platform.md.