PRD vs SRS vs SDD (2026)

"Banyak project gagal bukan karena developer gagal coding... tapi karena fondasi mereka sedang coding-nya gak jelas." — @stokquproject, TikTok 2026-07-24

Pernah ngerasa kayak gini:

Lo mulai coding Senin, hari Selasa udah stuck karena gak tau edge case apa aja yang harus dihandle. Rabu mutusin "ah ini mah scope creep", discard 40% kerjaan. Jumat baru jalan lagi, push weekend, Sabtu lo burn out.

Masalahnya bukan coding lo lambat. Masalahnya fondasi lo gak jelas.

Solusinya bukan nulis dokumen 50 halaman yang gak ada yang baca. Solusinya: dokumentasi yang cukup untuk tahu apa yang lo bangun, kenapa, dan gimana — sebelum nulis satu baris kode pun.

Artikel ini bahas 2 framework dokumentasi yang bisa lo pilih tergantung project type. Plus: kapan pake yang mana, dan template siap-pakai yang udah disesuaikan untuk solo dev / tim kecil Indonesia.

TL;DR

#	Poin	Detail
1	PRD = kontrak dengan user	Apa yang dibangun & kenapa, goal-oriented, bahasa bisnis
2	SRS = kontrak dengan engineer	Behavior & aturan sistem, presisi, bahasa teknis
3	SDD = kontrak dengan arsitek	Gimana bangunnya, arsitektur, DB, API, caching
4	2 framework: Formal (5 doc) vs Process (6 doc lean)	Pilih sesuai project size, audience, compliance need
5	Default solo dev Indonesia: Process framework	PRD 1 hal + Tech Spec 1 hal + User Flow + Timeline cukup
6	Formal wajib kalau: client korporat, audit, regulated, tim > 5	Compliance, sign-off, scope dispute prevention
7	MVD = Minimum Viable Documentation: 3-4 jam di awal	Hemat 30+ jam di belakang, prevent scope creep
8	Asumsi di PRD = section paling sering dilupain	Padahal paling sering salah — tulis sebagai alarm 6 bulan ke depan
9	Estimasi task = 2x dari best-case lo	90% task makan 2x estimasi, itu normal bukan tanda lo buruk
10	Buffer timeline 20% realistic	Launch week sengaja longgar untuk bug reveal
11	7 tren 2026-2027: Living Docs, AI-assisted, Diátaxis, Docs-as-Code, Auto-gen from code, ADRs, Async-first	Pilih 1-2 yang fit stack lo, jangan kejar semua
12	Tools: Excalidraw (wireframe), Notion/Confluence (docs), MkDocs/Docusaurus (static site), OpenAPI (API)	Fokus ke 1 stack, jangan mix 5 tools
13	5 anti-rekomendasi: gak perlu doc kalau eksperimen 1 hari, gak perlu formal kalau cuma lo, gak perlu SRS kalau gak ada QA, dll	Hemat 5-15 jam kerja
14	Update frequency: PRD mingguan, SRS per sprint, SDD per quarter	Document lifecycle = product lifecycle
15	90-day documentation sprint: Week 1-2 audit, Week 3-6 fill gap, Week 7-10 standardize, Week 11-12 review	Realistic adoption untuk existing project

Mental Model: 3 Alasan Dokumentasi Itu Bukan Overhead

Sebelum masuk framework, clear dulu kenapa ini bukan "tugas administratif yang malesin":

Spec = filter scope creep. 30 menit nulis spec = hemat 3 jam debug. Kalau lo gak nulis requirement, semua "ide bagus" di tengah jalan akan keliatan kayak fitur wajib. Spec tertulis kasih lo pegangan untuk bilang "ini gak ada di spec awal, masuk backlog dulu".
Memory external untuk konsistensi. Lo gak akan inget semua keputusan yang lo ambil di week 1 pas udah di week 6. Dokumen = cara termurah untuk maintain state of mind project.
Onboarding instan. Kalau lo sakit 2 minggu, atau hire freelancer, atau hand off ke temen — orang lain bisa lanjut tanpa lo harus jelasin 4 jam dari scratch.

Cost-nya: 2-6 jam di awal project. ROI: hampir selalu positif, kecuali project lo "coba-coba weekend" yang emang gak expected ke mana-mana.

Tambahannya: Dokumentasi Itu Bukan Beban, Tapi Leverage

Quote dari Paul Graham yang sering di-misinterpretasi: "Write code, not docs." Tapi konteks aslinya adalah tentang founding YC — startup fase awal butuh speed, gak ada waktu formal docs. Setelah product-market fit, dokumentasi jadi LEVERAGE:

Lo bisa hire orang lebih cepet (1 minggu onboard vs 1 bulan)
Lo bisa sleep nyenyak (kalau ada emergency, tim bisa handle tanpa bangunin lo)
Lo bisa exit (kalau project lo di-acquire, due diligence butuh docs)
Lo bisa maintain lebih cepet (gak perlu reverse-engineer keputusan lo sendiri)

Untuk solo dev Indonesia, MVD (Minimum Viable Documentation) = 4 dokumen total 3-4 jam. Itu leverage ratio terbaik per jam kerja.

2 Framework yang Lo Pilih

Ada 2 framework yang umum dipake. Bukan saingan — lo pilih salah satu, atau kombinasikan:

Framework	Untuk Siapa	Output
Formal Engineering (PRD→SRS→SDD→UI/UX→Task)	Tim, client-facing, regulated, formal spec	5 dokumen presisi tinggi
Process-Oriented (PRD→Tech Spec→User Flow→Timeline→Testing→Deploy)	Solo/lean, self-managed, deadline-driven	6 dokumen lean

Quick decision rule:

Project Type	Framework	Kenapa
Bikin SaaS sendirian	Process	Gak ada client yang minta sign-off, lo butuh speed
Freelance project untuk client korporat	Formal	Butuh dokumentasi untuk invoice, scope, sign-off
Side project / eksperimen	Process (bahkan cuma PRD)	Gak perlu full framework, cukup 1-2 halaman
Tim 3-5 orang, startup	Process + sebagian Formal	PRD formal untuk fundraising, sisanya lean
Project pemerintah / perbankan	Full Formal	Butuh compliance, audit trail

Kombinasi paling umum untuk indie/solo: PRD + Tech Spec + User Flow + Timeline. Skip SRS/SDD formal karena cuma lo yang baca, dan lo udah tau arsitekturnya.

Decision Tree Framework Selection

START
  │
  ├─ Ada client yang bayar & butuh sign-off?
  │   ├─ YES → Formal (atau minimal: Formal PRD + Process sisanya)
  │   └─ NO ↓
  │
  ├─ Project di regulated industry (bank/health/gov)?
  │   ├─ YES → Full Formal (compliance audit)
  │   └─ NO ↓
  │
  ├─ Tim lo > 5 orang?
  │   ├─ YES → Formal (komunikasi overhead tinggi)
  │   └─ NO ↓
  │
  ├─ Lo expect investor pitch dalam 6 bulan?
  │   ├─ YES → Formal PRD (untuk deck) + Process sisanya
  │   └─ NO ↓
  │
  ├─ Project bakal di-maintain > 1 tahun?
  │   ├─ YES → Process (PRD + Tech Spec + ADRs)
  │   └─ NO ↓
  │
  └─ Default: Process framework (lean)

Final score threshold:

0-3 YES → Process (lean, 4-6 doc ringkas)
4-6 YES → Hybrid (Formal PRD + Process sisanya)
7+ YES → Full Formal (semua 5 doc, compliance-grade)

Framework #1: Formal Engineering Docs

Buat project yang butuh presisi, sign-off, atau formal record. 5 dokumen, urut.

Step 1: PRD — Product Requirements Document

Isi: Apa dan kenapa, bukan gimana.

Komponen (stokquproject + IEEE/Atlassian):

Section	Isi	Penting?
Tujuan Produk	1 paragraf: masalah apa yang di-solve	WAJIB
Target User	Persona, use case	WAJIB
Core Features	List fitur, prioritas (must/should/nice)	WAJIB
User Flow	Journey dari onboarding sampai retention	WAJIB
Success Metrics	KPI yang ngukur produk berhasil	WAJIB
Stakeholders	Siapa yang punya veto	Nice-to-have
Constraints	Budget, timeline, tech	Nice-to-have
Assumptions	Hal yang lo assume bisa salah	WAJIB (biasanya dilupain)

Template PRD ringkas (1 halaman cukup untuk MVP):

# PRD: [Nama Produk]

## 1. Tujuan
[1 paragraf: masalah + solusi]

## 2. User
| Persona | Butuh |
|---------|-------|
| Dev Indonesia | Tools murah tanpa GPU |

## 3. Fitur (Prioritas)
### Must-have
- [ ] OAuth Google/GitHub
- [ ] Dashboard utama
- [ ] Subscription tier

### Should-have
- [ ] Webhook integration
- [ ] Team management

### Nice-to-have
- [ ] Custom domain
- [ ] White-label

## 4. User Flow
[Onboard → Trial → Convert → Retain]

## 5. Metrics
| KPI | Target |
|-----|--------|
| Trial → Paid | 8% |
| Monthly churn | <5% |
| NPS | >40 |

## 6. Asumsi (yang bisa salah)
- User mau bayar $20/bln (bukan $5)
- AWS region Singapore cukup cepet
- Indonesian market ready untuk vertical ini

Asumsi adalah section yang paling sering dilupain. Padahal itu yang paling sering salah. Kalau asumsi lo "user mau bayar $20" dan ternyata mereka mau bayar $5, semua pricing strategy di bawahnya perlu re-think. Tulis asumsi di PRD = kasih alarm ke diri sendiri 6 bulan lagi.

Step 2: SRS — Software Requirements Specification

Isi: Behavior dan aturan — gimana sistem harus respond ke setiap input.

Komponen (IEEE 830-1998 + stokquproject):

Section	Isi
External Interfaces	UI, API, hardware, integration
Functional Requirements	Tiap input → proses → output
Performance Requirements	Response time, throughput, capacity
Validation	Siapa validate, gimana caranya, sign-off
Application Rules	Business logic, state machine, edge cases
Data Constraints	Tipe data, range, validation rules
Acceptance Criteria	Kapan feature считается done

Bedanya PRD vs SRS:

Aspek	PRD	SRS
Audience	Product, business, design	Engineering, QA
Bahasa	"User bisa login dengan Google"	"Sistem terima OAuth callback, validate state token, query user by email, return 200 dengan session cookie"
Presisi	Goal-oriented	Behavior-oriented
Update frequency	Mingguan/bulanan	Per sprint/feature

PRD = kontrak dengan user. SRS = kontrak dengan engineer (atau diri lo sendiri di sprint berikutnya).

Template SRS mini:

# SRS: [Sistem]

## 1. Functional Requirements
### FR-1.1: User Login via Google
- **Input:** GET /auth/google/callback?code=XXX&state=YYY
- **Process:** 
  1. Validate state token
  2. Tuker code dengan access token
  3. Fetch user info dari Google API
  4. Query users.email, kalau ada → login, kalau gak ada → create
  5. Generate session, return 302 ke /dashboard
- **Output:** HTTP 302 dengan session cookie
- **Error cases:**
  - State invalid → 401, log "oauth_state_mismatch"
  - Email null → 400, prompt user input email manual

## 2. Performance
| Metric | Target |
|--------|--------|
| Login callback response | < 800ms (p95) |
| Concurrent OAuth flows | 100 |

## 3. Business Rules
- OAuth user email_verified_at = now() (provider udah verify)
- User dengan email sama dari 2 provider = 1 row (lookup by email)
- Avatar URL expire 24 jam → harus self-host di first login

## 4. State Machine
| State | Event | Next State | Action |
|-------|-------|-----------|--------|
| anonymous | oauth_success | authenticated | Set session, redirect dashboard |
| authenticated | session_expired | anonymous | Clear session, redirect login |

Step 3: SDD — System Design Document

Isi: Gimana bangunnya — arsitektur, database, API, backend structure.

Komponen (stokquproject + Atlassian):

Section	Isi
System Architecture	Monolith/microservices, component diagram
Database	Schema, ERD, index strategy, storage choice
API Design	Endpoint, auth, rate limit, error format
Backend Structure	Services, modules, algorithm kunci
Caching Strategy	Apa di-cache, di mana, TTL, invalidation
Third-Party Deps	Service apa, SLA, fallback

Template SDD ringkas:

# SDD: [Sistem]

## 1. Arsitektur
**Style:** Monolith Laravel 11 + Vue 3 SPA + PostgreSQL + Redis
**Component:**
- [Web Server] → [App Server] → [Postgres Primary + 2 Read Replica]
- Redis untuk session + cache + queue
- S3 untuk avatar/file upload

## 2. Database Schema (intinya aja)
### users
- id (uuid), email (unique), google_id (unique nullable), 
  github_id (unique nullable), avatar_url, created_at

### subscriptions
- id, user_id (FK), tier (enum), stripe_id, status, expires_at

### Indexes
- users.email (unique)
- subscriptions.user_id + status (composite)

## 3. API Endpoints
| Method | Path | Auth | Description |
|--------|------|------|-------------|
| POST | /auth/google/callback | public | OAuth callback |
| GET | /api/me | bearer | Current user info |
| POST | /api/subscriptions | bearer | Create subscription |

## 4. Caching
| Data | Key Pattern | TTL | Invalidation |
|------|-------------|-----|--------------|
| User profile | user:{id}:profile | 1h | On profile update |
| Subscription status | sub:{user_id} | 15m | On payment webhook |

