Saya mau cerita pengalaman yang masih membekas sampai sekarang.
Tahun 2019, ada client yang minta dibuatkan website e-commerce. Projectnya lumayan besar — estimasi 2 bulan pengerjaan. Kita deal harga Rp 25 juta, dan karena "sudah kenal" lewat referensi teman, saya skip kontrak formal. Cuma chat WhatsApp doang yang isinya "ok deal ya mas, kita mulai minggu depan."
Bagian 1: Kenapa Kontrak Itu Penting
Dua bulan kemudian, website selesai. Semua fitur jalan sesuai yang dibahas. Tapi waktu mau handover dan tagih pelunasan, client bilang: "Ini kok beda sama yang saya bayangkan ya. Harusnya ada fitur A, B, C juga."
Fitur A, B, C? Tidak pernah dibahas sebelumnya.
Saya scroll balik chat WhatsApp. Tidak ada. Tapi client ngotot itu "sudah pernah dibahas di meeting." Meeting yang tidak ada notulennya. Meeting yang cuma verbal.
Long story short, project itu molor 2 bulan lagi untuk "revisi" yang sebenarnya fitur baru. Dan saya cuma dibayar 60% dari total harga karena "tidak sesuai ekspektasi."
Rp 10 juta hilang. Dua bulan waktu terbuang. Dan yang paling menyakitkan: tidak ada yang bisa saya lakukan karena tidak ada dokumentasi tertulis.
"Itu adalah Rp 10 juta yang saya bayar untuk belajar pentingnya kontrak."
Realita Freelancer Indonesia
Cerita saya bukan unik. Kalau kamu aktif di komunitas freelancer, cerita seperti ini bertebaran. Client ghosting setelah project selesai. Revisi tanpa batas yang bikin project tidak profitable. Scope yang terus melebar tanpa tambahan bayaran.
Dan pattern-nya sama: tidak ada kontrak yang jelas.
Kenapa banyak freelancer skip kontrak? Alasannya klasik. "Projectnya kecil kok." "Sudah kenal orangnya." "Nanti malah keliatan tidak percaya." "Ribet, yang penting kerja dulu."
Saya paham. Dulu saya juga begitu.
Tapi setelah beberapa kali "kebakar," mindset saya berubah total.
Kontrak Bukan Tanda Tidak Percaya
Mari kita luruskan satu hal: kontrak bukan berarti kamu tidak percaya client. Justru sebaliknya.
KONTRAK BUKAN:
├── Tanda curiga atau tidak percaya
├── Formalitas yang bikin ribet
├── Cuma untuk project besar
├── Sesuatu yang bikin suasana awkward
└── Dokumen yang cuma menguntungkan satu pihak
KONTRAK ADALAH:
├── Perlindungan untuk KEDUA pihak
├── Clarity supaya tidak ada miskomunikasi
├── Tanda profesionalisme
├── Insurance kalau relationship memburuk
├── Dokumentasi yang bisa di-refer kapan saja
└── Tool untuk set expectations dari awal
Client yang profesional justru akan appreciate kalau kamu punya kontrak. Itu menunjukkan kamu serius, reliable, dan pernah handle project dengan proper. Red flag justru kalau client keberatan dengan kontrak — itu warning sign bahwa mereka mungkin planning untuk take advantage.
Yang Akan Kita Bahas
Di artikel ini, saya akan breakdown 10 hal krusial yang HARUS ada dalam setiap kontrak kerja freelance. Bukan legal jargon yang bikin pusing, tapi practical guide dengan:
- Penjelasan kenapa setiap elemen penting
- Contoh klausa yang bisa langsung kamu pakai
- Red flags yang harus diwaspadai
- Tips cara negotiate tanpa awkward
Setelah baca artikel ini, kamu akan punya framework untuk bikin atau review kontrak freelance yang solid. Tidak perlu perfect dari awal — kontrak sederhana yang cover hal-hal penting sudah jauh lebih baik dari tidak ada kontrak sama sekali.
Mari kita mulai dari hal yang paling sering jadi sumber masalah.
Bagian 2: Hal #1 - Scope of Work yang Detail
<image src="unsplash" alt="checklist document planning" />
Kalau saya harus pilih satu hal terpenting dalam kontrak, ini dia: Scope of Work.
Kenapa? Karena 80% masalah dalam project freelance berasal dari scope yang tidak jelas. "Saya kira termasuk..." adalah kalimat paling berbahaya yang bisa kamu dengar dari client. Dan biasanya kalimat itu muncul di akhir project, ketika kamu sudah invest waktu dan tenaga.
Scope creep — kondisi di mana scope terus melebar tanpa tambahan bayaran — adalah silent killer of profitability. Project yang harusnya profitable jadi rugi karena kerjaan terus bertambah tapi harga tetap.
Solusinya? Scope of Work yang detail, spesifik, dan tidak ambigu.
Yang Harus Ada dalam Scope
SCOPE OF WORK CHECKLIST:
☐ Deskripsi project secara umum
☐ List deliverables yang spesifik
☐ Spesifikasi teknis (kalau relevan)
☐ Jumlah halaman/screens/features
☐ Platform/device yang di-support
☐ Content — siapa yang provide?
☐ Apa yang TIDAK termasuk (exclusions)
Point terakhir — exclusions — sering di-skip padahal super penting. Dengan explicitly menyebut apa yang TIDAK termasuk, kamu menutup celah untuk "saya kira termasuk."
Contoh Scope: Jelek vs Bagus
Mari kita lihat perbedaannya.
❌ Scope yang JELEK:
Membuat website company profile untuk PT ABC.
Apa masalahnya? Semuanya. Berapa halaman? Fitur apa saja? Siapa yang provide content? Responsive atau tidak? Platform apa? Ini bukan scope, ini undangan untuk masalah.
✅ Scope yang BAGUS:
SCOPE OF WORK: Website Company Profile PT ABC
1. HALAMAN YANG DIBUAT (5 halaman):
• Homepage
- Hero section dengan tagline perusahaan
- Section highlights (3 items)
- Testimonial slider (max 5 testimonials)
- CTA section
• About Us
- Company history (timeline format)
- Vision & Mission
- Team section (max 8 orang dengan foto dan jabatan)
• Services
- List services (maksimal 6 services)
- Masing-masing dengan icon, judul, dan deskripsi singkat
• Portfolio/Projects
- Grid layout (maksimal 12 items)
- Lightbox untuk detail gambar
• Contact
- Contact form (nama, email, subject, message)
- Google Maps embed
- Informasi kontak (alamat, telepon, email)
2. FITUR YANG TERMASUK:
• Responsive design (mobile, tablet, desktop)
• Contact form dengan email notification ke [email client]
• WhatsApp floating button
• Basic SEO on-page (meta title, description, alt tags)
• Google Analytics integration
• SSL certificate setup
• Loading speed optimization (target: < 3 detik)
3. YANG TIDAK TERMASUK DALAM SCOPE (EXCLUSIONS):
• Copywriting — semua teks disediakan oleh Client
• Fotografi dan videografi
• Logo design atau rebranding
• E-commerce/shopping functionality
• Blog atau CMS untuk update konten
• Multi-bahasa
• Maintenance setelah handover
• Biaya hosting dan domain (disediakan Client)
• Custom illustration
4. SPESIFIKASI TEKNIS:
• Platform: WordPress dengan flavor starter
• Browser support: Chrome, Firefox, Safari, Edge (2 versi terakhir)
• Bahasa: Indonesia
• Hosting requirement: PHP 8.0+, MySQL 5.7+
5. ASSETS YANG DIBUTUHKAN DARI CLIENT:
• Logo dalam format PNG/SVG (high resolution)
• Foto team (min 800x800px)
• Foto portfolio/projects (min 1200x800px)
• Semua teks/copy untuk setiap halaman
• Informasi kontak lengkap
Lihat perbedaannya? Dengan scope seperti ini, tidak ada ruang untuk "saya kira termasuk."
Red Flags dalam Scope
Waspada kalau kamu menemukan (atau diminta menulis) scope dengan pattern seperti ini:
🚩 "...dan hal-hal lain yang diperlukan"
→ Ini carte blanche untuk unlimited requests
🚩 "...sesuai kebutuhan client"
→ Kebutuhan siapa? Kapan? Bisa berubah terus
🚩 "...termasuk revisi sampai client puas"
→ Puas itu kapan? Bisa selamanya
🚩 Tidak ada section exclusions
→ Semua hal yang tidak disebut = gray area
🚩 Scope cuma verbal, tidak tertulis
→ "Yang dibahas di meeting" tidak bisa dibuktikan
Tips Menangani Scope Creep
Scope creep pasti akan terjadi — yang penting adalah bagaimana menanganinya.
Gunakan Change Order:
Ketika client minta sesuatu di luar scope:
"Untuk fitur [X] yang Bapak/Ibu minta, ini tidak termasuk
dalam scope awal kita. Saya bisa kerjakan dengan additional
cost Rp [Y] dan tambahan waktu [Z] hari.
Mau saya buatkan quotation terpisah untuk ini?"
Dengan cara ini, kamu tidak menolak — kamu memberikan opsi. Client yang reasonable akan mengerti. Client yang tidak reasonable... well, lebih baik ketahuan dari awal.
Rule of Thumb:
"Kalau ragu apakah sesuatu termasuk scope atau tidak, masukkan ke exclusions. Lebih baik over-specify daripada under-specify."
Bagian 3: Hal #2 - Timeline dan Milestones
<image src="unsplash" alt="calendar planning timeline schedule" />
Scope menjawab pertanyaan "apa yang dikerjakan." Timeline menjawab "kapan selesainya."
Tanpa timeline yang jelas, project bisa molor tanpa batas. Kamu tidak bisa plan workload, tidak bisa commit ke project lain, dan client juga tidak punya predictability kapan bisa launch.
Tapi timeline bukan cuma satu tanggal deadline di akhir. Timeline yang baik punya milestones, review periods, dan yang paling penting: dependencies.
Elemen Timeline yang Harus Ada
TIMELINE ELEMENTS:
1. PROJECT START DATE
└── Kapan project officially dimulai?
Biasanya: setelah kontrak ditandatangani DAN DP diterima
2. MILESTONES
└── Break down project jadi phases
Setiap phase punya deliverable dan deadline spesifik
3. REVIEW PERIODS
└── Berapa lama waktu client untuk review setiap deliverable?
Apa konsekuensi kalau tidak review tepat waktu?
4. FINAL DELIVERY DATE
└── Target completion date
DENGAN CATATAN semua dependencies terpenuhi
5. DEPENDENCIES & ASSUMPTIONS
└── Apa yang harus client sediakan, dan kapan?
Timeline berlaku JIKA dan HANYA JIKA dependencies terpenuhi
Point nomor 5 — dependencies — adalah yang paling sering di-ignore. Padahal ini crucial. Kalau client telat kirim content 2 minggu, timeline juga harus geser 2 minggu. Ini harus explicit di kontrak.
Contoh Timeline yang Solid
PROJECT TIMELINE
Total Durasi: 4 minggu (20 working days)
Start Date: Dimulai setelah DP 50% diterima
─────────────────────────────────────────────────────────────
MINGGU 1: Discovery & Design
├── Day 1-2
│ └── Kickoff meeting
│ └── Gather requirements dan content dari Client
│
├── Day 3-5
│ └── Wireframe untuk semua halaman
│ └── Design mockup (Homepage + 1 inner page)
│
├── DELIVERABLE: Design mockup untuk review
└── CLIENT REVIEW PERIOD: 3 hari kerja
→ Feedback harus diterima paling lambat Day 8
─────────────────────────────────────────────────────────────
MINGGU 2: Development Phase 1
├── Day 9-13
│ └── Development Homepage
│ └── Development About page
│ └── Setup hosting dan domain
│
├── DELIVERABLE: Staging link untuk review
└── CLIENT REVIEW PERIOD: 2 hari kerja
→ Feedback harus diterima paling lambat Day 15
─────────────────────────────────────────────────────────────
MINGGU 3: Development Phase 2
├── Day 14-18
│ └── Development halaman tersisa (Services, Portfolio, Contact)
│ └── Integration contact form
│ └── Mobile responsive optimization
│
├── DELIVERABLE: Full staging site untuk review
└── CLIENT REVIEW PERIOD: 3 hari kerja
→ Feedback harus diterima paling lambat Day 21
─────────────────────────────────────────────────────────────
MINGGU 4: Revision & Launch
├── Day 19-21
│ └── Revisions berdasarkan feedback (max 2 rounds)
│
├── Day 22-23
│ └── Final testing (cross-browser, mobile)
│ └── Performance optimization
│ └── Deployment ke production
│
└── DELIVERABLE: Live website ✓
─────────────────────────────────────────────────────────────
DEPENDENCIES (Harus dipenuhi Client):
☐ Semua content (teks dan gambar) diterima sebelum Day 3
☐ Feedback design diberikan dalam 3 hari kerja
☐ Akses hosting/domain diberikan sebelum Day 9
☐ Feedback development diberikan sesuai review period
⚠️ PENTING:
Keterlambatan dari Client akan menggeser timeline
secara proporsional. Developer tidak bertanggung jawab
atas keterlambatan yang disebabkan oleh Client.
Kenapa Review Period Penting?
Ini yang sering di-skip: deadline untuk client memberikan feedback.
Tanpa ini, apa yang terjadi? Client bisa "hold" feedback berminggu-minggu, dan kamu terjebak — tidak bisa lanjut, tidak bisa close project, tidak bisa move on ke project lain.
REVIEW PERIOD CLAUSE:
"Client memiliki waktu [X hari kerja] untuk memberikan
feedback setelah deliverable dikirim. Jika tidak ada
feedback dalam periode tersebut, deliverable dianggap
APPROVED dan Developer akan melanjutkan ke tahap berikutnya."
Clause ini game-changer. Kamu punya leverage untuk move forward tanpa harus nunggu selamanya.
Red Flags dalam Timeline
🚩 "ASAP" atau "Secepat mungkin"
→ Bukan timeline, ini wishful thinking
🚩 Tidak ada buffer untuk revisions
→ Revisi PASTI ada, harus di-account
🚩 Client tidak punya deadline untuk feedback
→ Recipe for endless waiting
🚩 Timeline tidak mention dependencies
→ Kalau client telat, kamu yang kena
🚩 Satu deadline di akhir tanpa milestones
→ Tidak ada checkpoint, masalah baru ketahuan di akhir
Protect Yourself
Tambahkan klausul ini di kontrak:
"Timeline di atas berlaku dengan asumsi semua dependencies
terpenuhi sesuai jadwal. Keterlambatan dari pihak Client
dalam menyediakan materials, feedback, atau approval akan
menggeser timeline secara proporsional tanpa penalti
terhadap Developer."
Simple, tapi powerful. Ini melindungi kamu dari situasi di mana client telat berminggu-minggu tapi expect timeline tetap sama.
Bagian 4: Hal #3 - Payment Terms dan Schedule
<image src="unsplash" alt="money payment transaction business" />
Ini yang paling sensitif tapi paling penting: uang.
Payment terms yang tidak jelas adalah sumber masalah terbesar setelah scope. Client yang ghosting setelah project selesai, pembayaran yang molor berbulan-bulan, "cashflow lagi tight mas" yang tidak ada ujungnya — semua ini bisa diminimalisir dengan payment terms yang solid.
Golden rule yang saya pegang:
"Never deliver final files before final payment. Never start work before first payment."
Kedengarannya harsh? Mungkin. Tapi setelah beberapa kali ketipu, ini jadi non-negotiable.
Elemen Payment Terms
PAYMENT TERMS CHECKLIST:
☐ Total project fee (angka jelas, mata uang jelas)
☐ Payment schedule (kapan bayar berapa)
☐ Payment method yang accepted
☐ Invoice terms (kapan invoice dikirim)
☐ Due date (berapa hari setelah invoice)
☐ Late payment consequences
☐ Mata uang dan kurs (untuk client luar negeri)
☐ Pajak — siapa yang tanggung?
☐ Kondisi untuk release final deliverables
Payment Schedule Options
Tidak ada satu formula yang cocok untuk semua. Pilih berdasarkan size project dan relationship dengan client.
Opsi 1: 50-50 (Paling Umum)
├── 50% upfront — sebelum project dimulai
└── 50% on completion — sebelum final files di-handover
Best for:
• Project kecil sampai menengah (< Rp 20 juta)
• Client baru yang belum ada track record
• Project dengan durasi < 1 bulan
Opsi 2: 50-25-25 (Untuk Project Menengah)
├── 50% upfront — sebelum mulai
├── 25% at midpoint — setelah milestone tengah selesai
└── 25% on completion — sebelum handover
Best for:
• Project menengah (Rp 20-50 juta)
• Durasi 1-2 bulan
• Ada milestone natural di tengah (design approval, dll)
Opsi 3: 30-30-30-10 (Untuk Project Besar)
├── 30% upfront — sebelum mulai
├── 30% after design — setelah design approved
├── 30% after development — setelah development selesai
└── 10% after launch — setelah go-live
Best for:
• Project besar (> Rp 50 juta)
• Durasi 2-3 bulan+
• Client corporate yang butuh staged payments
Opsi 4: Monthly Retainer (Untuk Ongoing Work)
├── Fixed amount per bulan
├── Dibayar di awal bulan (sebelum kerja)
├── Include X jam atau Y deliverables per bulan
└── Unused hours tidak rollover (atau rollover dengan limit)
Best for:
• Maintenance contracts
• Ongoing development work
• Long-term client relationships
Contoh Payment Terms yang Solid
PAYMENT TERMS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
TOTAL PROJECT FEE
Rp 15.000.000 (Lima Belas Juta Rupiah)
Harga sudah termasuk:
• Semua deliverables sesuai Scope of Work
• 2 rounds revisi per milestone
• Support selama development
Harga belum termasuk:
• PPN 11% (jika diperlukan faktur pajak)
• Biaya hosting dan domain
• Stock photos premium (jika dibutuhkan)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PAYMENT SCHEDULE
┌─────────────────────────────────────────────────────────┐
│ Tahap │ Jumlah │ Kapan │
├─────────────────────────────────────────────────────────┤
│ DP │ Rp 7.500.000│ Sebelum project dimulai │
│ (50%) │ │ Invoice dikirim saat │
│ │ │ kontrak ditandatangani │
├─────────────────────────────────────────────────────────┤
│ Pelunasan │ Rp 7.500.000│ Setelah project selesai, │
│ (50%) │ │ SEBELUM final files │
│ │ │ di-handover │
└─────────────────────────────────────────────────────────┘
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PAYMENT METHOD
Transfer bank ke:
• Bank: BCA
• No. Rekening: 1234567890
• Atas Nama: [Nama Lengkap]
Atau e-wallet:
• GoPay/OVO: 081234567890
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
INVOICE & DUE DATE
• Invoice dikirim via email ke [email client]
• Payment due: 7 (tujuh) hari kalender setelah invoice
• Pembayaran dianggap lunas setelah dana diterima di rekening
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LATE PAYMENT
Keterlambatan pembayaran akan dikenakan:
• Denda 2% per minggu dari jumlah yang tertunggak
• Setelah 14 hari, project akan di-pause sampai payment clear
• Setelah 30 hari, Developer berhak terminate kontrak
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
KETENTUAN PENTING
⚠️ Project TIDAK akan dimulai sampai pembayaran pertama
(DP 50%) diterima dan dikonfirmasi.
⚠️ Final deliverables (source files, akses admin, dll)
TIDAK akan di-handover sampai pembayaran lunas 100%.
⚠️ Pembayaran yang sudah diterima bersifat NON-REFUNDABLE,
kecuali jika project dibatalkan oleh Developer tanpa cause.
Red Flags dalam Payment Terms
🚩 Client minta 100% payment di akhir
→ Huge risk. Kalau tidak bayar, kamu tidak punya leverage.
🚩 "Bayar setelah dapat investor/funding"
→ Payment harus unconditional. Bukan "kalau."
🚩 Tidak ada late payment clause
→ Tidak ada consequences = tidak ada urgency untuk bayar.
🚩 Payment terms cuma verbal
→ "Deal Rp 15 juta ya" di WhatsApp tidak cukup.
🚩 "Kita sesuaikan nanti"
→ Angka harus fixed dari awal. Tidak ada "nanti."
🚩 Client keberatan dengan DP
→ Red flag besar. Professional clients expect this.
Non-Refundable: Kenapa Penting?
Clause "non-refundable" melindungi kamu dari situasi di mana client cancel di tengah jalan dan minta refund DP.
DP itu bukan cuma "uang muka" — itu adalah kompensasi untuk:
- Waktu yang sudah kamu block di calendar
- Project lain yang kamu tolak
- Effort untuk preparation dan ramp-up
"Semua pembayaran yang sudah diterima bersifat non-refundable.
Dalam hal project diterminasi oleh Client, pembayaran yang
sudah diterima menjadi kompensasi untuk waktu dan resources
yang sudah dialokasikan oleh Developer."
Quick Tips
| Situation | Recommendation |
|---|---|
| Client baru, belum kenal | Minimum 50% DP, strict payment terms |
| Client lama, sudah trust | Bisa lebih flexible, tapi tetap ada DP |
| Project besar (> 2 bulan) | Multiple milestones, payment per milestone |
| Red flags dari awal | 100% upfront atau decline project |
| Corporate client dengan PO process | Adjust due date (NET 30), tapi tetap ada DP |
Satu hal yang perlu diingat: client yang serius dan professional tidak akan keberatan dengan payment terms yang reasonable. Kalau mereka push back keras untuk DP atau payment schedule yang melindungi kamu — itu warning sign.
Bagian 5: Hal #4 - Revision Policy
<image src="unsplash" alt="editing document with red pen corrections" />
"Mas, ini tolong direvisi sedikit ya."
Kalimat yang terdengar innocent, tapi bisa jadi nightmare kalau tidak ada batasan yang jelas.
Revisi adalah bagian natural dari setiap project. Client punya hak untuk memberikan feedback dan meminta penyesuaian. Masalahnya adalah ketika "sedikit revisi" berubah menjadi redesign total, atau ketika revisi tidak pernah berhenti karena tidak ada definisi "selesai."
Tanpa revision policy yang jelas, project yang profitable bisa jadi rugi. Waktu yang harusnya untuk project lain habis untuk revisi tanpa ujung.
Apa yang Harus Didefinisikan
REVISION POLICY ELEMENTS:
1. JUMLAH REVISI
└── Berapa round revisi yang termasuk dalam harga?
2. DEFINISI "REVISI"
└── Apa yang dianggap sebagai revisi?
3. DEFINISI "BUKAN REVISI"
└── Apa yang masuk kategori change request (tambahan)?
4. TIMELINE REVISI
└── Berapa lama client punya waktu untuk submit revisi?
5. CARA SUBMIT REVISI
└── Bagaimana feedback harus disampaikan?
6. COST REVISI TAMBAHAN
└── Berapa biaya kalau melebihi kuota?
Revisi vs Change Request
Ini perbedaan krusial yang harus dipahami:
✅ REVISI (Termasuk dalam scope):
Perubahan MINOR pada deliverable yang sudah di-approve konsepnya:
├── Ganti warna dari biru ke biru yang lebih tua
├── Adjust font size dari 16px ke 18px
├── Ganti foto (dengan file yang sudah ready dari client)
├── Perbaiki typo atau update teks
├── Adjust spacing atau padding
├── Pindahkan posisi elemen (minor adjustment)
└── Ganti icon dengan icon lain yang sejenis
❌ CHANGE REQUEST (Tidak termasuk, ada biaya tambahan):
Perubahan yang mengubah KONSEP atau menambah SCOPE:
├── Tambah halaman baru yang tidak ada di scope
├── Redesign layout yang sudah di-approve
├── Tambah fitur baru (misal: multi-bahasa)
├── Ubah struktur navigasi secara signifikan
├── Ganti konsep visual setelah design approved
├── Tambah animasi kompleks yang tidak dibahas
└── Integrasi dengan sistem lain yang baru
Contoh Revision Policy
REVISION POLICY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
KUOTA REVISI YANG TERMASUK
• Design Phase: 2 (dua) rounds of revisions
• Development Phase: 2 (dua) rounds of revisions
Satu "round" = satu batch feedback yang disubmit sekaligus.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
APA YANG TERMASUK REVISI
Revisi adalah perubahan minor pada deliverable, seperti:
• Perubahan warna, ukuran font, spacing
• Penggantian gambar/foto (file disediakan Client)
• Perubahan teks/copy (bukan rewrite keseluruhan)
• Adjustment posisi elemen
• Perbaikan typo atau kesalahan ketik
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
APA YANG BUKAN REVISI (CHANGE REQUEST)
Hal berikut TIDAK termasuk revisi dan akan di-quote terpisah:
• Penambahan halaman/section baru
• Perubahan layout secara signifikan
• Penambahan fitur di luar scope awal
• Redesign elemen yang sudah di-approve sebelumnya
• Perubahan arah konsep setelah approval
Change Request akan dibuatkan quotation terpisah dan
memerlukan approval tertulis sebelum dikerjakan.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CARA SUBMIT REVISI
• Semua feedback disubmit SEKALIGUS dalam satu dokumen/email
(tidak boleh nyicil satu per satu)
• Gunakan format yang jelas:
- Halaman/section mana
- Apa yang perlu diubah
- Referensi visual jika ada
• Feedback via voice note atau chat scattered TIDAK diterima
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DEADLINE SUBMIT REVISI
• Client memiliki 5 (lima) hari kerja untuk submit feedback
setelah deliverable dikirim
• Jika tidak ada feedback dalam 5 hari, deliverable dianggap
APPROVED dan project lanjut ke tahap berikutnya
• Feedback yang datang setelah deadline akan dianggap sebagai
round revisi baru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
REVISI TAMBAHAN
Jika kuota revisi sudah habis:
• Rp 500.000 per round revisi tambahan (design)
• Rp 750.000 per round revisi tambahan (development)
• Harus disetujui dan dibayar sebelum revisi dikerjakan
Red Flags dalam Revision Policy
🚩 "Revisi sampai client puas"
→ Tidak ada definisi "puas." Ini unlimited nightmare.
🚩 "Free unlimited revisions"
→ Biasanya marketing gimmick. Ada hidden cost somewhere.
🚩 Tidak ada definisi apa itu revisi
→ Gray area yang akan dieksploitasi.
🚩 Client submit feedback nyicil setiap hari
→ Susah di-track, tidak efficient.
🚩 Tidak ada deadline untuk feedback
→ Project bisa stuck berminggu-minggu.
🚩 "Minor changes aja kok"
→ Subjektif. "Minor" versi client bisa "major" versi kamu.
Tips Mengelola Revisi
Minta Feedback Consolidated:
"Untuk efisiensi, mohon semua feedback dikumpulkan dan
dikirim dalam SATU email/dokumen. Feedback yang datang
terpisah-pisah akan saya compile dulu dan dihitung
sebagai round berikutnya."
Approval Harus Explicit:
Jangan assume silence = approval. Minta konfirmasi tertulis.
"Mohon konfirmasi approval via email dengan membalas
'APPROVED' atau 'APPROVED WITH NOTES: [notes]'.
Tanpa konfirmasi tertulis, saya belum bisa lanjut ke
tahap berikutnya."
Document Everything:
Setiap approval, setiap feedback, setiap revisi — documented. Kalau nanti ada dispute, kamu punya paper trail.
Bagian 6: Hal #5 - Intellectual Property Rights
<image src="unsplash" alt="copyright symbol intellectual property" />
Siapa yang memiliki hasil kerja? Pertanyaan simple yang jawabannya sering tidak jelas.
IP (Intellectual Property) Rights menentukan siapa yang "own" deliverables setelah project selesai. Ini bukan cuma soal file — ini soal hak untuk use, modify, sell, atau license hasil kerja.
Tanpa clause IP yang jelas, bisa terjadi situasi awkward. Client assume mereka own everything termasuk template dan tools yang kamu pakai. Atau sebaliknya, kamu assume bisa pakai design untuk client lain padahal client expect exclusivity.
Dua Model Utama
MODEL 1: FULL TRANSFER (Work for Hire)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• Setelah payment lunas, SEMUA hak jadi milik Client
• Freelancer tidak bisa pakai untuk client lain
• Termasuk source files, assets, konsep
• Client bisa modify, resell, sublicense
• Biasanya untuk custom work
MODEL 2: LICENSE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• Client dapat hak untuk USE, bukan OWN
• Freelancer retain ownership
• Bisa re-use atau re-sell ke client lain
• Biasanya untuk template atau productized service
• Ada batasan (non-transferable, single use, dll)
Untuk kebanyakan freelance work, Model 1 (Full Transfer) adalah standard. Tapi ada nuance yang perlu diperhatikan.
Yang Harus Ada dalam IP Clause
IP CLAUSE CHECKLIST:
☐ Kapan transfer terjadi (setelah payment lunas!)
☐ Apa saja yang di-transfer
☐ Apa yang TIDAK di-transfer (exclusions)
☐ Portfolio rights untuk freelancer
☐ Bagaimana dengan source files
☐ Pre-existing materials dan third-party assets
Contoh IP Clause yang Comprehensive
INTELLECTUAL PROPERTY RIGHTS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. TRANSFER OF OWNERSHIP
Upon receipt of final payment IN FULL, Developer hereby
transfers to Client all intellectual property rights to
the final deliverables as specified in Scope of Work,
including but not limited to:
• Website design dan visual layout
• Custom graphics yang dibuat khusus untuk project ini
• HTML, CSS, dan JavaScript code yang ditulis khusus
• Content structure dan information architecture
• Custom illustrations (jika ada dalam scope)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. EXCLUDED FROM TRANSFER
Developer TETAP memiliki hak atas:
• Pre-existing tools, libraries, dan code snippets yang
sudah ada sebelum project
• Open-source components (subject to their respective
licenses: MIT, GPL, Apache, dll)
• Third-party assets (fonts, stock photos, plugins)
• WordPress theme/starter yang digunakan sebagai base
• General knowledge, skills, dan techniques
• Reusable code patterns dan methodologies
Client menerima LICENSE untuk menggunakan excluded items
sebagai bagian dari deliverables, namun tidak memiliki
hak untuk extract, resell, atau sublicense secara terpisah.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. PORTFOLIO RIGHTS
Developer berhak untuk:
• Menampilkan project dalam portfolio (website, social media)
• Menggunakan screenshots untuk keperluan marketing
• Menyebut nama Client sebagai past client
• Submit ke design awards atau showcase
Client dapat meminta penundaan portfolio display selama
maksimal 60 (enam puluh) hari setelah launch untuk alasan
kompetitif, dengan pemberitahuan tertulis.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. SOURCE FILES
• Source files (Figma, PSD, AI, working files) akan
diserahkan kepada Client setelah payment lunas
• Developer akan menyimpan backup working files selama
12 (dua belas) bulan setelah project completion
• Setelah 12 bulan, Developer berhak menghapus backup
• Request untuk files setelah 12 bulan tidak dijamin
dapat dipenuhi
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. THIRD-PARTY ASSETS
Project ini mungkin menggunakan third-party assets:
• Stock photos dari [Unsplash/Pexels/dll] — subject to
their respective licenses
• Fonts dari [Google Fonts/Adobe Fonts/dll]
• Icons dari [Feather/Heroicons/dll]
• WordPress plugins
Client bertanggung jawab untuk maintain licenses yang
diperlukan untuk third-party assets setelah handover.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️ PENTING:
Transfer IP HANYA berlaku setelah pembayaran lunas 100%.
Sebelum lunas, semua intellectual property rights tetap
menjadi milik Developer.
Red Flags dalam IP
🚩 Client minta IP transfer SEBELUM payment lunas
→ No way. Ini leverage terakhir kamu.
🚩 Tidak ada portfolio rights clause
→ Kamu butuh ini untuk marketing. Negotiate!
🚩 Client minta semua source files termasuk personal templates
→ Pre-existing materials adalah milikmu.
🚩 NDA yang melarang mention pernah kerja sama
→ Terlalu restrictive. Push back.
🚩 "All work product becomes property of Client"
→ Terlalu broad. Define specifically apa yang di-transfer.
🚩 Client minta exclusive rights untuk style/approach
→ Kamu perlu bisa pakai skills dan methodology untuk client lain.
Portfolio Rights: Jangan Sampai Skip
Portfolio adalah lifeline untuk freelancer. Tanpa portfolio, susah dapat client baru.
Pastikan kamu punya hak untuk showcase work. Kalau client keberatan, negotiate:
"Saya paham concern untuk confidentiality. Bagaimana kalau
kita compromise: saya boleh tampilkan screenshots setelah
60 hari dari launch, dan saya tidak akan mention detail
bisnis atau informasi sensitif?"
Most clients akan setuju dengan compromise yang reasonable.
Bagian 7: Hal #6 - Confidentiality dan NDA
<image src="unsplash" alt="lock security confidential secret" />
NDA (Non-Disclosure Agreement) atau Confidentiality clause melindungi informasi sensitif yang di-share selama project.
Tidak semua project butuh NDA. Tapi kalau client share business plans, financial data, user information, atau hal-hal yang mereka tidak mau kompetitor tahu — NDA jadi penting.
Kapan NDA Diperlukan?
BIASANYA BUTUH NDA:
☑️ Startup yang belum launch (stealth mode)
☑️ Project yang involve data pelanggan
☑️ Informasi finansial atau strategi bisnis
☑️ Industry yang regulated (finance, healthcare)
☑️ Proprietary technology atau trade secrets
☑️ Client yang kompetisinya ketat
BIASANYA TIDAK PERLU NDA:
☐ Website company profile standar
☐ Informasi yang sudah publik
☐ Project dengan scope generic
☐ Client yang tidak handle data sensitif
One-Way vs Mutual NDA
ONE-WAY NDA:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• Hanya SATU pihak yang bound
• Biasanya: freelancer wajib jaga rahasia client
• Client tidak punya obligation balik
• Common, tapi kurang fair
MUTUAL NDA (Recommended):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• KEDUA pihak bound
• Client jaga rahasia freelancer juga
• Pricing, methodology, business info freelancer dilindungi
• Lebih fair dan balanced
Selalu push untuk Mutual NDA. Kamu juga punya informasi yang tidak mau di-share ke publik — pricing structure, client list, methodology, dll.
Contoh Confidentiality Clause
CONFIDENTIALITY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. DEFINITION OF CONFIDENTIAL INFORMATION
"Confidential Information" includes, but is not limited to:
• Business plans, strategies, dan projections
• Financial information dan pricing
• Customer atau user data
• Technical specifications, source code, architecture
• Product features yang belum dirilis
• Marketing plans dan campaigns
• Any information marked as "Confidential"
• Any information that reasonably should be understood
as confidential given its nature
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. OBLIGATIONS
Receiving Party agrees to:
• Keep Confidential Information strictly confidential
• Not disclose to any third party without written consent
• Use only for the purpose of this project
• Take reasonable measures to protect confidentiality
• Limit access to employees/contractors who need to know
• Promptly notify if breach is suspected
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. EXCLUSIONS
Confidentiality obligations DO NOT apply to information that:
• Is or becomes publicly available (not through breach)
• Was already known before disclosure
• Is independently developed without using Confidential Info
• Is received from third party without confidentiality obligation
• Is required by law to be disclosed (with prior notice)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. MUTUAL OBLIGATION
This confidentiality obligation is MUTUAL. Client agrees to:
• Keep Developer's pricing and fee structure confidential
• Not disclose Developer's business methodology
• Not share proposal or quote with third parties
• Protect Developer's proprietary tools and processes
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. DURATION
Confidentiality obligations shall survive for:
• 2 (two) years after project completion, OR
• Until information becomes publicly available (whichever first)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. RETURN OF MATERIALS
Upon project completion or termination:
• Each party shall return or destroy Confidential Information
• Upon request, provide written confirmation of destruction
• Exception: one archival copy may be retained for legal purposes
Red Flags dalam NDA
🚩 Scope terlalu broad ("semua informasi")
→ Harus spesifik apa yang confidential.
🚩 Duration unlimited ("selamanya")
→ Tidak reasonable. 2-5 tahun adalah standard.
🚩 Penalty yang tidak proporsional
→ Hati-hati dengan liquidated damages yang extreme.
🚩 Melarang mention pernah kerja sama SAMA SEKALI
→ Terlalu restrictive. Bedakan confidential info vs portfolio.
🚩 One-sided tanpa mutual clause
→ Info kamu juga perlu dilindungi.
🚩 Non-compete yang terlalu luas
→ "Tidak boleh kerja dengan kompetitor" bisa sangat limiting.
NDA vs Portfolio Rights
Ini sering bikin bingung. Bisa kok punya NDA tapi tetap bisa showcase di portfolio.
CARA BALANCE:
NDA melindungi:
├── Informasi bisnis sensitif
├── Data keuangan
├── Strategy dan plans
└── User/customer data
Portfolio boleh menampilkan:
├── Visual design (screenshots)
├── Technical achievement
├── General description of work
└── Nama client (kalau diizinkan)
JANGAN tampilkan:
├── Informasi confidential
├── Data internal
├── Backend/admin screenshots dengan real data
└── Pricing atau business metrics client
Bagian 8: Hal #7 - Communication dan Response Time
<image src="unsplash" alt="chat messages communication mobile phone" />
"Mas, kok chatnya belum dibales?" "Saya sudah kirim via email kemarin." "Oh, saya kirimnya di Telegram, bukan WhatsApp."
Communication yang berantakan adalah productivity killer. Tanpa kesepakatan yang jelas, kamu bisa overwhelmed dengan messages dari berbagai channel, atau sebaliknya — miss informasi penting karena ada di platform yang tidak kamu monitor.
Yang Perlu Disepakati
COMMUNICATION TERMS:
1. PRIMARY CHANNEL
└── Satu channel untuk semua komunikasi official
2. RESPONSE TIME EXPECTATIONS
└── Berapa lama reasonable untuk respond?
3. WORKING HOURS
└── Kapan kamu available, kapan tidak?
4. MEETING POLICY
└── Bagaimana scheduling, berapa sering?
5. EMERGENCY PROTOCOL
└── Untuk urgent matters di luar jam kerja
Contoh Communication Terms
COMMUNICATION TERMS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. PRIMARY COMMUNICATION CHANNEL
Semua komunikasi project akan dilakukan via:
📧 Email: [email Developer]
Komunikasi di luar channel ini (WhatsApp, Telegram, dll)
dianggap TIDAK OFFICIAL dan tidak mengikat secara kontraktual.
Exception: Urgent matters bisa via WhatsApp [nomor] dengan
follow-up email untuk documentation.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. RESPONSE TIME
┌────────────────────────────────────────────────────┐
│ Party │ Response Time │ Catatan │
├────────────────────────────────────────────────────┤
│ Developer │ 24 jam kerja │ Senin-Jumat │
│ Client │ 48 jam kerja │ Untuk feedback/ │
│ │ │ approval │
└────────────────────────────────────────────────────┘
Response time dihitung dalam JAM KERJA, bukan jam kalender.
Weekend dan hari libur tidak dihitung.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. WORKING HOURS
Developer available:
• Hari: Senin - Jumat
• Jam: 09:00 - 18:00 WIB
• Istirahat: 12:00 - 13:00 WIB
Di luar jam tersebut:
• Tidak ada expectation untuk response
• Messages akan dibalas pada hari kerja berikutnya
Weekend dan Hari Libur Nasional:
• Developer TIDAK available
• Kecuali emergency yang sudah disepakati
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. MEETINGS
Scheduling:
• Meeting di-schedule minimal 24 jam sebelumnya
• Via Google Calendar invite ke [email]
Frekuensi:
• Regular check-in: 1x per minggu (30 menit)
• Ad-hoc meeting: sesuai kebutuhan, max 2x per minggu
Meeting Rules:
• Harus ada agenda yang jelas sebelum meeting
• Meeting notes akan dikirim dalam 24 jam setelah meeting
• Keputusan di meeting harus dikonfirmasi via email
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. EMERGENCY CONTACT
Definisi Emergency:
• Production website down
• Security breach
• Critical bug yang block business
BUKAN Emergency:
• "Urgent" revision request
• Pertanyaan yang bisa tunggu besok
• Last-minute changes
Emergency Contact:
• WhatsApp: [nomor]
• Hanya untuk genuine emergencies
• Akan dikenakan emergency fee jika di luar jam kerja
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. PROJECT MANAGEMENT
Progress Updates:
• Weekly update setiap hari [Jumat] via email
• Include: completed tasks, upcoming tasks, blockers
File Sharing:
• Via Google Drive folder: [link]
• Atau via email attachment untuk files < 10MB
Feedback Format:
• Consolidated feedback dalam satu document
• Gunakan format: [Halaman] - [Issue] - [Suggested Change]
• Screenshots atau screen recording sangat membantu
Red Flags dalam Communication
🚩 Client expect available 24/7
→ Set boundaries dari awal. Kamu bukan employee.
🚩 Meeting tanpa agenda
→ "Let's just chat and see" = time waster.
🚩 Feedback via voice note 5 menit
→ Susah di-reference. Minta written.
🚩 Multiple channels bikin bingung
→ Satu channel primary. Yang lain tidak dianggap.
🚩 Client tidak punya dedicated contact person
→ Siapa yang decision maker? Harus jelas.
🚩 "Bisa call sebentar?" setiap hari
→ Calls eat into productive time. Protect it.
Tips Communication yang Efektif
Set Expectations dari Awal:
Di awal project, kirim email seperti ini:
Subject: Communication Guidelines untuk Project [X]
Hi [Client],
Untuk memastikan project berjalan smooth, berikut guidelines
komunikasi kita:
📧 Primary channel: Email (ini)
⏰ Response time saya: 24 jam di hari kerja
📅 Working hours: Senin-Jumat, 09:00-18:00 WIB
📞 Urgent only: WhatsApp [nomor]
Untuk feedback, mohon dikumpulkan dalam satu email dengan
format yang clear ya.
Let me know if you have questions!
Protect Your Time:
Meeting adalah necessary evil. Minimize dengan:
- Tanya: "Bisa via email tidak?" sebelum setuju meeting
- Set durasi fixed: "30 menit untuk discuss X"
- Selalu minta agenda sebelumnya
- Follow up dengan email summary
Written Trail:
Apapun yang dibahas verbal, confirm via email:
"Hi [Client],
Following up dari call tadi. Untuk konfirmasi, kita sepakat:
1. [Point A]
2. [Point B]
3. [Point C]
Mohon reply 'Confirmed' kalau sudah sesuai.
Thanks!"
Ini melindungi kamu kalau nanti ada dispute tentang "yang dibahas di meeting."
Bagian 9: Hal #8 - Termination Clause
Tidak ada yang mulai project dengan niat untuk berhenti di tengah jalan. Tapi kenyataannya, hal itu bisa terjadi. Client kehabisan budget, bisnis pivot, atau simply berubah pikiran. Di sisi lain, kamu juga mungkin perlu withdraw karena alasan personal atau karena client yang terlalu toxic.
Tanpa termination clause yang jelas, situasi ini bisa jadi ugly. Siapa yang bayar apa? Apa yang terjadi dengan deliverables? Bagaimana dengan waktu yang sudah diinvest?
Termination clause adalah "prenup" dalam kontrak freelance. Tidak ada yang mau memakainya, tapi kalau dibutuhkan, sangat krusial.
Skenario Termination
TERMINATION SCENARIOS:
1. CLIENT TERMINATES (Without Cause)
└── Client berubah pikiran, budget cut, pivot bisnis
Bukan salah freelancer
2. CLIENT TERMINATES (With Cause)
└── Freelancer tidak perform sesuai agreement
Breach of contract dari freelancer
3. FREELANCER TERMINATES (Without Cause)
└── Alasan personal, sakit, tidak bisa lanjut
Bukan salah client
4. FREELANCER TERMINATES (With Cause)
└── Client tidak bayar, harassment, breach of contract
Client yang bermasalah
5. MUTUAL TERMINATION
└── Kedua pihak setuju untuk stop
Biasanya paling smooth
Contoh Termination Clause
TERMINATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. TERMINATION BY CLIENT (Without Cause)
Client dapat menghentikan kontrak ini kapan saja dengan
memberikan pemberitahuan tertulis. Dalam hal ini:
• Client membayar semua pekerjaan yang sudah selesai
sampai tanggal terminasi
• Deposit/DP yang sudah dibayar bersifat NON-REFUNDABLE
• Developer menyerahkan semua deliverables yang sudah
selesai dalam 7 (tujuh) hari kerja
• Developer berhak atas Kill Fee sebesar 25% dari sisa
nilai kontrak yang belum dikerjakan
Contoh perhitungan:
├── Total kontrak: Rp 20.000.000
├── Sudah dibayar (DP 50%): Rp 10.000.000
├── Pekerjaan selesai: 60%
├── Client terminate
├── Yang harus dibayar: 60% × Rp 20 juta = Rp 12.000.000
├── Kill fee: 25% × (40% × Rp 20 juta) = Rp 2.000.000
└── Total due: Rp 12 juta + Rp 2 juta - Rp 10 juta = Rp 4.000.000
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. TERMINATION BY CLIENT (With Cause)
Jika Developer melakukan breach of contract yang material
dan tidak memperbaiki dalam 14 (empat belas) hari setelah
pemberitahuan tertulis:
• Client dapat menghentikan kontrak dengan segera
• Developer mengembalikan pembayaran untuk pekerjaan
yang tidak diselesaikan
• Developer menyerahkan semua pekerjaan yang sudah selesai
• Tidak ada Kill Fee
Material breach termasuk:
├── Tidak memenuhi deadline tanpa alasan yang reasonable
├── Deliverables yang jauh di bawah standard profesional
├── Pelanggaran confidentiality
└── Abandonment (menghilang tanpa komunikasi)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. TERMINATION BY DEVELOPER (Without Cause)
Developer dapat menghentikan kontrak dengan memberikan
pemberitahuan tertulis 14 (empat belas) hari sebelumnya:
• Developer mengembalikan pembayaran untuk milestone
yang belum diselesaikan
• Developer menyerahkan semua pekerjaan yang sudah selesai
• Client tidak boleh menggunakan pekerjaan yang belum
selesai tanpa pembayaran proporsional
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. TERMINATION BY DEVELOPER (With Cause)
Developer dapat menghentikan kontrak dengan segera jika
Client melakukan breach material:
• Non-payment yang melebihi 14 hari dari due date
• Harassment, abuse, atau komunikasi yang tidak profesional
• Scope creep yang terus-menerus tanpa kompensasi
• Pelanggaran terms kontrak oleh Client
Dalam hal ini:
• Semua pembayaran untuk pekerjaan yang sudah selesai
harus dibayar dalam 7 hari
• Developer berhak menahan deliverables sampai payment clear
• Developer berhak atas Kill Fee 25%
• Outstanding invoices menjadi immediately due
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. EFFECT OF TERMINATION
Setelah termination:
• Confidentiality obligations tetap berlaku
• Payment obligations untuk completed work tetap berlaku
• IP transfer hanya untuk pekerjaan yang sudah dibayar
• Kedua pihak mengembalikan materials milik pihak lain
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. CURE PERIOD
Sebelum termination with cause, pihak yang melakukan breach
diberikan kesempatan untuk memperbaiki (cure) dalam waktu:
• 14 hari untuk breach yang bisa diperbaiki
• Segera untuk breach yang tidak bisa diperbaiki
(harassment, data breach, dll)
Kill Fee: Kenapa Penting?
Kill fee sering di-skip padahal melindungi kamu dari situasi tidak adil.
KENAPA KILL FEE PENTING:
Ketika client cancel project, kamu sudah:
├── Block waktu di calendar untuk project ini
├── Menolak project lain yang datang
├── Invest waktu untuk onboarding dan ramp-up
├── Mungkin sudah hire subcontractor
└── Mental shift ke "project mode"
Kill fee = kompensasi untuk opportunity cost ini.
STANDARD RATE:
├── 15-25% dari remaining project value
├── Atau flat fee yang disepakati di awal
└── Bisa di-waive untuk long-term client sebagai goodwill
Red Flags dalam Termination
🚩 Tidak ada termination clause sama sekali
→ Kalau ada masalah, tidak ada guidance.
🚩 Client bisa terminate tanpa konsekuensi
→ Kamu yang menanggung semua risiko.
🚩 Tidak ada cure period
→ Langsung terminate tanpa kesempatan memperbaiki.
🚩 Tidak jelas apa yang terjadi dengan deliverables
→ Recipe for dispute.
🚩 "Refund semua jika tidak puas"
→ Terlalu risky. Work yang sudah done ya harus dibayar.
Bagian 10: Hal #9 - Liability dan Warranty
Bagian ini sering di-skip karena terasa "too legal." Tapi ini penting untuk melindungi kamu dari risiko yang tidak proporsional.
Liability clause membatasi seberapa besar tanggung jawab kamu kalau ada masalah. Warranty clause mendefinisikan apa yang kamu jamin dan untuk berapa lama.
Kenapa Perlu Limitation of Liability?
Bayangkan skenario ini:
SKENARIO NIGHTMARE:
• Kamu bikin website e-commerce untuk client
• Website live, semua berjalan normal
• 3 bulan kemudian, ada bug yang bikin payment gagal
• Client claim rugi Rp 500 juta dari lost sales
• Client mau sue kamu untuk Rp 500 juta
Pertanyaannya: fair tidak kalau kamu yang dibayar Rp 20 juta
harus tanggung rugi Rp 500 juta?
JAWABANNYA: Tidak fair. Dan ini kenapa perlu liability cap.
Contoh Liability dan Warranty Clause
LIABILITY AND WARRANTY
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. LIMITATION OF LIABILITY
Total liability Developer di bawah kontrak ini TIDAK AKAN
MELEBIHI total fee yang dibayarkan Client untuk project ini.
Developer TIDAK bertanggung jawab untuk:
• Indirect, incidental, atau consequential damages
• Lost profits, lost revenue, atau lost business opportunities
• Lost data (kecuali karena gross negligence Developer)
• Third-party claims terhadap Client
• Damages yang disebabkan oleh modifikasi Client
• Hosting, server, atau third-party service failures
• Force majeure (bencana alam, perang, pandemi, dll)
• Issues yang muncul dari informasi yang salah dari Client
Contoh yang TIDAK ditanggung Developer:
├── Client rugi sales karena website down (hosting issue)
├── Client kena hack karena tidak update WordPress
├── Client kehilangan customer karena desain "tidak menarik"
└── Kompetitor client copy design (bukan tanggung jawab Developer)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. WARRANTY
Developer menjamin bahwa:
☑️ Pekerjaan akan dilakukan secara profesional dan
sesuai standard industri
☑️ Deliverables akan substantially conform dengan
spesifikasi yang disepakati dalam Scope of Work
☑️ Developer memiliki hak untuk memberikan services ini
☑️ Deliverables tidak akan dengan sengaja melanggar
intellectual property pihak ketiga
☑️ Code tidak akan mengandung malware, virus, atau
backdoor yang disengaja
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. WARRANTY PERIOD
Durasi: 30 (tiga puluh) hari kalender dari tanggal final delivery
Coverage selama warranty period:
• Bug atau error yang menghalangi core functionality
• Issues yang jelas merupakan defect dari development
• Developer akan memperbaiki dalam waktu reasonable
Yang TIDAK termasuk warranty:
• Issues dari modifikasi oleh Client atau pihak ketiga
• Third-party plugin/service yang berubah atau discontinued
• Request fitur baru (bukan bug fix)
• Browser atau OS updates yang keluar setelah delivery
• Content changes yang dilakukan Client
• Hosting atau server issues
Setelah warranty period:
• Support dan maintenance dikenakan biaya terpisah
• Rate: Rp [X] per jam, atau paket maintenance bulanan
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. DISCLAIMER
Kecuali yang secara eksplisit dinyatakan di atas, Developer
TIDAK memberikan warranty lain, baik express maupun implied,
termasuk namun tidak terbatas pada:
• Implied warranty of merchantability
• Fitness for a particular purpose
• Non-infringement
• Bahwa deliverables akan bebas dari semua errors
• Bahwa deliverables akan beroperasi tanpa interruption
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. CLIENT RESPONSIBILITIES
Client bertanggung jawab untuk:
• Menjaga keamanan credentials dan access
• Regular backup data
• Update software dan security patches setelah handover
• Compliance dengan regulasi yang berlaku (GDPR, dll)
• Renewal license third-party services
• Hosting dan domain maintenance
Red Flags dalam Liability
🚩 Tidak ada liability cap
→ Kamu bisa di-sue untuk jumlah tak terbatas.
🚩 Warranty tanpa batas waktu
→ "Lifetime warranty" = nightmare.
🚩 Client expect free support selamanya
→ Warranty ≠ free maintenance forever.
🚩 Liable untuk hal di luar kontrol
→ Hosting down, third-party service berubah = bukan salahmu.
🚩 "Developer menjamin website tidak akan pernah error"
→ Impossible. Jangan sign ini.
Tips
Standard Liability Cap:
Liability cap = Total project fee
Kalau project Rp 20 juta, maksimal liability ya Rp 20 juta.
Ini standard industri dan fair untuk kedua pihak.
Warranty Period yang Reasonable:
• 14 hari — minimum, untuk project kecil
• 30 hari — standard, paling umum
• 60-90 hari — untuk project besar atau enterprise client
Lebih dari 90 hari? Itu bukan warranty, itu maintenance contract.
Harus ada fee terpisah.
Bagian 11: Hal #10 - Dispute Resolution
Semoga tidak pernah terjadi, tapi kalau ada dispute, bagaimana menyelesaikannya?
Tanpa clause dispute resolution, default-nya adalah pengadilan. Dan percayalah, kamu tidak mau ke sana. Mahal, lama, dan stressful. Untuk project Rp 20 juta, biaya lawyer bisa lebih besar dari nilai project-nya.
Dispute resolution clause memberikan jalur yang lebih reasonable untuk menyelesaikan perselisihan.
Tahapan Dispute Resolution
ESCALATION PATH:
┌─────────────────────────────────────────────────────────┐
│ LEVEL 1: GOOD FAITH NEGOTIATION │
│ ├── Kedua pihak coba selesaikan secara langsung │
│ ├── Diskusi baik-baik, cari win-win solution │
│ └── Timeline: 14-30 hari │
└─────────────────────────────────────────────────────────┘
│
▼ Jika gagal
┌─────────────────────────────────────────────────────────┐
│ LEVEL 2: MEDIATION │
│ ├── Pihak ketiga netral membantu fasilitasi │
│ ├── Keputusan TIDAK binding │
│ ├── Lebih murah dari arbitration │
│ └── Masing-masing tanggung biaya sendiri │
└─────────────────────────────────────────────────────────┘
│
▼ Jika gagal
┌─────────────────────────────────────────────────────────┐
│ LEVEL 3: ARBITRATION │
│ ├── Pihak ketiga netral membuat keputusan │
│ ├── Keputusan BINDING (final) │
│ ├── Lebih cepat dan murah dari pengadilan │
│ └── Bisa pilih arbiter yang paham industri │
└─────────────────────────────────────────────────────────┘
│
▼ Last resort
┌─────────────────────────────────────────────────────────┐
│ LEVEL 4: LITIGATION (Pengadilan) │
│ ├── Proses formal di pengadilan │
│ ├── Mahal, lama, stressful │
│ ├── Untuk kasus besar atau yang kompleks │
│ └── Semoga tidak sampai sini │
└─────────────────────────────────────────────────────────┘
Contoh Dispute Resolution Clause
DISPUTE RESOLUTION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. GOOD FAITH NEGOTIATION
Jika terjadi perselisihan terkait kontrak ini, kedua pihak
sepakat untuk terlebih dahulu berusaha menyelesaikan secara
musyawarah dan mufakat dalam waktu 30 (tiga puluh) hari
kalender sejak pemberitahuan tertulis mengenai dispute.
Selama periode ini, kedua pihak akan:
• Berkomunikasi dengan itikad baik
• Berusaha mencari solusi yang dapat diterima kedua pihak
• Tidak mengambil tindakan hukum
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. MEDIATION
Jika negosiasi tidak berhasil, kedua pihak sepakat untuk
menempuh mediasi sebelum menempuh jalur hukum lainnya.
• Mediasi akan dilakukan di [Kota]
• Mediator dipilih berdasarkan kesepakatan kedua pihak
• Masing-masing pihak menanggung biaya sendiri
• Keputusan mediasi tidak mengikat secara hukum
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. GOVERNING LAW
Kontrak ini diatur oleh dan ditafsirkan sesuai dengan
hukum negara Republik Indonesia.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. JURISDICTION
Setiap proses hukum akan dilakukan di pengadilan yang
berwenang di [Kota], Indonesia.
Untuk nilai sengketa di bawah Rp 500.000.000 (Lima Ratus
Juta Rupiah), dapat menggunakan mekanisme Penyelesaian
Sengketa Sederhana sesuai PERMA No. 2 Tahun 2015.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. FEES AND COSTS
Dalam penyelesaian sengketa, pihak yang kalah akan
menanggung biaya hukum yang reasonable dari pihak yang
menang, termasuk namun tidak terbatas pada biaya pengacara.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. INJUNCTIVE RELIEF
Tidak ada ketentuan dalam clause ini yang mencegah salah
satu pihak untuk mengajukan injunctive relief (penetapan
sementara) ke pengadilan untuk:
• Pelanggaran Intellectual Property
• Breach of Confidentiality
• Kerugian yang tidak dapat diperbaiki dengan ganti rugi
Small Claims Court di Indonesia
Untuk project kecil, ada opsi yang lebih accessible:
PENYELESAIAN SENGKETA SEDERHANA:
Berdasarkan PERMA No. 2 Tahun 2015:
Syarat:
├── Nilai sengketa maksimal Rp 500 juta
├── Bukan sengketa tanah
├── Pembuktian sederhana
└── Para pihak diketahui alamatnya
Keuntungan:
├── Proses lebih cepat (max 25 hari)
├── Biaya lebih murah
├── Tidak wajib pakai pengacara
└── Keputusan bersifat final
Cocok untuk dispute freelance yang nilainya tidak terlalu besar.
Red Flags dalam Dispute Resolution
🚩 Tidak ada dispute resolution clause
→ Default langsung ke pengadilan = mahal.
🚩 Jurisdiction di negara lain
→ Kalau client luar negeri minta jurisdiction di negaranya,
kamu yang repot kalau ada dispute.
🚩 Wajib arbitration di Singapore/Hong Kong
→ Mahal banget. Push untuk Indonesia.
🚩 "All disputes go directly to court"
→ Tidak ada step awal yang lebih murah.
🚩 Tidak ada prevailing party clause
→ Kalau menang tapi tetap tanggung biaya sendiri, pyrrhic victory.
Bagian 12: Penutup - Checklist dan Next Steps
Kita sudah bahas 10 hal penting yang harus ada dalam kontrak freelance. Sekarang, bagaimana mengimplementasikannya?
Master Checklist
Print atau save checklist ini. Setiap kali review atau bikin kontrak, pastikan semua item ter-cover:
FREELANCE CONTRACT CHECKLIST
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IDENTITAS DAN DASAR
☐ Nama lengkap dan alamat kedua pihak
☐ Tanggal kontrak
☐ Nama project
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. SCOPE OF WORK
☐ Deskripsi project
☐ List deliverables spesifik
☐ Spesifikasi teknis
☐ Apa yang TIDAK termasuk (exclusions)
☐ Assets yang dibutuhkan dari client
2. TIMELINE & MILESTONES
☐ Start date (setelah DP diterima)
☐ Milestones dengan deliverables
☐ Review periods dengan deadline
☐ Final delivery date
☐ Dependencies dan assumptions
☐ Clause untuk delay dari client
3. PAYMENT TERMS
☐ Total project fee (angka jelas)
☐ Payment schedule
☐ Payment method
☐ Invoice dan due date terms
☐ Late payment consequences
☐ Non-refundable clause
4. REVISION POLICY
☐ Jumlah revisi yang termasuk
☐ Definisi revisi vs change request
☐ Deadline submit feedback
☐ Cara submit feedback
☐ Cost revisi tambahan
5. INTELLECTUAL PROPERTY
☐ Kapan transfer terjadi
☐ Apa yang di-transfer
☐ Exclusions (pre-existing, third-party)
☐ Portfolio rights
☐ Source files
6. CONFIDENTIALITY
☐ Definisi confidential information
☐ Obligations kedua pihak (mutual)
☐ Exclusions
☐ Duration
7. COMMUNICATION
☐ Primary channel
☐ Response time expectations
☐ Working hours
☐ Meeting policy
8. TERMINATION
☐ Termination by client (with/without cause)
☐ Termination by developer (with/without cause)
☐ Kill fee
☐ What happens to deliverables
☐ Cure period
9. LIABILITY & WARRANTY
☐ Liability cap
☐ Exclusions dari liability
☐ Warranty scope
☐ Warranty period
☐ Disclaimer
10. DISPUTE RESOLUTION
☐ Negotiation first
☐ Mediation
☐ Governing law
☐ Jurisdiction
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SIGNATURES
☐ Tanda tangan Developer
☐ Tanda tangan Client
☐ Tanggal
☐ Materai (jika diperlukan)
Cara Introduce Kontrak ke Client
Banyak freelancer awkward untuk introduce kontrak. Ini cara framing yang lebih smooth:
❌ JANGAN BILANG:
"Sebelum mulai, saya mau kirim kontrak dulu ya."
→ Terdengar defensive atau curiga
✅ BILANG SEPERTI INI:
"Untuk memastikan kita aligned dan project berjalan smooth,
saya biasanya kirim project agreement yang outline scope,
timeline, dan terms. Ini juga melindungi Bapak/Ibu sebagai
client — kalau ada apa-apa, semuanya sudah terdokumentasi.
Saya kirim draft-nya untuk di-review, ya? Kalau ada yang
perlu di-adjust, kita bisa diskusikan."
Framing-nya: ini adalah professional standard yang benefit kedua pihak, bukan tanda tidak percaya.
Kapan Perlu Konsultasi Legal?
Kontrak template cukup untuk kebanyakan project. Tapi pertimbangkan konsultasi lawyer kalau:
KONSULTASI LEGAL KALAU:
├── Project value di atas Rp 50-100 juta
├── Client adalah perusahaan besar/corporate
├── Project involve regulated industry (finance, healthcare)
├── Ada requirement khusus yang tidak standard
├── Client minta kamu sign kontrak mereka yang kompleks
├── Ada international element (client luar negeri)
└── Kamu merasa ada yang "off" tapi tidak sure apa
Biaya konsultasi lawyer sekitar Rp 500rb - 2jt untuk review kontrak. Worth it untuk project besar.
Mulai dari yang Simple
Tidak perlu kontrak 20 halaman untuk project pertama. Start simple:
PROGRESSION:
Project Kecil (< Rp 5 juta):
├── Scope of Work yang clear
├── Payment terms (bisa 100% upfront untuk project kecil)
├── Basic timeline
└── Via email agreement bisa cukup
Project Menengah (Rp 5-20 juta):
├── Kontrak 3-5 halaman
├── Cover 10 hal penting
├── Formal agreement dengan tanda tangan
Project Besar (> Rp 20 juta):
├── Kontrak comprehensive
├── Mungkin perlu review legal
├── Semua detail di-specify
Yang penting konsisten. Apapun project size-nya, selalu ada written agreement.
Closing Thoughts
"Kontrak bukan tanda tidak percaya. Kontrak adalah tanda profesionalisme."
Freelancer yang punya kontrak proper dipersepsi lebih professional. Client yang serius justru appreciate ini — karena mereka tahu kamu bukan amateur yang bisa di-exploit.
Dan yang paling penting: kontrak melindungi kamu. Dari client yang ghosting, dari scope creep yang endless, dari dispute yang tidak perlu. Worth the effort untuk setup di awal.
Action Items:
MULAI MINGGU INI:
1. ☐ Download atau buat template kontrak basic
2. ☐ Customize dengan informasi kamu (nama, rekening, dll)
3. ☐ Untuk project berikutnya, GUNAKAN kontrak
4. ☐ Iterate dan improve berdasarkan pengalaman
5. ☐ Simpan semua kontrak dengan organized
Semoga artikel ini membantu. Protect yourself, kamu sudah kerja keras untuk sampai di sini. Jangan biarkan hasil kerja kamu tidak terlindungi hanya karena tidak ada kontrak.
Good luck! 🚀