## 5. Third-Party
| Service | Purpose | Fallback |
|---------|---------|----------|
| Stripe | Payment | Midtrans (Indonesia) |
| Google OAuth | Login | GitHub OAuth |
| Sentry | Error tracking | Self-hosted GlitchTip |

Step 4: UI/UX Flow

Minimum deliverable: wireframe low-fidelity (hand-drawn atau Excalidraw) yang nunjukin:

Layout tiap screen (di mana element berada)
Navigation flow (arrow antar screen)
Input/output tiap screen
Edge case states: loading, empty, error

Gak perlu pixel-perfect mockup di phase ini. Yang penting: lo udah kebayang user klik mana, liat apa, input apa. Kalau belum, lo belum siap coding UI-nya.

Tools: Figma (kalau udah langganan), Excalidraw (free, fast, ugly-enough-that-lo-focus-on-flow), atau kertas + pulpen.

Step 5: Task Breakdown

Tujuan: pecah kerjaan jadi unit yang bisa di-estimasi dan di-execute. Cegah "bikin login page" yang ternyata 5 hari karena 20 micro-decision.

Template:

# Task Breakdown: Sprint 1 (Auth + User)

## Epic 1: User bisa login via Google
| # | Task | Estimate | Deps | Status |
|---|------|----------|------|--------|
| 1.1 | Setup Socialite package | 1h | - | done |
| 1.2 | Config services.php + .env | 1h | 1.1 | done |
| 1.3 | Migration: add google_id column | 30m | 1.1 | todo |
| 1.4 | Route auth/google + callback | 1h | 1.2 | todo |
| 1.5 | AuthController: redirect + callback method | 3h | 1.2, 1.3, 1.4 | todo |
| 1.6 | Test OAuth flow manual + automated | 2h | 1.5 | todo |

**Total estimate:** 8.5 jam (1 sprint 1 hari untuk solo dev)

Estimasi worst-case 2x dari best-case. Kalau lo pikir 1 jam, tulis 2 jam. Realita: 90% task makan 2x dari estimasi pertama kita. Itu normal, bukan tanda lo buruk.

Framework #2: Process-Oriented Docs (Lean)

Buat solo/lean project. 6 dokumen, tapi masing-masing bisa 1-2 halaman.

Step 1: PRD (sama kayak Framework #1)

Gak perlu beda. PRD adalah "north star" untuk semua framework.

Step 2: Tech Spec (gabungan SDD + tech decisions)

Isi: Stack pilihan, arsitektur, API contracts, data models, infrastructure.

Bedanya sama SDD formal: lebih ringkas, gak perlu sign-off section, gak perlu compliance section.

# Tech Spec: [Project]

## Stack
- Backend: Laravel 11 (PHP 8.2)
- Frontend: Vue 3 + Inertia.js
- DB: PostgreSQL 16
- Cache: Redis 7
- Queue: Redis-backed (delayed jobs)
- Hosting: VPS $20/bulan (Hetzner)

## Arsitektur
Monolith, deploy ke 1 VPS. Scaling vertical dulu (upgrade VPS), 
horizontal baru kalau revenue > $1k/bulan.

## Data Model (3 tabel utama)
- users: id, email, oauth_provider, oauth_id, created_at
- projects: id, user_id, name, settings (JSONB), created_at
- tasks: id, project_id, title, status, assignee_id, due_date

## API (RESTful, JSON)
- GET /api/projects
- POST /api/projects
- PATCH /api/tasks/{id}
- DELETE /api/tasks/{id}

## Deployment
Git push ke main → GitHub Actions → SSH ke VPS → 
docker compose up -d --build → smoke test → done.

Step 3: User Flow & Wireframe

Bedanya sama UI/UX formal: lebih ringkas, fokus ke happy path + 1-2 alternative path. Gak perlu full design system, component library, atau accessibility matrix di phase ini.

Yang perlu lo punya:

3-5 wireframe screen utama
Arrow flow antar screen
Notes untuk edge case: "kalau user belum login, redirect ke /login?return=..."

Step 4: Project Timeline & Milestones

Untuk solo/lean, ini bukan Gantt chart project management enterprise. Ini cuma: kapan fitur X harus jadi, dan kalau gak jadi, apa konsekuensinya?

# Timeline: [Project] - 6 minggu

| Week | Milestone | Owner | Buffer |
|------|-----------|-------|--------|
| 1 | Auth + user management | gue | 1 hari |
| 2 | Project CRUD + dashboard | gue | 1 hari |
| 3 | Task management + collaboration | gue | 2 hari |
| 4 | Subscription + payment | gue | 2 hari |
| 5 | Polish + bug fix + landing page | gue | 3 hari |
| 6 | Beta launch (10 user) | gue | 1 minggu |

**Buffer 20% realistic.** Week 6 sengaja longgar karena launch biasanya reveal 5-10 bug yang harus di-fix sebelum public.

Step 5: Testing & QA Checklist

Untuk solo dev, testing sering jadi yang pertama di-skip. Jangan. Checklist ini 30 menit tulis, hemat 5 jam bug fix nanti.

# QA Checklist

## Functional
- [ ] User bisa login via Google (test 3 email beda)
- [ ] User bisa bikin project (test dengan nama 1 char, 100 char, unicode)
- [ ] User bisa invite teammate (test 1 invite, multi invite, expired invite)
- [ ] Subscription webhook dari Stripe update status (test success + failed)

## Edge Cases
- [ ] User buka link invite setelah expired
- [ ] User ganti email di Google, login lagi — row lama di-update, gak duplicate
- [ ] User pakai VPN, OAuth callback masih jalan
- [ ] Concurrent edit: 2 user edit task yang sama

## Performance
- [ ] Dashboard load < 1.5s untuk user dengan 100 project
- [ ] Search debounce 300ms, gak fire tiap keystroke

## Device/Browser
- [ ] Chrome desktop, Safari desktop, Firefox desktop
- [ ] iOS Safari, Android Chrome (mobile)
- [ ] Slow 3G throttling test (semua fitur masih functional)

Step 6: Deployment & Maintenance Plan

# Deployment

## CI/CD
- Push to main → GitHub Actions run test + build
- Kalau pass → SSH to VPS, git pull, restart service
- Manual approval untuk deploy ke production (gak auto)

## Rollback
- Keep last 3 releases di server
- Rollback = `ln -sfn releases/v0.1.5 current && restart service`
- Test rollback sebulan sekali (kalau gak pernah test, gak jalan pas butuh)

## Monitoring
- Uptime monitoring: UptimeRobot (free, 5 menit interval)
- Error tracking: Sentry (free tier cukup untuk MVP)
- Server metrics: htop + cron email report

## Runbook
- DB down: cek systemd, restart, cek disk
- High CPU: cek htop, kill proses zombie, scale up
- Disk full: log rotation, clear old backups

Kapan Pakai Formal vs Process

Situasi Lo	Framework
Solo dev, MVP, target launch <3 bulan	Process (lean)
Freelance, client butuh invoice & scope jelas	Formal
Side project, eksplorasi	Process (cuma PRD + Tech Spec)
Startup, butuh investor pitch deck	Formal PRD + Process sisanya
Project pemerintah / audit-required	Full Formal
Tim > 5 orang	Formal (komunikasi overhead)
Bikin untuk klien luar negeri via Upwork	Formal (protect dari dispute)

Default untuk indie hacker / solo dev Indonesia: Process framework. Formal terlalu berat, tapi PRD tetap wajib (1 halaman cukup).

5 Case Study Indonesia: Dokumentasi yang Berhasil & Gagal

Case Study 1: Freelance Laravel — Dokumentasi Formal Hemat Dispute (Sukses)

Konteks: Developer freelance Solo, handle project e-commerce korporat Rp 80 juta, 4 bulan.

Sebelum dokumentasi: Klien minta "tambah fitur wishlist" di week 8. Developer ngerjain. Di week 10, klien minta "tambah filter advanced" tanpa sadar scope udah berubah 30%. Developer juga ngerjain karena gak ada acuan. Di week 12, klien protes invoice melebihi budget, ancam gak bayar.

Solusi: Developer berinisiatif bikin PRD + SRS formal di project Freelance ke-2. Total waktu: 6 jam. Isi: scope asli, 12 functional requirement, 8 acceptance criteria, change request template.

Hasil:

5 change request dari klien, semua tercatat formal
Klien bayar 15% di atas budget untuk extra feature (sesuai change request)
Dispute = 0
Developer hemat 20+ jam argumen via WhatsApp
Repeat order: 3x dari klien yang sama

Lesson: Untuk freelance > Rp 30 juta atau > 2 bulan, formal doc bukan overhead — ini invoice protection.

Case Study 2: SaaS B2B Tim 3 Orang — Process Framework Anti-Burnout (Sukses)

Konteks: Co-founder startup Jogja, bikin SaaS HRIS untuk UMKM, 3 co-founder (1 backend, 1 frontend, 1 marketing).

Sebelum dokumentasi: 6 bulan pertama tanpa docs. Di bulan ke-7, backend dev resign karena stuck. Co-founder lain gak bisa lanjut — semua arsitektur ada di kepala backend dev. Project mati 4 bulan sampai hire ulang.

Solusi: Project ke-2 (sebenarnya rebuild), pakai Process Framework (PRD + Tech Spec + User Flow + Timeline). Tambah: ADRs (Architecture Decision Records) untuk setiap keputusan besar.

Hasil:

1 co-founder cuti 2 minggu (sakit), 2 sisanya lanjut tanpa bottleneck
Time-to-onboard developer baru: 3 hari (vs 3 minggu project sebelumnya)
3 ADRs (database choice, auth approach, deployment strategy) = 30 menit baca untuk paham "kenapa begini, bukan begitu"
ARR 18 bulan kemudian: Rp 240 juta/tahun

Lesson: Untuk tim kecil 3-5 orang, MVD + ADRs udah cukup. Gak perlu formal IEEE-spec.

Case Study 3: Side Project Indie Hacker — PRD 1 Halaman (Sukses)

Konteks: Developer Bandung, side project "Tools untuk hitung PPh 21 freelance" (sendirian, weekend project).

Pendekatan: Tulis PRD 1 halaman (problem, user, 5 fitur must-have, success metric "1K download 3 bulan"). Gak bikin SRS/SDD/UI/UX formal — kode langsung.

Hasil:

1 bulan launch ke ProductHunt, 800 download
3 bulan kemudian: 1.5K download, $200 MRR dari subscription premium
Maintenance 4 jam/minggu
Gak ada bug besar karena 5 fitur must-have = scope terkontrol
Di bulan ke-6, akhirnya nulis Tech Spec karena perlu tambah payment integration

Lesson: Untuk eksperimen weekend, PRD 1 halaman udah leverage yang cukup. Nulis doc lebih banyak dari kode = wrong ratio.

Case Study 4: Startup Fintech YC-Style — Gagal Karena Gak Ada SRS (Gagal)

Konteks: Co-founder fintech Jakarta, 4 orang tim, dapat funding seed $500K, buru-buru bangun mobile banking.

Sebelum dokumentasi: "Move fast and break things" mentality. Skip SRS, langsung design mockup, langsung Android dev ngoding. Backend dev ngerjain paralel tanpa spec jelas.

Masalah:

Week 8: "KYC flow" — frontend udah selesai, backend belum tahu mau return apa. 2 minggu negosiasi
Week 12: "Transaction limit" — business requirement berubah, harus refactor 30% flow
Week 16: QA baru join, gak ada acceptance criteria. 1 minggu cuma verify "fitur ini bener gak?"
Week 20: OJK audit, butuh formal docs. Dari nol bikin semua = 6 minggu
Launch delay: 3 bulan dari target. Burn rate naik 40%.

Hasil: Project launch, tapi 3 bulan telat, burn rate 2x lipat, co-founder CTO resign karena burnout.

Lesson: "Move fast" bukan berarti "skip docs". MVD 3-4 jam di awal = hemat 3 bulan di belakang. Regulated industry (fintech) = formal SRS wajib.

Case Study 5: Open Source Library — Auto-Gen Docs dari Code (Sukses)

Konteks: Maintainer open source library Python "pyindonesia" (NLP Bahasa Indonesia), 2 maintainer, 30+ contributor.

Pendekatan: Gak nulis docs manual. Pakai Sphinx + autodoc yang generate docs dari docstring kode. Plus MkDocs untuk user guide.

Hasil:

90% docs ter-generate otomatis dari docstring
10% manual (tutorial, FAQ, contributing guide)
Maintainer hemat 5+ jam/minggu yang biasanya buat docs
PR baru wajib include docstring → contributor lain belajar convention
1.2K stars di GitHub, 8K download/bulan di PyPI

Lesson: Untuk library/tool, docs-as-code (auto-gen dari source) = leverage terbaik. Manual docstring < automated doc. Tapi untuk product/business logic, manual doc tetap wajib.

10 Best Practices Dokumentasi

1. MULAI DARI PRD, JANGAN LANGSUNG NGODING

Poin ini udah dibahas 5x di artikel. Tapi worth-it untuk diulang: PRD dulu, baru kode. 30 menit PRD = hemat 3 jam debug.

2. Tulis Asumsi sebagai Alarm 6 Bulan ke Depan

Section "Asumsi" di PRD sering di-skip karena "ah ini mah obvious". Padahal asumsi yang "obvious" itu yang paling sering salah. Tulis explicit, dengan tanggal tulis. Review setiap quarter.

3. Estimasi 2x dari Best-Case Lo

Kalau lo pikir task 1 jam, tulis 2 jam. 90% task makan 2x estimasi pertama. Ini bukan tanda lo buruk — ini tanda lo belum punya experience metric. Setelah 6 bulan, lo bisa calibrate.

4. Update Dokumen di Sprint yang Sama dengan Kode

Dokumen yang outdated = dokumen yang bohong. Setiap PR yang ubah behavior sistem, harus update SRS/SDD di PR yang sama. Code review wajib include doc review.

5. Pakai ADR untuk Keputusan Arsitektur Besar

ADR (Architecture Decision Record) = 1-2 halaman untuk setiap keputusan besar:

"Kenapa PostgreSQL bukan MySQL?"
"Kenapa monolith bukan microservices?"
"Kenapa VPS bukan serverless?"

Format: Context → Decision → Consequences. Save di docs/adr/0001-database-choice.md, 0002-monolith-vs-microservices.md, dll.

6. User Flow Lebih Penting dari Wireframe Detail

Flow nunjukin "user klik apa, liat apa". Wireframe pixel-perfect nunjukin "warna button ijo apa biru". Yang pertama = kritikal. Yang kedua = nice-to-have. Mulai dari flow, baru wireframe.

7. Test Edge Case yang Lo Tulis di SRS

SRS tanpa test = SRS yang gak divalidasi. Setiap acceptance criteria di SRS harus jadi 1 test case (manual atau automated). Gak ada test = belum selesai.

8. Dokumentasi Bukan Tujuan, Tapi Alat

Kalau lo nulis doc tapi gak ada yang baca (termasuk lo sendiri 1 bulan kemudian), itu dokumen mati. Review setiap quarter: doc mana yang masih relevan? Hapus yang mati. Update yang outdated. Keep yang aktif.

9. Single Source of Truth (SSOT)

Code & doc harus sinkron. Kalau kode bilang users.email tapi doc bilang users.email_address = bug di doc. Tools: OpenAPI spec di-generate dari code annotation (Spring, FastAPI), TypeScript types di-share ke FE & BE, DB schema di-migrate via Prisma/Drizzle.

10. Dokumen = Living Document, Bukan Artifact

Dokumen harus di-update berkala, bukan "tulis sekali terus ditinggal". Mindset: doc adalah bagian dari product. Kalau lo ngeluarin v2 tanpa update doc, lo misleading user.

10 Pitfall Dokumentasi (dan Cara Menghindarinya)

1. Premature Documentation (Doc Sebelum Paham)

Jangan nulis PRD detail 30 halaman kalau lo belum validate problem-nya. Validasi dulu dengan 5 user interview, baru PRD detail. Order: Problem → User → PRD → Code.

2. Write-Only Documentation

Doc yang ditulis tapi gak pernah dibaca/diupdate = doc yang mati. Tanda: doc terakhir di-update 1 tahun lalu, tapi kode udah berubah 50x. Solusi: doc review tiap sprint, atau auto-generate.

3. Documentation Paralysis

Terlalu fokus bikin doc sempurna sampai gak mulai coding. Untuk MVP, PRD 1 halaman + Tech Spec 1 halaman udah cukup. Perfect doc = enemy of good doc.

4. Over-Engineering (Tools & Format)

Pakai Notion + Confluence + Google Docs + Markdown + Wiki = chaos. Pilih 1 stack, konsisten. Default: Markdown di Git repo + Notion/Confluence untuk collaborative doc.

5. Gak Punya Owner

Doc yang gak ada ownernya = doc yang gak ke-update. Setiap doc harus ada "owner" (PIC) yang bertanggung jawab review/update.

6. Doc Bahasa Asing untuk Tim Lokal

Buat tim Indonesia, doc bahasa Inggris = barrier. Doc bahasa Indonesia casual = lebih cepet ditulis, lebih cepet dipahami, lebih cepet di-update. Untuk open source/investor = English. Untuk internal team = Indonesia.

7. Asumsi yang Gak Explicit

Bagian "Asumsi" di PRD sering kosong. Padahal keputusan terbesar biasanya berdasarkan asumsi yang gak ditulis. Tulis asumsi dengan eksplisit, review tiap quarter.

8. Code Comment = Documentation (Salah)

Code comment nunjukin "gimana". Documentation nunjukin "kenapa" & "apa". Keduanya beda. Jangan cuma comment di code, tapi doc yang berdiri sendiri.

9. Gak Ada Versioning

Doc tanpa version = doc tanpa history. Pakai Git (Markdown) atau Notion (page history). Review perubahan doc kayak review code.

10. Compliance / Audit Doc Dilupain

Untuk industri regulated (fintech, health, gov), doc adalah audit trail. Kalau lo gak nulis kenapa keputusan X diambil, pas audit lo gak bisa jawab. ADR = murah, tapi powerful untuk audit.

7 Tren Dokumentasi 2026-2027

1. Living Documentation (Auto-Sync dengan Code)

Doc yang auto-update ketika kode berubah. Tools: Fern (API doc generator), Mintlify (component doc), TypeDoc (TS), Sphinx autodoc (Python). Trend: doc jadi side-effect dari kode, bukan side-project terpisah.

2. AI-Assisted Documentation (LLM Tulis Draft)

LLM (Claude, GPT-4) bisa generate draft PRD/SRS dari meeting notes, transcript, atau user research. Lo tinggal review & edit. Trend 2026-2027: 50% doc pertama di-draft AI, lo refine. ROI: hemat 2-3 jam per doc.

3. Diátaxis Framework (4 Tipe Doc)

Diátaxis = framework yang organize doc jadi 4 kategori:

Tutorial (belajar, learning-oriented)
How-to Guide (solve problem, task-oriented)
Reference (informasi teknis, information-oriented)
Explanation (konteks & design decision, understanding-oriented)

Adopsi: Django, MDN, Kubernetes docs pakai Diátaxis. Untuk 2026-2027, ini best practice untuk technical documentation.

4. Docs as Code (Markdown + Git + CI)

Doc ditulis di Git, version control sama kayak kode, di-deploy via CI/CD ke static site (MkDocs, Docusaurus, Nextra). Benefit: PR review untuk doc, history jelas, gak ada "doc ilang". Trend: 70% startup tech pakai docs-as-code di 2026.

5. Auto-Generated dari Code Annotation

OpenAPI spec di-generate dari FastAPI/Flask decorator. TypeScript types di-share ke FE & BE. Prisma schema di-generate ke SQL & TypeScript. Doc jadi byproduct, bukan artifact. ROI: 0 maintenance burden.

6. Architecture Decision Records (ADRs) Wajib

Setiap keputusan arsitektur besar → 1 file ADR. Tools: log4brains, adr-tools, MADR. Trend 2026-2027: tim yang sustainable pake ADRs, tim yang chaotic gak.

7. Async-First Documentation

Doc menggantikan meeting. Daripada meeting 1 jam bahas decision, tulis 1 halaman doc + comment di Git. Orang baca + comment kapanpun. Meeting jadi exception, bukan default. Trend: post-COVID, async-first jadi new normal.

90-Day Documentation Sprint (untuk Existing Project)

Kalau lo udah punya project tapi dokumentasinya berantakan, ini 90-day sprint untuk rapihin:

Horizon 1: Audit & Discovery (Week 1-2)

Activity	Output	Time
List semua doc existing	Inventory.md (path, last updated, owner)	2h
Interview 3-5 user internal	Pain points doc	3h
Cek code vs doc mismatch	Gap analysis report	4h
Prioritas doc untuk ditulis/diupdate	Top 10 doc list	2h

Total: ~11 jam (1.5 hari)

Horizon 2: Fill the Gap (Week 3-6)

Activity	Output	Time
Tulis/update PRD	PRD v1	3-4h
Tulis Tech Spec	Tech Spec v1	3-4h
Tulis User Flow untuk 5 screen utama	User Flow v1	3h
Tulis Testing & QA Checklist	QA v1	2h
Tulis Deployment Plan	Deploy Plan v1	2h

Total: ~14 jam (2 hari) — Spread 1-2 jam per hari, atau 1 weekend marathon.

Horizon 3: Standardize (Week 7-10)

Activity	Output	Time
Pilih doc tool (Notion / Git)	Decision doc	1h
Setup template (PRD, SRS, ADR)	4 template	2h
Migrasi doc existing ke tool baru	All doc in new tool	4h
Setup CI/CD untuk docs-as-code	Auto-deploy pipeline	3h
Buat contributing guide	CONTRIBUTING.md	1h

Total: ~11 jam

Horizon 4: Review & Optimize (Week 11-12)

Activity	Output	Time
Doc review dengan tim/user	Feedback doc	3h
Update doc berdasarkan feedback	Doc v2	4h
Setup doc ownership matrix	Owner per doc	1h
Quarterly review process	Cadence doc	1h

Total: ~9 jam

Total 90-day sprint: ~45 jam (~6 hari kerja). Worth it? Kalau project lo di-maintain > 1 tahun, ROI = 10x-50x.

Tool Stack Recommendation (2026)

Tier 1: Solo Dev / Small Team (Free / Cheap)

Kebutuhan	Tool	Cost
PRD / SRS / SDD	Notion (free) atau Markdown di Git	Free
Wireframe / User Flow	Excalidraw	Free
API Docs	Stoplight Elements (open source)	Free
Project Timeline	Notion / Linear / Trello	Free
Diagram Arsitektur	draw.io / Mermaid (di Markdown)	Free
Docs as Code	MkDocs + GitHub Pages	Free

Tier 2: Growing Team ($/bulan per user)

Kebutuhan	Tool	Cost
PRD / SRS / SDD	Confluence	$5-7/user/bulan
Wireframe / User Flow	Figma	$12/user/bulan
API Docs	Mintlify / ReadMe	$50-200/bulan
Project Timeline	Jira	$7-14/user/bulan
Diagram Arsitektur	Lucidchart	$8/user/bulan
Docs as Code	Docusaurus + Vercel	$20/bulan

Tier 3: Enterprise ($/bulan per user, compliance-grade)

Kebutuhan	Tool	Cost
PRD / SRS / SDD	Confluence + Comala	$15+/user/bulan
Wireframe / User Flow	Figma Enterprise	$45/user/bulan
API Docs	ReadMe Business	$399+/bulan
Project Timeline	Jira + Advanced Roadmaps	$14+/user/bulan
Diagram Arsitektur	Lucidchart Enterprise	$20+/user/bulan
Compliance & Audit	Vanta + Drata	$500+/bulan

Rekomendasi untuk solo dev Indonesia: Tier 1. Notion + Excalidraw + MkDocs = 100% cukup untuk 95% project.

Anti-Rekomendasi: 5+5 Situasi yang GAK Perlu Dokumentasi

5 Situasi JANGAN Bikin Dokumentasi Formal

Eksperimen 1 hari / weekend hackathon — PRD 1 paragraf cukup, gak perlu SRS/SDD
Belajar teknologi baru (tutorial, course) — Catatan pribadi cukup, bukan PRD
Internal script / CLI tool — README 1 halaman cukup, gak perlu SRS
Project yang bakal di-discard dalam 1 bulan — Wasted effort kalau full formal doc
Pure refactor (no behavior change) — Code review + commit message cukup, gak perlu spec

5 Situasi JANGAN Skip Dokumentasi (Bahkan untuk Solo Dev)

Project dengan client bayar > Rp 30 juta — Formal doc = invoice protection
Project regulated (fintech, health, gov) — Compliance = audit trail
Project dengan investor — Due diligence butuh formal doc
Project yang bakal di-handover ke orang lain — Onboarding cost tanpa doc = 3-4x
Project yang bakal di-monetize (SaaS, B2B) — User-facing API/feature perlu SRS/SDD

Industry-Specific Documentation Pattern

E-commerce / Marketplace

Wajib: PRD (flow checkout, refund, dispute), SRS (payment integration, inventory sync), QA Checklist
Tools: Stripe/Midtrans docs, Notion/Confluence
Pattern: Heavy on edge cases (stok habis saat checkout, payment timeout, double refund)

SaaS B2B

Wajib: PRD (user journey, pricing tier), SRS (auth, RBAC, audit log), Tech Spec (multi-tenant), API Docs (untuk integration customer)
Tools: Notion + OpenAPI + ReadMe
Pattern: Heavy on RBAC, audit log, SLA, integration guide

Fintech / Payment

Wajib: SEMUA (PRD, SRS, SDD, QA, Deploy + Compliance Doc)
Tools: Confluence + Jira + Vanta
Pattern: Compliance-grade (OJK, BI), audit trail, runbook emergency, rollback procedure

Healthtech

Wajib: SEMUA + HIPAA/local-regulator doc
Tools: Confluence + specialized compliance tool
Pattern: Data privacy critical, encryption doc mandatory, patient consent flow

Edtech

Wajib: PRD (user journey student/parent/teacher), SRS (course delivery, payment)
Tools: Notion + Excalidraw
Pattern: Multi-role, gamification, payment per-course

Media / Content

Wajib: PRD (content model, editorial flow), Tech Spec (CMS choice)
Tools: Notion + Sanity/Strapi doc
Pattern: Content modeling penting, editorial workflow, SEO consideration

Logistics / Supply Chain

Wajib: PRD (shipment lifecycle), SRS (tracking, notification), Tech Spec (integration dengan 3PL)
Tools: Notion + draw.io + Jira
Pattern: Integration banyak (3PL, kurir, payment), real-time tracking, edge case banyak

Agency / Consultancy

Wajib: PRD per project + SOW (Statement of Work) + Change Request template
Tools: Notion + DocuSign / HelloSign
Pattern: Project-based, time-bound, scope change frequent, dispute prevention

Open Source Library / Tool

Wajib: README, CONTRIBUTING, API Reference, Tutorial
Tools: Markdown + MkDocs/Docusaurus + GitHub
Pattern: Auto-generated dari code, contribution-friendly, example-driven

Internal Tool / CLI

Wajib: README + --help output + 1 contoh penggunaan
Tools: Markdown
Pattern: Minimum viable, code comment + README cukup

Kapan Pakai Formal vs Process (Recap Decision Matrix)

Dimensi	Formal	Process
Project size	> 5 orang atau > 6 bulan	Solo atau tim kecil < 6 bulan
Compliance	Fintech, health, gov, regulated	Lainnya
Audience	Client korporat, investor, auditor	Diri sendiri, tim kecil
Budget	> Rp 100 juta	< Rp 100 juta
Timeline	> 6 bulan	< 6 bulan
Maintenance	> 1 tahun	< 1 tahun
Update frequency	Per sprint (formal review)	Per minggu (informal review)
Tool cost	Confluence + Jira + Vanta	Notion + Git + Excalidraw (free)
Effort	20-40 jam initial	3-6 jam initial
Risk if skip	Compliance issue, audit fail, dispute	Scope creep, bug, slow onboarding

Default: Process framework. Upgrade ke Formal kalau ≥3 dimensi cocok dengan kolom "Formal".

TL;DR — Minimum Viable Documentation

Kalau lo males baca semua di atas, ini minimum yang HARUS lo punya sebelum mulai coding:

PRD 1 halaman — problem, user, fitur must-have, success metric
Tech Spec 1 halaman — stack, arsitektur, data model
User Flow sketch — bisa hand-drawn, 3-5 screen
Timeline 4-6 minggu — milestones, buffer 20%

Total waktu: 3-4 jam. Output: lo ngerti apa yang lo bangun dan kenapa. Worth it.

Yang sering terjadi: developer skip langkah ini karena "ah ini project kecil, gak usa formal". Trus di week 3, scope udah 2x lipat, gak ada yang ngerti-apa priority, dan semangat lo udah turun.

Investasi 3-4 jam di awal = lo hemat 30+ jam di belakang.

"MULAI DARI PRD, JANGAN LANGSUNG NGODING." 🛑

21. IEEE 830-1998 Deep-Dive: Standar Wajib SRS

Recommended Practice for Software Requirements Specifications (IEEE 830-1998, superseded by IEEE 29148-2018 tapi masih banyak dipakai) — definisi resmi struktur SRS. Lima karakteristik wajib: Correct, Unambiguous, Complete, Consistent, Ranked (prioritas). Delapan section template:

Introduction (purpose, scope, definitions, references, overview)
Overall Description (product perspective, functions, user characteristics, constraints, assumptions)
Specific Requirements (functional, performance, design constraints, attributes, external interface)
Appendices (data dictionary, analysis models, issues list)
Index

Kapan wajib pakai IEEE 830? (a) Project >6 bulan, (b) Tim >3 orang, (c) Regulasi/audit (FDA, aerospace, medical devices), (d) Klien korporat minta compliance. Solo dev project 2 minggu? Skip.

Studi kasus: NASA pakai IEEE 830 buat flight software — bug di spec = pesawat ulang-alik delay atau nyawa hilang. Buat SaaS UMKM? Overkill. Tapi PRD lo harus cover 5 karakteristik: Correct (no false claims), Unambiguous (1 interpretasi per kalimat), Complete (semua user story), Consistent (no contradiction), Ranked (MoSCoW).

Anti-pattern: Copy-paste SRS template kosong tanpa isi → worthless. Template tanpa content = false comfort.

Sumber: IEEE 830-1998 — https://standards.ieee.org/standard/830-1998.html

22. IEEE 29148-2018: Pengganti Modern

Systems and Software Engineering — Life Cycle Processes — Requirements Engineering (IEEE 29148-2018) — suksesor IEEE 830, scope lebih luas: requirements engineering di seluruh lifecycle, bukan cuma spec document.

Perbedaan kunci dari IEEE 830:

Stakeholder needs emphasis — bukan cuma system requirements tapi juga business, user, regulatory needs
Traceability matrix wajib — setiap requirement trace ke source (user story, regulation, business goal)
Requirements attributes — priority, owner, verification method, risk level per item
Lifecycle integration — requirements evolve dengan agile iterations, bukan single waterfall doc

Struktur IEEE 29148-2018:

Stakeholder requirements (high-level, often non-technical)
System requirements (functional + non-functional)
Software requirements (detailed, implementation-ready)
Interface requirements (hardware, software, user, communication)
Performance requirements (throughput, latency, capacity)
Design constraints (platform, language, framework)
Software quality attributes (maintainability, portability, security)

Pakai kapan? Project regulated (healthtech HIPAA, fintech PCI-DSS, gov procurement) WAJIB pakai IEEE 29148-2018. Project biasa? Ambil 3 elemen paling useful: stakeholder needs, traceability matrix, requirements attributes. Skip formal compliance kalau gak butuh audit.

Tools: Jama Connect, Polarion, IBM DOORS buat enterprise. Buat solo: spreadsheet Google Sheets aja udah cukup untuk traceability matrix.

Sumber: IEEE 29148-2018 — https://standards.ieee.org/standard/29148-2018.html

23. ISO/IEC/IEEE 12207:2017 — Software Lifecycle Standard

Systems and Software Engineering — Software Life Cycle Processes (ISO/IEC/IEEE 12207:2017) — standar tertinggi untuk software process. Bukan tentang documents, tapi tentang activities dan outcomes yang harus ada di setiap phase.

Empat group process:

Agreement processes (acquisition, supply) — kontrak dengan klien/vendor
Organizational Project-Enabling processes (management, infrastructure, training, reuse) — gimana org support project
Technical Management processes (planning, assessment, control, decision, risk) — daily management
Technical processes (requirements, design, construction, testing, installation, operation, maintenance, disposal) — hands-on engineering

Solo dev relevant subset: Technical Management + Technical processes. Skip agreement (lo bukan procurement) dan organizational (lo bukan enterprise).

Kapan penting? (a) ISO 9001 certified company, (b) Government contract (LPSE), (c) Medical device / aerospace. Buat startup biasa? Liat dia sebagai checklist mental, bukan compliance mandate.

Simplified version untuk solo dev:

Planning: 1 dokumen (timeline + milestones)
Assessment: weekly self-review (Apa blockers? Apa learned?)
Control: change log (PR + commit message)
Risk: top 3 risks di awal project
Requirements: PRD
Design: SDD atau sketch
Construction: code + commit history
Testing: automated test suite
Maintenance: changelog + user feedback loop

Insight: ISO 12207 bukan "lebih document dari agile" — dia bilang activities tertentu harus ada, output format bebas. Agile with no docs = no audit trail, ISO 12207 violation.

Sumber: ISO/IEC/IEEE 12207:2017 — https://www.iso.org/standard/63712.html

24. ISO/IEC/IEEE 42010:2011 — Architecture Documentation

Systems and Software Engineering — Architecture Description (ISO/IEC/IEEE 42010:2011) — standar untuk mendokumentasikan arsitektur sistem. Concern utama: stakeholders (siapa yang baca?) + viewpoints (dari sudut mana?) + views (output per viewpoint) + correspondence (konsistensi antar view).

Empat konsep kunci:

Stakeholder — individual, team, organization dengan concern terhadap system (developer, ops, security, product owner, end-user, regulator)
Concern — interest tentang system (performance, security, cost, maintainability, scalability)
Viewpoint — template/specification untuk constructing view (C4 model, 4+1 view, arc42)
View — artifact yang menyampaikan concern untuk stakeholder

Contoh practical — arc42 template (popular di Eropa):

Section 1: Introduction & Goals (top 3 business goals, top 3 quality goals)
Section 2: Architecture Constraints (technical, organizational, conventions)
Section 3: System Scope & Context (business context, technical context)
Section 4: Solution Strategy (pola decompose, pola cross-cutting)
Section 5: Building Block View (static decomposition: container, component, module)
Section 6: Runtime View (dynamic scenarios: startup, request flow, failure)
Section 7: Deployment View (infrastructure: where code runs)
Section 8: Cross-cutting (logging, error handling, persistence, session, security)
Section 9: Architecture Decisions (ADR reference)
Section 10: Quality Requirements (measurable: 99.9% uptime, p95 < 200ms)
Section 11: Risks & Technical Debt
Section 12: Glossary

Kapan pakai 42010? (a) System >5 services/microservices, (b) Tim >2 developer, (c) Klien butuh "architecture document" untuk compliance. Solo 1-service API? Skip arc42, pake C4 model (Context, Container, Component, Code) — 4 level cukup.

Tools: Structurizr (C4 as code), arc42 template (Markdown/AsciiDoc), Sparx EA (enterprise).

Sumber: ISO/IEC/IEEE 42010:2011 — https://www.iso.org/standard/50508.html | arc42 — https://arc42.org/

25. RFC 2119 / RFC 8174: Keyword Wajib untuk Spec

Key Words for Use in RFCs to Indicate Requirement Levels (RFC 2119, updated RFC 8174) — standar vocabulary buat spec documents. Tanpa keyword konsisten, spec jadi ambiguous.

Empat level requirement:

Keyword	Meaning	Indonesian
MUST / REQUIRED / SHALL	Absolute requirement	Wajib
MUST NOT / SHALL NOT	Absolute prohibition	Dilarang
SHOULD / RECOMMENDED	Recommended tapi ada valid reason untuk skip	Sebaiknya
SHOULD NOT / NOT RECOMMENDED	Not recommended tapi boleh	Sebaiknya tidak
MAY / OPTIONAL	Truly optional	Boleh

Aturan penggunaan (RFC 8174):

Huruf besar semua: MUST, SHOULD, MAY
Digunakan di awal kalimat (setelah subjek)
Untuk klarifikasi: tambahkan "The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here."

Contoh salah: "User must register before checkout" (kecil = tidak punya kekuatan legal/spec). Contoh benar: "User MUST register before checkout" (kapital = binding requirement).

Pakai di mana?

API contract (OpenAPI description)
SRS document
ADR (consequences section)
Contributing guidelines
Style guide code

Real example — Twilio API docs: "All requests to the API MUST use HTTPS. Parameters MUST be URL-encoded. The To field MAY be either E.164 format or local format." — Konsisten, tidak ambigu.

Anti-pattern: Campur "harus", "wajib", "perlu", "sebaiknya" dalam 1 doc = bingung implementer. Pilih 1 vocabulary, stick to it.

Sumber: RFC 2119 — https://datatracker.ietf.org/doc/html/rfc2119 | RFC 8174 — https://datatracker.ietf.org/doc/html/rfc8174

26. AI Tools for Documentation 2026

Toolkit AI terbaru yang spesifik untuk documentation engineering, ranked by maturity:

Tier 1 — Production-ready:

GitHub Copilot for Docs (2026) — Inline doc generation dari function signature, $10/bulan. Akurasi 85% untuk function docs, 60% untuk README. Worth it.
Mintlify Writer (2024-2026) — AI writing assistant untuk API docs. Bisa ingest OpenAPI spec + generate markdown + sync changes. Free tier 1 project, Pro $150/bulan.
Cursor + Claude/GPT-4 — IDE-level doc generation. Lebih fleksibel dari Copilot, bisa generate ADRs, design docs, architecture dari existing code. Worth the $20/bulan.
Notion AI — Brainstorming + outline generation untuk PRD. Bagus untuk ideation, bukan untuk final docs.
Anthropic Claude Projects — Custom knowledge base dari existing docs (IEEE standards, your codebase) → generate compliant docs. Free tier cukup untuk solo, Pro $20/bulan untuk volume.

Tier 2 — Emerging / Niche:

ReadTheDocs AI Search (2026 beta) — Semantic search untuk docs site. Reduce "where is this in docs?" friction.
DeepWiki by Devin (2026) — Auto-generate wiki dari GitHub repo. Powerful tapi hallucinate kalau repo private/bad naming.
Swimm (2024-2026) — Code-coupled docs yang update otomatis saat code berubah. Cocok untuk tutorial-style docs yang sering outdated.
Document360 AI (2025-2026) — Enterprise knowledge base + AI assist. Overkill untuk solo.
Mintlify + GPT-4 Fine-tuned — Custom model untuk tech writing style. $$$ tapi enterprise.

Workflow recommendation (solo dev):

1. PRD: Brainstorm dengan Notion AI / Claude Project (1 jam)
2. SRS/SDD: Generate outline dengan Claude + manual refine (2 jam)
3. Code comments: GitHub Copilot (real-time)
4. API docs: Mintlify Writer + OpenAPI spec
5. Architecture diagrams: Mermaid + Excalidraw (manual)
6. User guides: Claude Project trained on product context

Red flag: Jangan pakai AI untuk generate compliance docs (FDA, ISO) tanpa human review. AI halusinasi citation — bisa claim "per ISO 9001 section 7.5.1" tapi faktanya salah. AI = productivity tool, bukan replacement for domain expertise.

Cost-benefit:

Free: Claude free tier + Copilot free tier = cukup untuk solo dev
$20/bulan: Claude Pro + Copilot Pro = sweet spot
$50/bulan: All-in stack = baru worth it kalau lo monetize

Sumber: GitHub Copilot — https://github.com/features/copilot | Mintlify — https://mintlify.com/ | Claude — https://claude.ai/

27. Documentation Glossary: 40+ Istilah Wajib Tau

ADR (Architecture Decision Record) — Doc pendek (1-2 halaman) yang capture 1 keputusan arsitektur + alternatives + consequences
API (Application Programming Interface) — Contract antara 2 software, didefine via OpenAPI/Swagger
arc42 — Template arsitektur komprehensif (12 sections), popular di Eropa
ASR (Architecture Significant Requirement) — Requirement yang constrain arsitektur (performance, security, scalability)

BDD (Behavior-Driven Development) — Format Gherkin (Given-When-Then) untuk user stories
BRD (Business Requirements Document) — High-level business needs, often jadi input PRD

C4 Model — 4-level diagram (Context, Container, Component, Code) untuk architecture
Changelog — Append-only log perubahan (per release atau per commit)
CMMI (Capability Maturity Model Integration) — 5-level model untuk software process maturity (Level 1 ad-hoc → Level 5 optimized)
CRUD — Create, Read, Update, Delete — 4 operasi database basic

Diátaxis — Framework documentation dengan 4 mode: Tutorial, How-to, Reference, Explanation
Doc-as-Code — Documentation ditulis sebagai code (Markdown, version-controlled, CI/CD)
DSL (Domain-Specific Language) — Bahasa untuk domain tertentu (SQL, GraphQL, OpenAPI)

EARS (Easy Approach to Requirements Syntax) — 5 template pattern untuk requirements (Ubiquitous, Event-driven, State-driven, Unwanted behaviors, Optional features)
ERD (Entity-Relationship Diagram) — Visual representation database schema

FRD (Functional Requirements Document) — Detail dari functional requirements (sering = SRS)
FRS (Functional Requirements Specification) — Synonym FRD

Glossary — Definisi terms, anti-ambiguity
Gherkin — Bahasa BDD: Given-When-Then

HFRS (High-Level Functional Requirements) — Functional requirements level tinggi (PRD-adjacent)

IEEE — Institute of Electrical and Electronics Engineers, publisher standar
ISO — International Organization for Standardization
ITIL — IT service management framework

KDoc / JSDoc / docstring — Inline documentation untuk Kotlin/JavaScript/Python

Living Documentation — Doc yang auto-update dari source code
Linting — Automated check untuk style/consistency (markdownlint, vale)

MADR (Markdown ADR) — Template ADR dalam Markdown
Mermaid — Diagram as code (flowchart, sequence, ERD, gantt)
MoSCoW — Prioritization: Must have, Should have, Could have, Won't have

NFR (Non-Functional Requirement) — Requirement non-feature: performance, security, usability, scalability
NFRS (Non-Functional Requirements Specification) — Doc untuk NFR

OpenAPI (Swagger) — Spec untuk REST API, JSON/YAML format
Onboarding Doc — Panduan untuk new developer/user

PlantUML — Diagram as code, lebih mature dari Mermaid untuk UML
PRD (Product Requirements Document) — Doc yang define apa yang akan dibangun dan kenapa
Persona — Archetype user fiktif, dipakai untuk align design decision

RACI — Responsibility matrix: Responsible, Accountable, Consulted, Informed
RFC (Request for Comments) — Doc untuk propose change besar, minta feedback komunitas
ROI (Return on Investment) — Metric untuk justify investment

SDD (System Design Document) — Doc arsitektur + technical design
SLA (Service Level Agreement) — Contract tentang uptime/performance
SLO (Service Level Objective) — Target internal untuk SLA
SRS (Software Requirements Specification) — Doc detail functional + non-functional requirements
SAD (Software Architecture Document) — Synonym SDD

TDD (Test-Driven Development) — Test dulu, code kemudian
TLP (Technical Leading Person) — Orang yang lead technical direction
Traceability Matrix — Tabel yang trace requirements ke design → code → test

UML (Unified Modeling Language) — Standar diagram (class, sequence, activity, state, deployment)
URD (User Requirements Document) — User-level needs, often jadi input PRD

V&V (Verification & Validation) — Verification: apakah build right? Validation: apakah build the right thing?
Versioning — Semantic (semver): MAJOR.MINOR.PATCH

WBS (Work Breakdown Structure) — Decomposition project jadi task kecil-kecil
Wiki — Knowledge base kolaboratif (Notion, Confluence, GitHub Wiki)

YAML / TOML — Format config + spec (OpenAPI, GitHub Actions, ADR frontmatter)

28. ADR (Architecture Decision Records) Deep-Dive

ADR = 1-2 halaman doc yang capture 1 keputusan arsitektur significant. Berbeda dari SDD: ADR fokus ke WHY (kenapa pilih X bukan Y?), SDD fokus ke WHAT (gimana sistem dibangun).

Struktur ADR (MADR template):

# ADR-001: Pilih PostgreSQL sebagai primary database

## Status
Accepted (2026-07-30)

## Context
Butuh RDBMS untuk SaaS analytics. Options: PostgreSQL, MySQL, MongoDB.
- 50K rows/day, mostly structured (transactions + events)
- Tim 2 backend, semua familiar SQL
- Budget $200/bulan untuk managed DB

## Decision
Pakai PostgreSQL (Supabase managed).

## Consequences
Good:
- ACID compliance, mature replication
- JSONB untuk semi-structured fields (no need MongoDB)
- pgvector untuk future ML use case
- Supabase free tier 500MB, upgrade $25/bulan
- Tim familiar → no learning curve

Bad:
- Vendor lock-in ke Supabase (mitigation: export pg_dump weekly)
- Supabase pricing naik drastis di 100GB+ (mitigation: consider self-host setelah 50GB)

Neutral:
- Harus belajar pgvector + RLS policies
- Migration dari Supabase ke Neon/RDS = effort 2-3 hari

## Alternatives Considered
- **MySQL:** Familiar tapi JSON support inferior
- **MongoDB:** Overkill untuk mostly-structured data, transaction support weak
- **Self-host Postgres:** Save cost tapi ops overhead 5-10 jam/bulan

Kapan bikin ADR?

(a) Pilihan teknologi (database, framework, cloud provider)
(b) Pattern arsitektur (monolith vs microservices, sync vs async)
(c) Cross-cutting concern (auth, logging, error handling)
(d) Reversible decision yang cost tinggi untuk reverse

Kapan JANGAN bikin ADR?

Detail implementation (naming convention, function signature)
Business decision tanpa technical impact (pricing tier)
Trivial choice (color scheme UI)

Lifecycle ADR:

Proposed — Draft, minta feedback
Accepted — Final, tim align
Deprecated — Diganti ADR baru
Superseded — Di-replace oleh ADR-[N+1]

Storage:

Repo: docs/adr/0001-pilih-postgres.md
Index: docs/adr/README.md (list + status)
Tools: adr-tools (CLI), log4brains (static site generator)

Anti-pattern:

ADR tanpa alternatives considered = keputusan tanpa justifikasi
ADR tanpa consequences = tidak realistis
ADR yang terlalu panjang (>5 halaman) = over-document, pecah jadi beberapa ADR

Sumber: MADR — https://adr.github.io/madr/ | ADR Tools — https://github.com/npryce/adr-tools | log4brains — https://github.com/thomvaill/log4brains

29. Living Documentation Deep-Dive

Living documentation = doc yang otomatis ter-update saat source code berubah. Kontras dengan traditional doc yang cepat outdated.

Teknik living documentation:

Doc-from-code:
- JSDoc / KDoc / docstring → generate API reference (TypeDoc, pdoc, Javadoc)
- OpenAPI dari code annotation (Spring Boot, NestJS, FastAPI) → auto-generate spec
- TypeScript types → generate type docs (TypeDoc, TSDoc)
Test-as-doc:
- Cucumber / SpecFlow — Gherkin scenarios jadi executable spec
- Postman / Newman — API tests + documentation merged
- Jest snapshot tests — example outputs
Doc-as-code (CI/CD):
- MkDocs + GitHub Actions — Auto-deploy ke GitHub Pages saat push
- Docusaurus — Same, plus versioning
- Mintlify — SaaS, auto-sync dari GitHub
Architecture as code:
- Structurizr DSL — C4 model → live diagrams
- Terraform plan output → auto-generate infra docs
- Kubernetes manifest → diagram auto-generation

Contoh workflow living documentation:

# .github/workflows/docs.yml
name: Deploy Docs
on:
  push:
    branches: [main]
    paths: [docs/**, src/**]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install mkdocs-material
      - run: mkdocs gh-deploy --force

Benefit:

Doc selalu up-to-date (CI/CD enforce)
Onboarding time turun 50% (new dev baca docs yang works)
Single source of truth (code = doc)

Cost:

Setup awal 2-3 hari (vs 30 menit untuk static markdown)
Vendor lock-in (kalau pakai SaaS seperti Mintlify, Notion, Confluence)
Debugging CI/CD lebih kompleks

Kapan worth it?

(a) Project >1 tahun lifespan
(b) Tim >3 orang
(c) Compliance required (regulated industry)
(d) Customer-facing API

Kapan JANGAN?

(a) Prototype <1 bulan
(b) Solo dev, 1 project
(c) Static marketing site

Tools comparison (2026):

Tool	Language	Hosting	Cost	Best For
MkDocs	Python	GH Pages	Free	OSS projects
Docusaurus	JS	Vercel/Netlify	Free	OSS + commercial
Mintlify	SaaS	Mintlify	$150/mo	Enterprise API
ReadTheDocs	SaaS	RTD	Free OSS, $5/user commercial	Python-heavy
GitBook	SaaS	GitBook	$5/user/mo	Internal wiki
Notion	SaaS	Notion	$10/user/mo	Team wiki
Confluence	Self/SaaS	Atlassian	$6/user/mo	Enterprise

Sumber: MkDocs — https://www.mkdocs.org/ | Docusaurus — https://docusaurus.io/ | Structurizr — https://structurizr.com/

30. Diátaxis Framework Deep-Dive

Diátaxis (Daniele Procida, 2017-2026) — framework documentation yang organize content ke 4 mode berdasarkan user need:

Tutorials (learning-oriented) — "Show me how to do X" — untuk new user, step-by-step
How-to guides (problem-oriented) — "How do I solve Y?" — untuk user dengan goal spesifik
Reference (information-oriented) — "What is Z?" — lookup, API docs, factual
Explanation (understanding-oriented) — "Why is it this way?" — design decisions, history

Pemisahan kritis: Campur tutorial + how-to = bingung user. Tutorial harus sequence (Step 1 → 2 → 3), how-to harus goal-oriented (skip step 1 kalau lo udah expert).

Contoh salah (campur aduk):

"Install Postgres (Step 1). Then... wait, sebelum install, kita bahas dulu kenapa Postgres lebih baik dari MySQL (3 paragraf). Trus install. Oh iya, kalau error, cek log di /var/log/postgres/ (reference info). Sekarang setup user..."

Contoh benar (Diátaxis-compliant):

Tutorial: "First-time Setup Guide — Install Postgres di Mac/Linux/Windows, 15 menit"
How-to: "Cara Migrasi Database ke Postgres Baru (untuk user existing)"
Reference: "Postgres Configuration Reference — semua parameter dengan default value"
Explanation: "Kenapa Kami Pilih Postgres (trade-off, alternative, future plan)"

Struktur repo (MkDocs):

docs/
├── tutorials/
│   ├── getting-started.md
│   ├── first-deployment.md
│   └── adding-team-member.md
├── how-to/
│   ├── migrate-database.md
│   ├── configure-ssl.md
│   └── enable-monitoring.md
├── reference/
│   ├── api/
│   │   ├── authentication.md
│   │   ├── endpoints.md
│   │   └── errors.md
│   ├── cli.md
│   └── config.md
└── explanation/
    ├── architecture.md
    ├── why-postgres.md
    └── roadmap.md

Navigation menu (MkDocs):

nav:
  - Tutorials:
    - Getting Started: tutorials/getting-started.md
    - First Deployment: tutorials/first-deployment.md
  - How-to:
    - Migrate Database: how-to/migrate-database.md
    - Configure SSL: how-to/configure-ssl.md
  - Reference:
    - API: reference/api/endpoints.md
    - CLI: reference/cli.md
  - Explanation:
    - Architecture: explanation/architecture.md

Benefit:

User tau di mana harus lihat (browsing = lebih cepet dari search)
Author tau apa yang harus ditulis (gap analysis)
Konten tidak duplikat (1 topik = 1 kategori)

Anti-pattern:

1 doc yang campur tutorial + how-to + reference → tinggi bounce rate
Tutorial yang pakai jargon tanpa definisi → newbie stuck
How-to yang terlalu panjang (>10 langkah) → pecah jadi beberapa

Pakai kapan?

Project dengan user base diverse (newbie, intermediate, expert)
Docs site yang jadi pusat info
Onboarding process yang harus scalable

Sumber: Diátaxis — https://diataxis.fr/

31. Docs-as-Code Deep-Dive

Docs-as-Code = filosofi bahwa documentation diperlakukan seperti code: version-controlled, code-reviewed, CI/CD-deployed.

Prinsip:

Version control — Doc di Git, bisa rollback, bisa blame
Plain text — Markdown / AsciiDoc / reStructuredText (bukan Word, Google Docs)
Code review — PR untuk doc changes, sama strictness dengan code
Automated testing — Link checker, spell check, style check (vale, markdownlint)
CI/CD deploy — Auto-deploy ke hosting (GitHub Pages, Vercel, Netlify)
Issue tracking — Doc bugs pakai GitHub Issues, bukan email

Toolkit minimal (free):

# 1. Editor: VS Code + extensions
- Markdown All in One
- Markdownlint
- Code Spell Checker
- Mermaid Preview

# 2. Static site generator: MkDocs + Material theme
pip install mkdocs mkdocs-material

# 3. Linting: vale.sh + markdownlint
brew install vale
npm install -g markdownlint-cli

# 4. CI/CD: GitHub Actions
# (Lihat example di section 29)

# 5. Hosting: GitHub Pages (free, unlimited untuk OSS)
# Atau Vercel/Netlify (free tier generous)

Workflow:

1. Author bikin PR dengan changes ke docs/*.md
2. CI/CD run:
   - vale (style check)
   - markdownlint (syntax)
   - spell check
   - link check (broken links)
3. Reviewer approve
4. Auto-deploy ke production
5. Email/Slack notification ke maintainer

Cost-benefit:

Setup awal: 1-2 hari (one-time)
Per-doc: +5 menit (lint + review) vs -30 menit (no version conflict, no "kirim Word ke Tim X")
ROI hitung di project ke-3 (per docs-as-code doc lebih cepet dari Word workflow)

Anti-pattern:

Doc di Word + di-commit sebagai binary (.docx di Git) = useless
Doc di Notion/Confluence + di-link dari README = dua source of truth
Doc yang di-edit langsung di production tanpa PR = no audit trail

Comparison dengan Notion/Confluence:

Aspect	Docs-as-Code	Notion/Confluence
Version control	✅ Git	❌ Built-in only
Plain text	✅ Markdown	❌ Proprietary
Code review	✅ PR	❌ Comment only
Automation	✅ CI/CD	⚠️ Limited
Onboarding	⚠️ Butuh Git skill	✅ Easy drag-drop
Search	⚠️ Need Algolia/MeiliSearch	✅ Built-in
Collaboration	⚠️ Git conflicts	✅ Real-time
Cost	✅ Free (self-host)	❌ $5-10/user/mo

Kapan pilih Notion/Confluence?

Tim non-technical (marketing, sales, support)
Real-time collaboration dominan
Budget OK, no strict compliance

Kapan pilih Docs-as-Code?

Tim teknis, familiar dengan Git
Project >1 tahun
Compliance / audit required
Integration dengan code (CI/CD)

Hybrid approach (best of both):

Engineering docs: docs-as-code (MkDocs)
Product/HR/Marketing docs: Notion
Sync via API (Notion API → MkDocs via webhook)

Sumber: Write the Docs — https://www.writethedocs.org/ | Docs-as-Code di GitHub — https://github.com/topics/docs-as-code

32. 5 International Case Studies Tambahan

Case Study 6: Stripe — API Documentation as Marketing Weapon

Background: Stripe (2011-now) — payment processor global, API docs jadi kunci adopsi developer.

Approach:

Reference-first — API reference selalu up-to-date, generated dari code
Interactive examples — inline code editor yang bisa langsung test API call
Multi-language SDK — 7 bahasa (Node, Python, Ruby, PHP, Java, Go, .NET), setiap bahasa punya guide sendiri
Versioning strict — API version di URL, old version tetap available 18 bulan

Result:

Developer adoption: 90% dari Fortune 500 pakai Stripe
Docs site: 100M+ pageviews/tahun
Time-to-first-payment: 15 menit (vs 2-3 hari untuk competitor)
NPS docs: 70+ (industry average: 30)

Lesson untuk solo dev:

Reference doc berkualitas = competitive advantage
Interactive examples = reduce friction massively
Versioning eksplisit = trust signal

Anti-pattern yang dihindari: Stripe gak punya "Getting Started" panjang — langsung ke "Send your first API request in 30 seconds". Tutorial minimal, reference comprehensive.

Sumber: Stripe Docs — https://stripe.com/docs | Behind the Scenes — https://stripe.com/blog/online-payments

Case Study 7: GitLab — All-Remote Documentation Culture

Background: GitLab (2014-now) — all-remote company 2,000+ employees, documentation adalah cara koordinasi utama.

Approach:

"Handbook First" — semua process (HR, sales, engineering) di handbook, searchable
No meeting without agenda — agenda harus di handbook issue sebelum meeting
Public handbook — semua orang bisa baca (transparency = marketing)
MR = Discussion — decision-making lewat Merge Request + comments

Result:

Onboarding time: 1 minggu (vs 3-6 bulan traditional)
Decision audit trail lengkap (siapa decide apa, kapan, kenapa)
100K+ external readers/bulan (marketing side-effect)

Lesson untuk solo dev:

Documentation = async communication
Public docs = SEO + trust
Decision record (ADR-style) prevent "kok dulu kita decide gini ya?"

Anti-pattern yang dihindari: GitLab gak punya "internal wiki" vs "external docs" — 1 source of truth. Banyak perusahaan punya 2 (confusing).

Sumber: GitLab Handbook — https://about.gitlab.com/handbook/ | All-Remote Playbook — https://about.gitlab.com/company/culture/all-remote/

Case Study 8: HashiCorp — Tutorial-First Approach

Background: HashiCorp (2012-now) — Terraform, Vault, Consul, dll. Docs jadi product surface utama.

Approach:

Tutorials as primary docs — first-time user harus bisa selesai dalam 30 menit
Get Started → Use Cases → Reference — 3-tier navigation
Code examples tested in CI — setiap code snippet di test otomatis
Interactive learning — HashiCorp Learn (learn.hashicorp.com) dengan sandbox

Result:

Terraform adoption: 10M+ downloads, dominant di IaC
Learn platform: 2M+ learners, 50K+/bulan baru
Docs quality: best-in-class menurut developer survey

Lesson untuk solo dev:

Tutorial yang bener-bener works > reference yang lengkap
Test code examples di CI (prevent "docs lie")
Interactive learning = retention tinggi

Anti-pattern yang dihindari: HashiCorp gak pakai jargon tanpa definisi. Setiap konsep baru di-explain di tutorial, baru di-reference di spec.

Sumber: HashiCorp Learn — https://learn.hashicorp.com/ | Terraform Docs — https://developer.hashicorp.com/terraform

Case Study 9: Rust — RFC + This Week in Rust

Background: Rust language (2010-now) — community-driven language, docs jadi core asset.

Approach:

RFC process — semua breaking change butuh RFC + community review
The Rust Programming Language Book — free, comprehensive, official
This Week in Rust — newsletter mingguan curated
docs.rs — auto-generated crate docs untuk semua package

Result:

Stack Overflow Most Loved Language 7 tahun berturut
Crate ecosystem: 150K+ di crates.io
The Book: standard reference untuk belajar Rust

Lesson untuk solo dev:

Community-driven docs > vendor-driven (biasanya)
Auto-generated API docs (docs.rs) = coverage tinggi
Curated newsletter = signal yang terpercaya di laut content

Anti-pattern yang dihindari: Rust gak coba jadi "all things to all people" — fokus ke systems programming, gak try to replace Python di data science.

Sumber: The Rust Book — https://doc.rust-lang.org/book/ | This Week in Rust — https://this-week-in-rust.org/ | docs.rs — https://docs.rs/

Case Study 10: Notion — Engineering Wiki Public

Background: Notion (2013-now) — productivity tool, public engineering blog + docs jadi marketing.

Approach:

Public engineering blog — deep technical posts (scale, architecture, lessons)
Notion Engineering Handbook — partial public, focused on culture
Behind the scenes — datadog, post-mortem, scaling stories
API-first — developer tools extensive docs (api.notion.com)

Result:

Brand: "engineering-first productivity tool"
Recruitment: 50% dari applications yang mereferensikan engineering blog
Developer adoption: 1M+ API calls/bulan

Lesson untuk solo dev:

Engineering content = moat (kompetitor gak bisa copy)
Public post-mortem = trust + learning
API docs = ecosystem (third-party integrations)

Anti-pattern yang dihindari: Notion gak cuma marketing — engineering content berkualitas, bukan "10 reasons why Notion is great".

Sumber: Notion Engineering — https://www.notion.so/blog/category/engineering | Notion API — https://developers.notion.com/

33. Cheat Sheet: 5-Minute Quick Reference

Kalau lo cuma punya 5 menit, ini minimum yang harus lo tahu:

Decision Tree: "Doc apa yang gue butuhin?"

Project size?
├─ <2 minggu, solo
│  └─ Gak perlu doc formal
│  └─ Commit message + README cukup
├─ 2-8 minggu, solo
│  └─ PRD 1 halaman + Tech Spec 1 halaman
├─ 2-6 bulan, solo
│  └─ PRD + SRS ringkas + SDD + 1-2 ADR
├─ 2-6 bulan, tim 2-3
│  └─ PRD + SRS + SDD + ADRs + User Flows
└─ >6 bulan, tim >3
   └─ FULL: PRD + SRS + SDD + ADRs + Living Docs + CI/CD

Stack Minimum (solo dev):

PRD:     1-2 halaman Google Docs / Notion
SRS:     1-2 halaman Google Docs / Notion (kalau perlu)
SDD:     Mermaid diagram + Markdown
ADR:     docs/adr/0001-...md di Git
Diagrams: Excalidraw (hand-drawn) atau Mermaid (code)
Hosting: MkDocs + GitHub Pages (free)

Tools Wajib (5 yang paling impactful):

Mermaid — Diagram as code, hidup di Markdown
Vale.sh — Prose linter, enforce style guide
markdownlint — Markdown syntax check
MkDocs Material — Static site generator, beautiful default theme
GitHub Actions — Auto-deploy docs + run lint di setiap PR

Template 1-Page PRD (copy-paste):

# [Product Name] PRD

## Problem
[2-3 kalimat. User apa masalahnya?]

## Target User
[1 user persona. Siapa, umur, job, pain point.]

## Goals (3 bulan)
1. [Measurable goal #1]
2. [Measurable goal #2]
3. [Measurable goal #3]

## Features (MoSCoW)
**Must Have:**
- [ ] Feature A
- [ ] Feature B
**Should Have:**
- [ ] Feature C
**Won't Have (this release):**
- Feature D

## Success Metrics
- [Metric 1: target value]
- [Metric 2: target value]

## Non-Goals
- [Apa yang GAK akan dibangun]

## Open Questions
- [Pertanyaan yang masih belum terjawab]

Template 1-Page Tech Spec:

# [Product Name] Tech Spec

## Stack
- Frontend: [Next.js 14 / Astro / dll]
- Backend: [Node.js / Python / Go]
- Database: [PostgreSQL / MongoDB]
- Hosting: [Vercel / VPS / Cloud Run]

## Arsitektur (C4 Level 1-2)
[Diagram Mermaid]

## Data Model (3 tabel utama)
[ERD Mermaid]

## API (RESTful / GraphQL)
- GET /api/resource
- POST /api/resource
- [Endpoint list]

## Deployment
[GitHub Actions → Vercel/VPS]

## Risks
- [Risk 1 + mitigation]
- [Risk 2 + mitigation]

Template ADR:

# ADR-[NNN]: [Judul Keputusan]

## Status
[Proposed / Accepted / Deprecated / Superseded by ADR-XXX]

## Context
[Masalah + constraints]

## Decision
[Pilihan yang diambil]

## Consequences
**Good:** [...]
**Bad:** [...]
**Neutral:** [...]

## Alternatives Considered
- [Alt 1]: [why not]
- [Alt 2]: [why not]

34. 20 Kesalahan Pemula yang Sering Terjadi

Group 1: Skip Documentation

"Gak usa PRD, langsung ngoding" — Tanpa doc, scope meledak 2-3x, baru nyadar di week 3. Solusi: 3 jam PRD di awal, hemat 30 jam di belakang.
"Nanti aja dokumentasinya, kalau udah selesai" — "Nanti" = tidak pernah. Solusi: tulis doc paralel dengan code, atau sebelum code.
"README cukup" — README = first impression, bukan comprehensive doc. Solusi: README + docs/ folder untuk detail.

Group 2: Bad Structure

Doc 50 halaman tanpa heading — Reader scroll 5 menit, baru nemu info. Solusi: 1 H1 per doc, multiple H2/H3.
Campur tutorial + how-to + reference — Reader bingung (mau step-by-step atau lookup?). Solusi: Diátaxis 4 mode.
Naming file doc1.md, doc2.md — File name harus deskriptif (getting-started.md, api-reference.md).
Taruh semua di docs/ flat — Solusi: subfolder tutorials/, how-to/, reference/, explanation/.

Group 3: Vague Content

"User harus bisa cepat dapat data" — Berapa cepat? Solusi: measurable: "p95 latency < 200ms".
"Sistem harus reliable" — 99%? 99.9%? 99.99%? Solusi: angka eksplisit + measurement method.
"User-friendly" — Siapa usernya, definisi "friendly" gimana? Solusi: persona + usability test.
"Support semua browser" — Browser apa, versi berapa? Solusi: explicit list + EOL policy.

Group 4: Wrong Audience

Doc teknikal untuk user bisnis — Solusi: 2 docs (executive summary + technical detail).
Doc bisnis untuk developer — Solusi: technical writer untuk developer-facing docs.
"Semua orang baca doc yang sama" — Solusi: persona-based docs (admin vs developer vs end-user).

Group 5: Process Issues

"Doc di-review akhir" — Telat, harus rewrite. Solusi: doc review paralel dengan code review.
Doc tidak ada owner — Setiap orang asumsi orang lain yang maintain. Solusi: CODEOWNERS + review assignment.
"Doc out of date, gakusa di-update" — Doc outdated = lebih bahaya dari gak ada doc. Solusi: 1x per sprint, audit + fix.

Group 6: Anti-Patterns

"Tulis doc sebanyak mungkin" — Quantity ≠ quality. Solusi: write only what user needs, delete unused.
Copy-paste template kosong — Template tanpa content = false comfort. Solusi: fill or delete.
"Doc ini optional" — Kalau optional, gak akan dibaca. Solusi: doc WAJIB atau jangan bikin.

Group 7: Tools Mistakes (Bonus)

Word/Google Docs untuk engineering doc — Tidak version-controlled, no code review. Solusi: Markdown.
Mermaid diagram dari screenshot — Tidak editable, tidak scalable. Solusi: Mermaid code di Markdown.
Doc site tanpa search — User scroll 10 menit. Solusi: Algolia DocSearch (free untuk OSS).
Doc broken links — Audit 1x per bulan. Solusi: link checker di CI (Lychee).

35. 30 FAQ Documentation Engineering

Category 1: Fundamentals (Q1-5)

Q1: Apa bedanya PRD vs SRS? A: PRD = "what & why" (product perspective), SRS = "what exactly" (engineering perspective). PRD untuk stakeholder non-tech, SRS untuk engineer yang implement. Banyak company pakai 1 doc gabungan.

Q2: SDD sama dengan SRS? A: Tidak. SDD (System Design Document) = "how" (arsitektur, design). SRS = "what" (requirements). SDD input dari SRS, output ke code.

Q3: Kapan butuh ADR? A: Saat bikin keputusan arsitektur yang: (a) cost tinggi untuk reverse, (b) banyak alternatives, (c) impact ke banyak orang. Contoh: pilih database, framework, cloud provider. JANGAN bikin ADR untuk naming convention.

Q4: Apakah doc harus selalu update? A: Iya, kalau gak update = outdated = misleading. Solusi: living documentation (auto dari code) atau doc-as-code + CI/CD enforce.

Q5: Berapa lama waktu nulis doc ideal? A: Aturan 30/70: 30% waktu untuk design+doc, 70% untuk implementasi. Bukan 0% doc, bukan 50% doc. Untuk solo project kecil: 1-2 hari doc di awal.

Category 2: Tools (Q6-10)

Q6: MkDocs atau Docusaurus? A: MkDocs = Python, simpel, theme Material cantik, ideal untuk OSS. Docusaurus = JS, fitur lebih (versioning, i18n), ideal untuk product besar. Solo dev OSS: MkDocs.

Q7: Mermaid atau PlantUML? A: Mermaid = Markdown-native, syntax simple, cukup untuk 80% use case. PlantUML = lebih lengkap (UML compliant), perlu Java/jar. Mulai dari Mermaid, upgrade ke PlantUML kalau perlu UML compliance.

Q8: Notion atau Markdown? A: Notion = non-tech team, real-time collab, search bagus. Markdown = tech team, version control, CI/CD. Hybrid: engineering di Markdown, ops/HR di Notion.

Q9: GitBook atau Docs-as-Code? A: GitBook = managed service, easy onboarding, tapi $$. Docs-as-Code = gratis, full control, tapi perlu Git skill. Budget OK + non-tech team: GitBook. Tech team + budget ketat: docs-as-code.

Q10: Confluence atau GitHub Wiki? A: Confluence = enterprise, integrasi Jira, $. GitHub Wiki = free, Git-native, tapi fitur terbatas. Kalau udah pakai Atlassian stack: Confluence. Kalau pure engineering: GitHub Wiki.

Category 3: Process (Q11-15)

Q11: Siapa yang harus nulis doc? A: Orang yang paling paham. Untuk project solo: lo sendiri. Untuk tim: bisa developer yang feature (TBD), atau technical writer (kalau budget). Yang penting: doc reviewed oleh peer.

Q12: Kapan review doc? A: Parallel dengan code review. PR dengan code + doc changes = 1 review. Bukan doc review terpisah di akhir.

Q13: Gimana enforce doc untuk junior dev? A: CODEOWNERS file, template PR checklist ("sudah update docs?"), CI check (broken links, outdated flag).

Q14: Doc sprint vs parallel? A: Parallel > sprint khusus. Doc parallel dengan feature development, di-review bareng PR. Sprint khusus = doc jadi "nanti aja" dan gak ada yang ngerjain.

Q15: Gimana handle doc untuk legacy code? A: (a) Reverse-engineer SDD dari code, (b) Tulis ADR untuk existing decisions, (c) Update README minimum, (d) Buat tutorial untuk common task. Skip kalau legacy mau di-deprecate.

Category 4: Content (Q16-20)

Q16: Berapa panjang 1 doc ideal? A: Sweet spot: 5-15 menit baca (1.5K-5K kata). Lebih dari itu: pecah jadi beberapa. Lebih dari 30 menit: wajib TOC.

Q17: Banyak diagram atau banyak text? A: Diagram untuk high-level (arsitektur, flow). Text untuk detail (logic, edge cases). Rule of thumb: 1 diagram per 500 kata.

Q18: Code examples format apa? A: Markdown code block dengan language tag. Runnable code > pseudo-code. Test code di CI (HashiCorp approach).

Q19: Perlu glossary? A: Iya, kalau domain-specific (finance, healthcare, legal). Plus: istilah internal company (product name, internal tool).

Q20: Bikin doc dalam bahasa Inggris atau Indonesia? A: Default: Inggris (lebih luas audience). Indonesia kalau: (a) target user Indo-only, (b) jargon susah translate, (c) SEO lokal. Hybrid: judul + intro Inggris, content teknis Indonesia.

Category 5: Anti-Patterns (Q21-25)

Q21: Apakah AI bisa bikin doc? A: Bisa untuk draft (PRD, SRS, ADR), tapi HARUS human review. AI halusinasi citation, fabricate references. Pakai untuk productivity, bukan replacement.

Q22: Apakah perlu doc untuk MVP? A: Minimum: README + 1-paragraph PRD. Cukup untuk konteks. SRS/SDD setelah MVP validated.

Q23: Bikin doc sebelum atau sesudah code? A: Idealnya: PRD sebelum code, SRS/SDD sebelum/during, ADR saat bikin keputusan, API doc during. Doc after code = retrospective, banyak yang lupa.

Q24: Apakah internal doc perlu public? A: Tergantung: (a) security risk? (b) competitive advantage? (c) marketing value? GitLab/Notion: public = marketing + trust. Fintech/healthtech: internal only.

Q25: Apakah "comment di code" cukup? A: Untuk context lokal (fungsi spesifik): ya. Untuk arsitektur, decision rationale, on-boarding: tidak. Code comments = how, doc = why.

Category 6: Career & Business (Q26-30)

Q26: Doc skill penting untuk career? A: Sangat. Senior engineer/EM/CTO = 50% waktu untuk doc (decision, design, communication). Writing skill = multiplier untuk technical skill.

Q27: Freelancer harus punya doc skill? A: Iya. Client delivery = working code + readable doc. Tanpa doc, client complain "gue gak ngerti gimana maintain".

Q28: Bagaimana monetize doc skill? A: (a) Technical writer consultant ($50-200/jam), (b) Doc audit service, (c) Bikin template + jual di Gumroad, (d) Course tentang docs.

Q29: Doc engineering = dead career? A: Tidak. Justru dengan AI yang nge-generate code, doc skill yang ngebedain engineer biasa vs engineer premium. AI bisa generate first draft, human refine untuk quality.

Q30: Tools apa yang wajib di-resume? A: MkDocs, Docusaurus, OpenAPI, Mermaid, AsciiDoc, Vale, Markdownlint, GitBook, Notion API. Plus 1-2 specific (Confluence, GitHub Wiki, dll).

36. 90+ Resources Tambahan

Documentation Frameworks (8)

Diátaxis — https://diataxis.fr/
arc42 — https://arc42.org/
C4 Model — https://c4model.com/
Docs-as-Code — https://www.writethedocs.org/
The Good Docs Project — https://www.thegooddocsproject.dev/
Write the Docs Guide — https://www.writethedocs.org/guide/
Documenting APIs — https://idratherbewriting.com/learnapidoc/
Google Developer Documentation Style Guide — https://developers.google.com/style

Tools: Static Site Generators (6)

MkDocs + Material — https://squidfunk.github.io/mkdocs-material/
Docusaurus — https://docusaurus.io/
Sphinx — https://www.sphinx-doc.org/
Hugo — https://gohugo.io/
Jekyll — https://jekyllrb.com/
AsciiDoctor — https://asciidoctor.org/

Tools: Diagram as Code (5)

Mermaid — https://mermaid.js.org/
PlantUML — https://plantuml.com/
Structurizr (C4) — https://structurizr.com/
Excalidraw — https://excalidraw.com/
draw.io (diagrams.net) — https://www.drawio.com/

Tools: API Documentation (5)

OpenAPI / Swagger — https://www.openapis.org/
Swagger UI — https://swagger.io/tools/swagger-ui/
Redoc — https://redocly.com/redoc/
Stoplight Elements — https://stoplight.io/open-source/elements
Mintlify — https://mintlify.com/

Tools: Knowledge Bases / Wikis (5)

Notion — https://www.notion.so/
Confluence — https://www.atlassian.com/software/confluence
GitBook — https://www.gitbook.com/
Outline — https://www.getoutline.com/
BookStack — https://www.bookstackapp.com/

Tools: Linting / Quality (6)

Vale.sh (prose linter) — https://vale.sh/
markdownlint — https://github.com/DavidAnson/markdownlint
Lychee (link checker) — https://github.com/lycheeverse/lychee
htmltest (HTML link checker) — https://github.com/wjdp/htmltest
Alex (offensive language check) — https://alexjs.com/
Write-Good (English linter) — https://github.com/btford/write-good

AI for Documentation (8)

GitHub Copilot for Docs — https://github.com/features/copilot
Mintlify AI Writer — https://mintlify.com/
Claude Projects — https://claude.ai/
Notion AI — https://www.notion.so/product/ai
ReadTheDocs AI Search — https://about.readthedocs.com/blog/2024/ai-search/
DeepWiki — https://deepwiki.com/
Swimm — https://swimm.io/
Document360 — https://document360.com/

Templates & Examples (8)

Awesome README — https://github.com/matiassingers/awesome-readme
PRD Templates (Atlassian) — https://www.atlassian.com/software-development/requirements-gathering
ADR Templates — https://adr.github.io/madr/
SRS Template (IEEE) — https://standards.ieee.org/standard/830-1998.html
MADR Examples — https://github.com/adr/madr
arc42 Examples — https://github.com/arc42/arc42-template
OpenAPI Examples — https://github.com/OAI/OpenAPI-Specification
1-Page Tech Spec (Will Larson) — https://lethain.com/one-page-tech-spec/

Books (10)

Docs-as-Code (Various) — https://www.writethedocs.org/
The Documentation Book (Linn Vizard) — https://thegooddocsproject.dev/
The Product Book — https://theproductbook.com/
Inspired (Marty Cagan) — https://www.svpg.com/products/inspired-2nd-edition
Continuous Discovery Habits (Teresa Torres) — https://www.continuousdiscoveryhabits.com/
The Pragmatic Programmer (Hunt & Thomas) — https://pragprog.com/
Domain-Driven Design (Eric Evans) — https://domainlanguage.com/ddd/
Designing Data-Intensive Applications (Martin Kleppmann) — https://dataintensive.net/
Software Engineering at Google (Titus Winters) — https://abseil.io/resources/swe-book
Accelerate (Forsgren, Humble, Kim) — https://itrevolution.com/product/accelerate/

Communities (6)

Write the Docs — https://www.writethedocs.org/
The Good Docs Project — https://www.thegooddocsproject.dev/
Information Architecture Community — https://www.iainstitute.org/
API Evangelist — https://apievangelist.com/
Stack Overflow Documentation — https://stackoverflow.com/documentation
Reddit r/technicalwriting — https://www.reddit.com/r/technicalwriting/

Conferences & Newsletters (5)

Write the Docs Conference — https://www.writethedocs.com/conf/
API Days — https://www.apidays.global/
The Pragmatic Engineer Newsletter — https://newsletter.pragmaticengineer.com/
Console (newsletter) — https://console.dev/
Software Design: Tidy First? (Kent Beck) — https://tidyfirst.substack.com/

Cheat Sheets & Quick References (4)

Markdown Cheat Sheet — https://www.markdownguide.org/cheat-sheet/
Mermaid Cheat Sheet — https://jojozhuang.github.io/tutorial/mermaid-cheat-sheet/
Git Cheat Sheet — https://education.github.com/git-cheat-sheet-education.pdf
REST API Design Cheat Sheet — https://restfulapi.net/rest-api-design-tutorial-with-example/

Standards (5)

IEEE 830-1998 — https://standards.ieee.org/standard/830-1998.html
IEEE 29148-2018 — https://standards.ieee.org/standard/29148-2018.html
ISO/IEC/IEEE 12207:2017 — https://www.iso.org/standard/63712.html
ISO/IEC/IEEE 42010:2011 — https://www.iso.org/standard/50508.html
RFC 2119 (Keywords) — https://datatracker.ietf.org/doc/html/rfc2119

Domain-Specific Docs (5)

FDA Software Documentation (Medical) — https://www.fda.gov/medical-devices/software-medical-device-samd
DO-178C (Aerospace) — https://www.rtca.org/
PCI-DSS Documentation (Fintech) — https://www.pcisecuritystandards.org/
HIPAA Documentation (Healthcare) — https://www.hhs.gov/hipaa/
GDPR Documentation (EU Privacy) — https://gdpr-info.eu/

37. 110+ Referensi (Expanded)

Standards & Specs (15)

IEEE 830-1998: SRS Recommended Practice — https://standards.ieee.org/standard/830-1998.html
IEEE 29148-2018: Requirements Engineering — https://standards.ieee.org/standard/29148-2018.html
ISO/IEC/IEEE 12207:2017: Software Lifecycle — https://www.iso.org/standard/63712.html
ISO/IEC/IEEE 42010:2011: Architecture Description — https://www.iso.org/standard/50508.html
ISO 9001:2015: Quality Management — https://www.iso.org/standard/62085.html
ISO/IEC 25010:2011: Software Product Quality — https://www.iso.org/standard/35733.html
RFC 2119: Requirement Keywords — https://datatracker.ietf.org/doc/html/rfc2119
RFC 8174: Ambiguity Update for RFC 2119 — https://datatracker.ietf.org/doc/html/rfc8174
OpenAPI 3.1 Spec — https://spec.openapis.org/oas/v3.1.0
AsyncAPI 2.6 Spec — https://www.asyncapi.com/
JSON Schema 2020-12 — https://json-schema.org/
TOML 1.0 Spec — https://toml.io/en/v1.0
Markdown Spec (CommonMark) — https://commonmark.org/
AsciiDoc Spec — https://asciidoctor.org/
SPDX License List — https://spdx.org/licenses/

Books (15)

The Pragmatic Programmer (Hunt & Thomas) — https://pragprog.com/
Domain-Driven Design (Eric Evans) — https://domainlanguage.com/
Designing Data-Intensive Applications (Kleppmann) — https://dataintensive.net/
The Mythical Man-Month (Fred Brooks) — https://www.goodreads.com/book/show/13629
Clean Architecture (Robert Martin) — https://www.oreilly.com/library/view/clean-architecture/9780134494166/
The Phoenix Project (Gene Kim) — https://itrevolution.com/the-phoenix-project/
Accelerate (Forsgren et al) — https://itrevolution.com/accelerate/
Team Topologies (Skelton & Pais) — https://teamtopologies.com/
Continuous Architecture (Skurla) — https://www.continuous-architecture.com/
Software Architecture: The Hard Parts (Ford et al) — https://www.oreilly.com/library/view/software-architecture-the/9781492086888/
Documenting Software Architecture (Clements et al) — https://www.oreilly.com/library/view/documenting-software-architecture/9780132488588/
The Documentation Book (Vizard) — https://thegooddocsproject.dev/the-documentation-book
Inspired (Marty Cagan) — https://www.svpg.com/
Continuous Discovery Habits (Teresa Torres) — https://www.continuousdiscoveryhabits.com/
Shape Up (Basecamp) — https://basecamp.com/shapeup

Articles & Blog Posts (20)

Paul Graham: Write Code, Not Docs — https://www.paulgraham.com/ds.html
Paul Graham: "Maker's Schedule, Manager's Schedule" — https://www.paulgraham.com/makersschedule.html
Joel Spolsky: "Painless Functional Specifications" — https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-write-specs/
Joel Spolsky: "Bionic Office" — https://www.joelonsoftware.com/2000/04/26/bionic-office/
Martin Fowler: "Patterns of Enterprise Application Architecture" — https://martinfowler.com/books/eaa.html
Martin Fowler: "Is Design Dead?" — https://martinfowler.com/articles/designDead.html
Martin Fowler: "PatternsPrimer" — https://martinfowler.com/eaaCatalog/
Kent Beck: "Tidy First?" — https://tidyfirst.substack.com/
Kent Beck: "Test-Driven Development" — https://www.kentbeck.com/
Eric Sink: "Source Code Control" — https://ericsink.com/scm/source_code_control.html
Charity Majors: "Observability" — https://charity.wtf/tag/observability/
Charity Majors: "Honeycomb Blog" — https://www.honeycomb.io/blog/
Sam Newman: "Building Microservices" — https://samnewman.io/books/building_microservices_2nd_edition/
Gregor Hohpe: "The Software Architecture Chronicles" — https://www.enterpriseintegrationpatterns.com/
Simon Brown: "C4 Model" — https://c4model.com/
Simon Brown: "Software Architecture for Developers" — https://simonbrown.je/
Daniele Procida: "Diátaxis" — https://diataxis.fr/
Daniele Procida: "What nobody tells you about documentation" — https://www.youtube.com/watch?v=ztL0kikz8rc
William Zinsser: "On Writing Well" — https://www.williamzinsserwriting.com/
Strunk & White: "The Elements of Style" — https://www.bartleby.com/141/strunk5.html

Tools & Software (20)

MkDocs — https://www.mkdocs.org/
Docusaurus — https://docusaurus.io/
Mintlify — https://mintlify.com/
ReadTheDocs — https://about.readthedocs.com/
GitBook — https://www.gitbook.com/
Notion — https://www.notion.so/
Confluence — https://www.atlassian.com/software/confluence
Outline — https://www.getoutline.com/
Excalidraw — https://excalidraw.com/
Mermaid — https://mermaid.js.org/
PlantUML — https://plantuml.com/
Structurizr — https://structurizr.com/
draw.io — https://www.drawio.com/
Vale.sh — https://vale.sh/
markdownlint — https://github.com/DavidAnson/markdownlint
Lychee — https://github.com/lycheeverse/lychee
Swagger Editor — https://editor.swagger.io/
Redocly — https://redocly.com/
Stoplight — https://stoplight.io/
Sphinx — https://www.sphinx-doc.org/

Templates (10)

MADR Template — https://adr.github.io/madr/
arc42 Template — https://arc42.org/
PRD Template (Atlassian) — https://www.atlassian.com/software-development/requirements-gathering
PRD Template (ProductPlan) — https://www.productplan.com/
One-Page PRD (Lenny's) — https://www.lennysnewsletter.com/p/the-one-page-prd
Tech Spec Template (Will Larson) — https://lethain.com/one-page-tech-spec/
ADR Tools by Nat Pryce — https://github.com/npryce/adr-tools
log4brains (ADR site generator) — https://github.com/thomvaill/log4brains
OpenAPI Examples — https://github.com/OAI/OpenAPI-Specification
GitHub Issue Templates — https://github.com/topics/issue-template

Communities & Conferences (10)

Write the Docs — https://www.writethedocs.org/
The Good Docs Project — https://www.thegooddocsproject.dev/
Information Architecture Institute — https://www.iainstitute.org/
API Evangelist — https://apievangelist.com/
Write the Docs Conf — https://www.writethedocs.com/conf/
API Days — https://www.apidays.global/
Stack Overflow Documentation — https://stackoverflow.com/documentation
Reddit r/technicalwriting — https://www.reddit.com/r/technicalwriting/
Hacker News (show HN) — https://news.ycombinator.com/
Indie Hackers — https://www.indiehackers.com/

Companies Doing It Well (10)

Stripe API Docs — https://stripe.com/docs
GitLab Handbook — https://about.gitlab.com/handbook/
Notion Engineering — https://www.notion.so/blog/category/engineering
HashiCorp Learn — https://learn.hashicorp.com/
The Rust Book — https://doc.rust-lang.org/book/
MDN Web Docs — https://developer.mozilla.org/
Tailwind CSS Docs — https://tailwindcss.com/docs
Vercel Docs — https://vercel.com/docs
Cloudflare Docs — https://developers.cloudflare.com/
AWS Docs — https://docs.aws.amazon.com/

Methodologies (10)

Agile Manifesto — https://agilemanifesto.org/
Scaled Agile (SAFe) — https://scaledagileframework.com/
Shape Up (Basecamp) — https://basecamp.com/shapeup
Lean Startup — https://theleanstartup.com/
Domain-Driven Design — https://domainlanguage.com/ddd/
Team Topologies — https://teamtopologies.com/
Wardley Maps — https://medium.com/wardleymaps
Continuous Discovery — https://www.continuousdiscoveryhabits.com/
Documentation as Code — https://www.writethedocs.org/
Google SRE Book — https://sre.google/sre-book/table-of-contents/

20 Referensi

IEEE 830-1998: Recommended Practice for Software Requirements Specifications — https://standards.ieee.org/standard/830-1998.html
Atlassian: PRD Templates & Examples — https://www.atlassian.com/software-development/requirements-gathering
stokquproject TikTok: Dokumentasi untuk Solo Dev (2026-07-24) — Cross-referenced dengan IEEE 830 + Atlassian + Martin Fowler
Martin Fowler: Patterns of Enterprise Application Architecture — https://martinfowler.com/books/eaa.html
Paul Graham: Write Code, Not Docs (YC Essay) — https://www.paulgraham.com/ds.html
Diátaxis Documentation Framework — https://diataxis.fr/
MADR (Markdown ADR) Template — https://adr.github.io/madr/
ADR Tools by Nat Pryce — https://github.com/npryce/adr-tools
log4brains: Living ADR Documentation — https://github.com/thomvaill/log4brains
MkDocs (Documentation as Code) — https://www.mkdocs.org/
Docusaurus (Facebook Open Source) — https://docusaurus.io/
Excalidraw (Hand-drawn Diagrams) — https://excalidraw.com/
Mintlify (Modern API Docs) — https://mintlify.com/
Fern (API Docs Generator) — https://buildwithfern.com/
OpenAPI Specification — https://www.openapis.org/
Sphinx + autodoc (Python) — https://www.sphinx-doc.org/
Notion Engineering Wiki Templates — https://www.notion.so/templates/engineering
Confluence Templates by Atlassian — https://www.atlassian.com/software/confluence/templates
Figma for Product Managers — https://www.figma.com/solutions/product-management/
The Pragmatic Programmer: Documentation Chapter (Hunt & Thomas) — https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/

Mau share framework dokumentasi favorit lo, atau ada pertanyaan spesifik kapan harus pilih Formal vs Process? Drop di komentar — Tim Toolkuy biasa review template doc gratis untuk yang request spesifik. Atau kalau lo lagi stuck nulis PRD untuk project baru, kasih tau problem-nya, kita bantu brainstorm scope. 🦀

Resources Pendukung

Biar dokumentasi framework di artikel ini gak cuma jadi teori, lo butuh infrastruktur yang murah, terukur, dan gampang di-scale. Semua rekomendasi di bawah nyambung langsung ke section yang udah dibahas — mulai dari §31 Docs-as-Code Deep-Dive sampe §33 Cheat Sheet: 5-Minute Quick Reference:

Compute buat jalanin doc-as-code CI pipeline — §31 Docs-as-Code Deep-Dive dan §10 Best Practices Dokumentasi nunjukin: docs-as-code itu build docs tiap commit, render preview, dan auto-deploy ke staging. Pipeline yang jalan terus-menerus itu butuh server, bukan laptop lo yang ditutup tiap malem — cek free tier Alibaba Cloud buat ngerasain docs pipeline pertama lo.
Storage buat doc artifacts & ADR — §28 ADR (Architecture Decision Records) Deep-Dive dan §29 Living Documentation Deep-Dive nyuruh lo simpen ADR, decision log, dan doc artifacts yang timestamped biar bisa di-refer ulang. ADR yang ke-overwrite = keputusan ilang. Benefits campaign Alibaba Cloud sering ngasih kuota storage gratis buat ngetes.
Database buat doc tracking & glossary — §27 Documentation Glossary: 40+ Istilah Wajib Tau dan §33 Cheat Sheet: 5-Minute Quick Reference butuh lo nyimpen istilah, doc status, dan ownership tiap section biar gak ada doc yang mati. Simpen di database yang bisa lo query, bukan spreadsheet yang numpuk — Cek penawaran database di Alibaba Cloud.
Compute scaling buat preview build & multi-branch docs — §31 Docs-as-Code Deep-Dive dan §90-Day Documentation Sprint nunjukin: preview per PR + sprint paralel = banyak build jalan barengan. Itu butuh resource yang fleksibel pas scope naik. Benefits campaign Alibaba Cloud ngasih fleksibilitas buat scale up pas lo butuh.
Container buat reproducible doc build — §31 Docs-as-Code Deep-Dive dan §29 Living Documentation Deep-Dive nyuruh lo bikin build yang reproducible: environment tooling yang sama persis di tiap run, biar docs bisa di-rebuild bulan depan tanpa "kok formatnya beda?". Container image registry itu wajib — container & registry services bikin ini gampang.
AI coding buat generate doc skeleton — §26 AI Tools for Documentation 2026 dan Framework #2: Process-Oriented Docs (Lean) itu banyak boilerplate-nya: bikin template PRD, SRS, dan ADR. Pakai AI coding buat generate skeleton dan draft pertama — ini bisa motong waktu nulis docs sampe separuhnya — AI scene coding dari Alibaba Cloud worth dicoba buat accelerate development.
AI buat review & consistency check — §26 AI Tools for Documentation 2026 dan §10 Best Practices Dokumentasi ngingetin lo: docs yang gak konsisten (istilah beda, format beda) itu musuh utama maintainability. AI yang bisa cross-check konsistensi antar doc itu penghemat waktu gila-gilaan — AI coding tools Alibaba include bantuan analisis yang lumayan.
Observability buat doc freshness — §29 Living Documentation Deep-Dive dan §10 Best Practices Dokumentasi butuh lo tau kapan doc mulai stale: last-updated, broken link, dan doc yang gak diakses siapa-siapa. Kalau doc lo mati diam-diam, lo mau tau dari dashboard bukan dari client yang komplen — Alibaba Cloud benefits punya paket observability yang bisa lo cobain.
Free tier buat POC — §90-Day Documentation Sprint (untuk Existing Project) dan §TL;DR — Minimum Viable Documentation dua-duanya nyaranin mulai dari scope kecil: 1 project, 3 doc inti, 30 hari. Sebelum bayar apapun, bikin POC di resource gratisan dulu — kalau framework lo terbukti kerja, baru naikin ke paid tier — free tier Alibaba Cloud ngasih kuota tiap bulan buat eksperimen ini.
Compute scalable buat production. Cocok buat ngecek realita Step 6: Deployment & Maintenance Plan di artikel ini — ECS 9th-gen g9i Alibaba Cloud ngasih kuota yang pas buat nyobain sendiri.

Semua link di atas punya kuota gratis yang lumayan buat testing, jadi gak ada alasan buat nunda eksperimen — tinggal daftar, cobain, dan bandingin hasilnya sama §5 Case Study Indonesia: Dokumentasi yang Berhasil & Gagal dan §32 5 International Case Studies Tambahan di artikel ini.

Topik Terkait

Artikel lain yang relevan dengan topik AI agent, workflow, dan teknis toolkuy: