# Noble Dev > Noble Dev is the studio of Bastian, a solo Full Stack Developer based in Indonesia. He builds business websites, landing pages, web apps, mobile apps, MVPs, automations and ongoing maintenance for clients in Indonesia and worldwide, and works directly with the client from planning to launch. ## Key facts - Owner and only developer: Bastian (Full Stack Developer, Indonesia) - Services: websites, landing pages, web apps, mobile apps, MVPs, automations, maintenance - Languages: Indonesian (Bahasa Indonesia) and English - Contact: info@nobledevco.com or WhatsApp +6281264323032 (the chat on the site opens WhatsApp) - Pricing: quoted per project after a short conversation about the need; no fixed price list - Social: https://instagram.com/basstian, https://www.threads.net/@basstian # Bahasa Indonesia Pages in this language: https://nobledevco.com/id ## Bastian: Full Stack Developer · Indonesia Noble Dev dipimpin oleh Bastian, Full Stack Developer berbasis di Indonesia yang membangun website bisnis, landing page, dashboard, web app, mobile app, dan MVP terarah. Melalui Noble Dev, Bastian membantu bisnis kecil, brand jasa, kursus, bimbel, dan personal brand membangun kehadiran digital yang lebih kuat dengan website yang jelas, profesional, dan mudah dinavigasi. Pendekatannya sederhana: website yang baik tidak hanya terlihat modern. Website juga harus membantu orang memahami bisnis kamu, percaya pada penawaran kamu, dan menghubungi kamu tanpa kebingungan. Alih-alih menambah kompleksitas yang tidak perlu, Noble Dev berfokus pada struktur rapi, fitur praktis, layout responsif, dan keputusan development yang sesuai dengan scope project. - **Full Stack Development**: Support frontend, backend, database, dan deployment untuk project web yang utuh. - **Website Business-Focused**: Struktur halaman dan messaging dirancang berdasarkan penawaran, audience, dan jalur konversi kamu. - **Eksekusi Rapi & Reliable**: Proses development yang tenang, terorganisir, dan komunikatif dari planning sampai launch. ## Atau pilih layanan ↓ - **website**: Website bisnis yang bikin orang percaya sebelum menghubungimu. - **landing page**: Satu halaman, satu tujuan: bikin pengunjung mengirim pesan. - **dashboard**: Admin dashboard untuk mengelola data, pesanan, atau jadwal tanpa spreadsheet berantakan. - **web app**: Aplikasi web yang mengikuti alur kerja bisnismu, bukan sebaliknya. - **aplikasi mobile**: MVP aplikasi mobile untuk menguji ide sebelum investasi besar. - **otomasi**: Menyambungkan tools dan API supaya pekerjaan berulang jalan sendiri. - **maintenance**: Update, perbaikan, dan pemantauan setelah website jalan. ## Tech stack - **Frontend**: React, Next.js, HTML, CSS, Tailwind CSS - **Backend**: Node.js, Express, FastAPI - **Database**: MongoDB, PostgreSQL, Firebase - **Deployment**: Vercel, Railway, Supabase - **Tools**: GitHub, Figma, Canva, Notion - **AI / API**: OpenAI API, Third-party APIs, Workflow form, Sistem notifikasi ## Pertanyaan umum ### Aku lihat kamu belum punya client nyata. Bagaimana aku tahu kamu bisa benar-benar deliver? Itu pertanyaan yang sangat wajar. Aku masih membangun client base, jadi aku tidak ingin berpura-pura punya daftar panjang hasil client yang sebenarnya belum aku miliki. Yang bisa aku tunjukkan adalah project portfolio yang benar-benar berjalan, cara berpikir yang jelas, implementasi yang rapi, dan proses kerja yang transparan. Kamu bisa melihat live demo, memahami bagaimana produknya disusun, dan menilai kualitasnya sebelum memutuskan untuk bekerja sama. Aku lebih memilih membangun trust lewat pekerjaan yang terlihat dan komunikasi yang jujur daripada memakai testimonial palsu. ### Kamu menggunakan AI untuk membangun project. Apakah itu berarti kualitasnya lebih rendah? Tidak. AI adalah bagian dari workflow aku, bukan pengganti judgment, planning, testing, atau tanggung jawab. Aku menggunakan AI untuk bergerak lebih cepat, mengeksplorasi solusi, membuat draft yang lebih rapi, dan mempercepat pekerjaan development yang repetitif. Tetapi keputusan akhir, struktur, testing, dan quality control tetap aku tangani sendiri. Tujuannya bukan mengirim code random hasil AI. Tujuannya adalah membangun produk yang bekerja dengan lebih cepat tanpa memangkas bagian yang penting. ### Kenapa aku harus hire kamu dibanding agency? Agency bisa menjadi pilihan yang baik untuk project besar dengan banyak bagian yang bergerak. Tetapi untuk banyak small business, agency juga bisa berarti biaya lebih tinggi, komunikasi lebih lambat, dan terlalu banyak layer antara client dan orang yang benar-benar mengerjakan project. Dengan aku, kamu berbicara langsung dengan orang yang membangun project kamu. Prosesnya lebih sederhana, komunikasinya lebih jelas, dan pekerjaan bisa bergerak lebih cepat karena tidak ada handoff yang tidak perlu. Jika project kamu membutuhkan solusi web yang lean, praktis, dan dibangun dengan rapi, bekerja dengan solo developer yang fokus bisa menjadi pilihan yang masuk akal. ### Bagaimana kalau aku belum tahu persis apa yang aku butuhkan? Itu normal. Kamu tidak perlu datang dengan brief yang sudah sempurna. Kamu bisa mulai dengan menjelaskan bisnis kamu, masalah yang sedang dihadapi, apa yang ingin diperbaiki, dan outcome seperti apa yang ingin dicapai. Dari sana, aku bisa membantu memperjelas apakah kamu membutuhkan business website, landing page, web app, API, dashboard, atau sesuatu yang lebih sederhana. Langkah pertama bukan tentang langsung membeli. Langkah pertama adalah memahami arah yang tepat. ### Apakah kamu bisa menangani design dan development sekaligus? Bisa, selama masih dalam scope yang tepat. Aku bisa membantu dengan struktur website, arah UI, responsive frontend, logic backend, setup database, API development, dan deployment. Untuk sebagian besar project web skala kecil hingga menengah, itu cukup untuk bergerak dari ide menjadi produk yang berjalan. Jika sebuah project membutuhkan branding tingkat lanjut, ilustrasi kompleks, arsitektur enterprise, atau pengerjaan besar dengan banyak orang, aku akan jujur jika bagian tersebut sebaiknya ditangani oleh specialist atau tim yang lebih besar. ### Project seperti apa yang kamu bangun? Aku fokus pada project web praktis yang membantu bisnis terlihat lebih profesional, beroperasi lebih baik, atau mengubah ide menjadi produk yang bisa digunakan. Ini mencakup business website, landing page, full stack web application, admin dashboard, REST API, sistem berbasis database, dan integrasi tool sederhana. Aku tidak mencoba menawarkan semua jenis layanan digital. Aku fokus pada area di mana aku bisa membangun produk yang bersih, berguna, dan benar-benar berjalan. ### Berapa lama biasanya pengerjaan project? Tergantung scope project. Business website atau landing page sederhana biasanya bisa bergerak lebih cepat dibanding full stack web application dengan authentication, logic database, fitur dashboard, dan integrasi API. Sebelum development dimulai, aku akan memperjelas scope, timeline, dan prioritas agar kamu tahu apa yang bisa diharapkan. Aku lebih memilih timeline yang jelas daripada janji yang terlalu umum. ### Apa yang terjadi setelah project launch? Setelah launch, aku bisa memberikan walkthrough dasar, menjelaskan bagaimana project bekerja, dan membantu proses handoff agar kamu memahami apa yang sudah dibangun. Tergantung projectnya, ongoing support, perbaikan kecil, improvement, atau maintenance juga bisa didiskusikan. Tujuan aku bukan hanya mem-publish sesuatu lalu menghilang. Handoff harus cukup jelas agar kamu memahami produk akhirnya dan tahu langkah berikutnya. ### Bagaimana kalau sesuatu berada di luar skill atau scope kamu saat ini? Aku akan memberi tahu kamu dari awal. Aku tidak ingin menjanjikan sesuatu yang tidak bisa aku deliver dengan benar. Jika sebuah fitur terlalu kompleks, berada di luar kemampuan aku saat ini, atau lebih baik ditangani oleh specialist lain, aku akan mengatakannya sebelum project dimulai atau sebelum fitur tersebut disetujui. Kejujuran adalah bagian dari proses kerja. Itu melindungi project kamu, budget kamu, dan reputasi aku. ## Studi kasus ### Klinik Cahaya Medika Page: https://nobledevco.com/id/case-studies/klinik-cahaya-medika Live demo: https://cahaya-medika-nu.vercel.app/ Landing page satu halaman untuk klinik keluarga, dengan panel admin ringan agar pemilik klinik bisa mengubah jadwal dokter dan info layanan sendiri, tanpa menunggu developer untuk perubahan rutin. Klinik Cahaya Medika adalah studi kasus ilustratif, dibuat untuk menunjukkan proses kerja dari dokumen perencanaan sampai implementasi teknis. Ini tidak ditampilkan sebagai project klien. Scope: 9 screen, 5 endpoint admin, 1 role admin. Topics: Landing page publik, Panel admin, Row Level Security, On-demand ISR. **Jadwal dokter, info layanan, dan status buka-tutup sering hidup terpisah dari website: di kepala pemilik, di grup WhatsApp, atau di catatan yang tidak sempat diperbarui.** - Jadwal dokter cepat basi: Setiap perubahan jadwal butuh menghubungi developer dan menunggu, sementara pasien sudah datang berdasarkan info lama. - Info layanan tidak konsisten: Layanan atau harga yang berubah di lapangan tidak otomatis tercermin di website. - Pasien menghubungi manual: Tanpa status buka/tutup yang jelas, resepsionis menerima telepon hanya untuk mengonfirmasi jam praktik. - Tidak ada jejak perubahan: Kalau ada data yang salah, tidak jelas siapa mengubah apa dan kapan. **Satu sistem, dua sisi dengan peran yang jelas. Pengunjung mendapat informasi yang selalu akurat, pemilik mendapat kendali untuk menjaganya tetap akurat, tanpa harus paham kode.** - Indikator buka/tutup: Status dihitung otomatis dari jadwal dokter, tampil di hero dan footer, tidak pernah basi. - Upload foto dokter: Foto yang jelas dan konsisten membangun kepercayaan sebelum pasien menelepon. - Panel admin self-service: Edit jadwal, layanan, dan profil dokter dari browser, tanpa menyentuh kode. - Pratinjau real-time: Setiap layar edit menampilkan tampilan publik sebelum admin menekan simpan. - Riwayat perubahan: Setiap perubahan tercatat otomatis sebagai audit log: siapa, apa, dan kapan. - Frontend (Next.js 15 · App Router · Tailwind): Halaman publik, form admin, tabel jadwal, dan pratinjau real-time. - Backend API (Route Handlers · Zod · requireAdmin()): Route handler tipis: validasi, guard admin, panggil service. - Database (Supabase Postgres · RLS · RPC): Row Level Security sebagai otorisasi utama, write atomic lewat RPC. - Deployment (Vercel (sin1) · Supabase SG): Region eksplisit untuk latensi pengguna Indonesia, revalidation on-demand. ### EduCentre Page: https://nobledevco.com/id/case-studies/educentre Live demo: https://educentre-apps.vercel.app/ Konsep web app mandiri untuk membantu bisnis kursus mengelola siswa, pengajar, kelas, absensi, pembayaran, dan visibilitas orang tua melalui satu sistem dashboard yang tenang dan rapi. EduCentre adalah project portfolio mandiri untuk menunjukkan product thinking, struktur interface, dan kemampuan full-stack. Ini tidak ditampilkan sebagai project klien. Scope: 4 role, 4 dashboard desktop, 6 layar ponsel. Topics: Dashboard berbasis role, Sistem pendidikan, Admin panel, Konsep full-stack. **Data siswa, jadwal, absensi, tagihan, dan komunikasi orang tua sering terpisah di spreadsheet, chat app, catatan kertas, dan reminder manual.** - Data siswa tersebar: Identitas, status, dan catatan belajar membutuhkan satu sumber yang konsisten. - Absensi sulit dipantau: Pengajar dan admin memerlukan workflow pencatatan yang seragam. - Orang tua kurang mendapat visibilitas: Progres dan pembayaran tidak seharusnya bergantung pada chat. - Pekerjaan harian terasa manual: Jadwal, laporan, tagihan, dan pengumuman perlu saling terhubung. **Semua pengguna bekerja di produk yang sama, sementara hierarki informasi dan action menyesuaikan tanggung jawab harian mereka.** - Akses berbasis role: Dashboard berbeda menjaga setiap pengguna tetap fokus. - Absensi: Pencatatan konsisten mendukung tindak lanjut antar-role. - Ringkasan tagihan: Status pembayaran aktif jelas bagi siswa dan orang tua. - Pengumuman: Informasi penting tetap terlihat di dalam sistem. - Frontend (React · Next.js · Tailwind): Halaman role, dashboard, tabel, form, status badge, dan layout responsif. - Backend API (FastAPI · Node.js): Autentikasi, permission, kelas, absensi, tagihan, dan pengumuman. - Database (MongoDB · PostgreSQL): User, role, jadwal, data siswa, pembayaran, dan progres belajar. - Deployment (Vercel · Railway): Konfigurasi environment, hosting frontend, API, dan monitoring. ## Blog ### Sebenarnya Berapa Lama Waktu Bikin Website atau Web App? Page: https://nobledevco.com/id/blog/how-long-to-build-a-website Published: 2026-09-05 "Berapa lama pengerjaannya?" biasanya jadi pertanyaan pertama setelah "berapa biayanya?" — dan jawaban jujurnya: ini lebih ditentukan oleh keputusan daripada oleh coding. #### Perkiraan timeline per jenis proyek **Landing page (1 halaman, tanpa CMS).** 3–7 hari setelah konten dan arah desain fix. Sebagian besar waktu di sini habis untuk copywriting dan visual, bukan development. **Website company profile (5–10 halaman, pakai CMS).** 2–4 minggu. Ini termasuk struktur, konten tiap halaman, setup CMS supaya klien bisa edit sendiri nanti, dan satu-dua putaran revisi. **MVP atau web app sederhana (login, database, satu alur inti).** 4–8 minggu. Di sinilah scope benar-benar berpengaruh — app booking dengan satu alur beda proyeknya dengan yang ada pembayaran, notifikasi, dan role admin. **Platform custom atau sistem multi-role.** 2–4+ bulan, sering lebih lama. Banyak tipe user, integrasi, dan model data yang lebih kompleks berarti lebih banyak yang harus dirancang, dibangun, dan diuji dengan benar. Rentang waktu ini mengasumsikan tim kecil yang fokus dan konsisten mengerjakan — bukan satu freelancer yang membagi waktu ke lima klien sekaligus. #### Apa yang sebenarnya bikin proyek molor **Konten yang belum jelas atau sering berubah.** Developer sering menunggu copy, gambar, atau data produk. Website dengan teks placeholder bisa "hampir selesai" selama berminggu-minggu kalau konten aslinya tak kunjung datang. **Proses pengambilan keputusan yang lambat.** Kalau setiap warna tombol atau struktur halaman harus disetujui komite, timeline melebar — bukan karena pengerjaannya lambat, tapi karena menunggu keputusannya yang lambat. **Penambahan scope di tengah jalan.** "Bisa tambah member area gak?" adalah permintaan yang wajar, tapi kalau ditambahkan setelah timeline sudah disepakati, biasanya deadline mundur atau ada bagian lain yang harus dikorbankan. **Ketergantungan pihak ketiga.** Approval payment gateway, transfer domain, dan akses API dari vendor lain sering di luar kendali developer — dan ini sumber keterlambatan yang sering tidak diperhitungkan dari awal. **Feedback yang dicicil vs. sekaligus.** Menerima lima putaran feedback kecil yang tersebar selama lima minggu jauh lebih lama dibanding satu putaran feedback yang jelas setelah draft pertama selesai. #### Cara menjaga timeline tetap realistis 1. Siapkan konten — copy, gambar, logo, halaman penting — *sebelum* development mulai, bukan sambil jalan. 2. Sepakati scope secara tertulis sebelum pengerjaan dimulai, dan perlakukan penambahan sebagai diskusi terpisah, bukan tambahan diam-diam. 3. Tunjuk satu orang untuk memberi persetujuan final, alih-alih feedback melewati banyak stakeholder. 4. Tanyakan di awal bagian timeline mana yang tergantung padamu (konten, approval) dan mana yang tergantung developer (pengerjaan, testing) — supaya keterlambatan terlihat lebih awal, bukan pas minggu launch. Kalau kamu punya proyek dan mau timeline yang realistis, bukan estimasi generik, [chat kami di WhatsApp](/api/whatsapp?intent=contact&lang=id) dan ceritakan apa yang mau kamu bangun. ### Cara Memilih Web Developer atau Agency di Indonesia Page: https://nobledevco.com/id/blog/how-to-choose-a-web-developer-indonesia Published: 2026-08-05 Kebanyakan orang memilih web developer di Indonesia dengan membandingkan harga, bukan kemampuan — karena harga adalah satu-satunya hal yang paling mudah dibandingkan. Masalahnya, penawaran termurah dan termahal bisa sama-sama datang dari orang yang belum pernah benar-benar merilis produk yang jalan. Ini yang sebenarnya membedakan keduanya. #### Jangan cuma lihat screenshot portfolio Screenshot hanya menunjukkan desain, bukan apakah sistemnya benar-benar berfungsi. Sebelum deal, minta link yang live — bukan screenshot, bukan file Figma — dan coba pakai langsung dari HP kamu. Portfolio yang isinya mockup rapi tanpa satupun link live itu tanda bahaya, bukan bukti kemampuan. - Apakah website-nya loading cepat di koneksi 4G biasa? - Apakah form-nya benar-benar bisa submit dan mengirim konfirmasi? - Kalau itu web app, bisakah kamu login dan pakai fitur utamanya sendiri? #### Pertanyaan yang membongkar developer berisiko **"Yang benar-benar mengerjakan ini siapa — kamu sendiri, atau orang lain?"** Banyak agency menjual portfolio developer senior lalu project-nya dikerjakan junior atau freelancer yang belum pernah mereka ajak kerja sama. Tanyakan siapa nama yang benar-benar mengerjakan project-mu. **"Kalau saya mau ganti developer di tengah jalan, gimana?"** Developer yang serius akan menyerahkan kode yang bersih dan terdokumentasi, yang bisa dipindahkan ke tempat lain. Kalau jawabannya samar-samar, atau kodenya sengaja dibuat sulit dipindahkan, itu tandanya mereka sedang menjaga leverage atas kamu. **"Apa saja yang tidak termasuk dalam harga ini?"** Minta ini secara tertulis sebelum mulai. Sumber pembengkakan budget yang paling umum bukan dari harga penawaran — tapi dari semua hal yang diam-diam tidak termasuk di dalamnya: revisi, hosting, domain, perbaikan bug setelah launch. **"Apakah saya bisa memiliki kode dan domainnya sendiri?"** Beberapa penawaran murah menyimpan domain atau akun hosting atas nama developer-nya. Ini tidak masalah selama hubungan kerja baik-baik saja, tapi jadi masalah besar begitu tidak. #### Red flag yang perlu diwaspadai - Harga pasti diberikan sebelum ada diskusi soal apa yang sebenarnya dibutuhkan website-nya. - Tidak ada kontrak tertulis atau dokumen scope — cuma chat dan kesepakatan lisan. - Enggan memberikan akses admin ke domain, hosting, atau CMS milikmu sendiri setelah project dibayar lunas. - Portfolio isinya cuma landing page padahal kamu butuh web app sungguhan dengan database dan login — itu keahlian yang berbeda. #### Ciri-ciri developer yang bagus Developer yang layak dipekerjakan akan bertanya lebih banyak dari yang kamu tanyakan di percakapan pertama — soal siapa user-nya, apa yang perlu dilakukan website-nya, dan apa yang terjadi setelah launch. Mereka akan jujur soal berapa budget dan timeline yang realistis untuk scope spesifikmu, meskipun angkanya lebih tinggi dari harapanmu, bukan asal kasih angka biar kamu bilang "iya." Kalau kamu mau minta pendapat kedua atas penawaran yang sudah kamu terima, atau belum yakin cara menentukan scope kebutuhanmu, [chat kami di WhatsApp](/api/whatsapp?intent=contact&lang=id) — kami dengan senang hati kasih pandangan jujur sebelum kamu deal dengan siapapun. ### MVP vs. Prototype vs. Landing Page: Mana yang Perlu Dibuat Dulu? Page: https://nobledevco.com/id/blog/mvp-vs-prototype-vs-landing-page Published: 2026-07-15 Banyak diskusi awal dengan founder dimulai dengan kalimat yang sama: "Saya butuh MVP." Sepuluh menit kemudian, biasanya ternyata yang dibutuhkan adalah hal lain — dan membangun yang salah duluan membuang waktu dan budget. #### Tiga hal ini, dijelaskan sederhana **Landing page** — satu halaman yang menjelaskan penawaran dan menangkap minat (email, chat WhatsApp, pendaftaran). Tidak ada aplikasi di baliknya. Tugasnya menjawab satu pertanyaan: *apakah ada yang peduli dengan ide ini?* **Prototype** — desain yang bisa diklik dan terlihat nyata, mensimulasikan pengalaman produk tanpa fungsi sungguhan di baliknya. Tugasnya menjawab: *apakah alur ini masuk akal buat user asli, sebelum kita menulis kode backend?* **MVP (Minimum Viable Product)** — produk sungguhan yang berfungsi, dengan fitur secukupnya untuk memberi nilai nyata ke user asli dan menghasilkan data penggunaan yang nyata. Tugasnya menjawab: *apakah orang benar-benar akan memakai ini, dan membayar untuk itu, berulang kali?* #### Kenapa urutannya penting Masing-masing lebih murah dan lebih cepat dari yang berikutnya, dan masing-masing dirancang untuk menghentikan ide yang salah sebelum kamu mengeluarkan lebih banyak biaya: 1. Landing page bisa memvalidasi permintaan dengan biaya ratusan ribu rupiah dan waktu seminggu. 2. Prototype bisa memvalidasi alur dan mendapat persetujuan investor atau stakeholder tanpa menyentuh database. 3. MVP adalah tempat uang dan waktu sungguhan dihabiskan — layak dilakukan setelah kamu sudah punya sinyal bahwa orang menginginkannya. Langsung loncat ke MVP karena "terdengar lebih serius" adalah cara paling umum founder menghabiskan budget berlebihan untuk versi pertama yang salah. #### Cara cepat memutuskan - Kalau kamu belum yakin ada yang menginginkan ide ini sama sekali → **landing page** dulu. - Kalau orang menginginkannya tapi kamu belum yakin soal pengalaman/alurnya → **prototype** berikutnya. - Kalau alurnya sudah tervalidasi dan kamu perlu membuktikan orang akan benar-benar memakai dan membayar → **MVP**. #### Yang biasanya kami sarankan Kebanyakan project yang datang ke kami dengan bilang "kami butuh MVP" sebenarnya lebih baik mulai satu langkah sebelumnya. Langkahnya lebih singkat, lebih murah, dan langsung membentuk apa yang seharusnya ada di dalam MVP — jadi tidak ada yang terbuang di build "sungguhan" nanti. Kalau kamu belum yakin dari ketiganya mana yang cocok untuk situasimu, [ceritakan apa yang ingin kamu bangun di WhatsApp](/api/whatsapp?intent=contact&lang=id) — kami bantu cari tahu titik mulai yang tepat sebelum satu baris kode pun ditulis. ### Berapa Biaya Bikin Website di Indonesia? Page: https://nobledevco.com/id/blog/website-cost-indonesia Published: 2026-07-22 Kalau kamu sudah tanya beberapa developer atau agency "berapa harga bikin website?", kemungkinan besar jawabannya sangat bervariasi — mulai dari ratusan ribu rupiah sampai puluhan juta. Bukan berarti ada yang menaikkan harga seenaknya — perbedaan itu mencerminkan scope yang benar-benar berbeda di balik kata yang sama: "website." #### Apa yang sebenarnya mempengaruhi harga Tiga hal ini paling menentukan angkanya: - **Desain custom vs. template.** Landing page dari template bisa selesai cepat. Desain yang benar-benar custom — layout sendiri, ilustrasi, detail interaksi — butuh waktu desain yang serius sebelum satu baris kode pun ditulis. - **Konten statis vs. sistem yang sesungguhnya.** Website company profile dengan form kontak adalah project yang berbeda dari dashboard dengan login, role, dan database di baliknya. Yang kedua itu web app, bukan sekadar website, meskipun tampilannya mirip dari luar. - **Siapa yang maintain setelah launch.** Sebagian penawaran sudah termasuk hosting, monitoring, dan update kecil selama setahun. Sebagian lain hanya kasih file lalu selesai. Pastikan kamu tahu kamu dapat yang mana. #### Kisaran budget (Indonesia, 2026) Ini gambaran umum, bukan penawaran resmi — setiap project tetap butuh diskusi scope tersendiri. **Landing page / website bisnis kecil** — halaman utama, beberapa section, form kontak, mobile-friendly, dasar-dasar SEO. Ini titik masuk untuk sebagian besar usaha kecil yang butuh kehadiran online yang kredibel. **Website bisnis multi-halaman** — beberapa halaman, mungkin blog atau case study, desain lebih custom, integrasi seperti WhatsApp atau notifikasi email. **Web app / dashboard / MVP** — akun user, database, logika bisnis spesifik untuk operasional kamu (booking, tagihan, inventory, portal siswa/orang tua, dll). Di titik ini perbandingan harga "website" sudah tidak relevan lagi — kamu sedang membuat software, bukan sekadar halaman. #### Pertanyaan yang perlu ditanyakan sebelum deal 1. Apakah harga sudah termasuk revisi, atau setiap perubahan dihitung terpisah? 2. Siapa pemilik kode dan domain setelah project selesai? 3. Kalau website bermasalah setelah launch, apakah itu ditanggung atau biaya tambahan? 4. Apakah harga tetap, atau "penambahan kecil" selama pengerjaan bisa mengubah harga? #### Jawaban jujurnya Kalau ada yang langsung kasih angka pasti sebelum memahami apa yang sebenarnya ingin kamu jalankan secara online, anggap itu perkiraan awal, bukan penawaran final. Cara tercepat untuk dapat angka yang akurat adalah diskusi singkat tentang apa yang website ini perlu *lakukan* — bukan cuma tampilannya seperti apa. Kalau kamu mau jawaban jujur untuk kebutuhan spesifikmu, [chat kami di WhatsApp](/api/whatsapp?intent=contact&lang=id) dan ceritakan apa yang ingin kamu bangun — kami akan kasih tahu apa adanya masuk ke tier yang mana. ### Maintenance Website: Apa yang Sebenarnya Terjadi Setelah Launch Page: https://nobledevco.com/id/blog/website-maintenance-after-launch Published: 2026-08-12 Banyak penawaran berhenti di hari launch, dan banyak klien mengira pekerjaannya juga selesai di situ. Padahal tidak. Website yang tidak pernah disentuh lagi lama-lama jadi lebih lambat, kurang aman, dan lebih susah di-update — walaupun dari luar terlihat tidak ada yang berubah. #### Apa saja yang sebenarnya dicakup maintenance **Update keamanan.** Framework, plugin, dan library terus-menerus dapat patch. Melewatkan update selama setahun di website WordPress, misalnya, adalah salah satu cara paling umum website jadi diretas atau di-deface — bukan lewat serangan canggih, tapi lewat celah keamanan yang sudah diketahui publik dan tidak pernah ditambal. **Hosting dan uptime.** Server butuh dipantau. Lonjakan traffic, sertifikat SSL yang expired, dan disk yang diam-diam penuh semuanya bisa menyebabkan downtime yang baru disadari setelah ada customer komplain website-nya mati. **Backup yang benar-benar bisa dipulihkan.** Punya backup dan punya backup yang *sudah diuji* itu dua hal berbeda. Waktu paling buruk untuk sadar backup-mu rusak atau sudah tiga bulan lama adalah tepat setelah ada yang rusak. **Request konten dan perbaikan kecil.** Ganti foto, update harga, betulkan typo, ubah field form — semua ini tidak butuh pengerjaan ulang penuh, tapi butuh orang yang punya akses dan konteks untuk melakukannya dengan aman. **Perubahan dependency dan platform.** Payment gateway mengubah API-nya. Browser menghentikan dukungan perilaku lama. Website yang dibuat dua tahun lalu dan tidak pernah disentuh bisa diam-diam berhenti berfungsi dengan cara yang baru disadari saat proses checkout error. #### Apa yang terjadi kalau dilewatkan Awalnya tidak terjadi apa-apa — dan justru itu yang membuatnya mudah diabaikan. Sampai akhirnya celah keamanan di plugin dieksploitasi, atau sertifikat expired malam Jumat, atau developer yang membuat website aslinya sudah tidak bisa dihubungi dan tidak ada orang lain yang paham kodenya. Biaya dari mengabaikan maintenance biasanya tidak terlihat sampai tiba-tiba sangat terlihat dan sangat mendesak. #### Apakah kamu benar-benar butuh paket maintenance? - **Website company profile yang jarang berubah** — biasanya cukup patch keamanan sesekali dan monitoring uptime, tidak perlu retainer bulanan. - **Website dengan blog, form, atau update konten rutin** — lebih baik ada orang dengan akses tetap yang bisa melakukan perubahan kecil dengan cepat. - **Web app dengan login, pembayaran, atau data user** — butuh perhatian berkelanjutan. Ini kategori di mana sikap "nanti kalau rusak baru diurus" bisa jadi mahal dengan cepat. #### Pertanyaan sebelum tanda tangan apapun 1. Apakah paket maintenance mencakup patch keamanan, atau cuma perubahan konten? 2. Seberapa sering backup dilakukan, dan apakah proses restore-nya pernah benar-benar diuji? 3. Berapa lama waktu respons kalau ada yang rusak jam 11 malam di akhir pekan? 4. Siapa yang punya akses admin ke hosting, domain, dan codebase — dan apa yang terjadi kalau kamu pindah provider nanti? Kalau kamu belum yakin apakah setup website-mu sekarang butuh maintenance rutin, atau kamu mewarisi website yang sudah lama tidak disentuh siapapun, [chat kami di WhatsApp](/api/whatsapp?intent=contact&lang=id) dan kami akan kasih penilaian jujur soal kondisinya sekarang. ### Website atau Web App: Bisnismu Sebenarnya Butuh yang Mana? Page: https://nobledevco.com/id/blog/website-vs-web-app-which-one Published: 2026-09-05 Banyak founder datang minta dibuatkan "website" padahal yang sebenarnya mereka butuhkan adalah web app — atau sebaliknya. Salah pilih di sini bukan cuma buang-buang budget, tapi bisa berarti bangun ulang dari nol enam bulan kemudian. #### Perbedaan intinya **Website** menyajikan informasi. Orang datang, baca, lalu pergi — atau mengisi form kontak. Isinya kurang lebih sama untuk setiap pengunjung. **Web app** melakukan sesuatu *untuk* tiap user. Ada login, menyimpan data per akun, dan tampilannya berubah tergantung siapa yang memakainya — dashboard, sistem booking, platform pemesanan. Tidak ada yang "lebih baik". Keduanya menyelesaikan masalah berbeda, dan banyak bisnis pada akhirnya butuh dua-duanya. #### Tanda-tanda website saja sudah cukup - Kamu terutama menjelaskan bisnismu dan membangun kepercayaan sebelum orang menghubungi atau membeli lewat saluran lain. - "Produk"-mu adalah layanan yang disampaikan offline atau lewat telepon, bukan sesuatu yang dipakai di dalam website itu sendiri. - Konten berubah sesekali (layanan, harga, portofolio) tapi tidak ada interaksi berkelanjutan per user. - Kamu butuh sesuatu yang cepat live dan belum tahu apakah model bisnisnya nanti butuh lebih dari itu. Kalau ini kondisimu, website yang dibangun dengan baik dan call-to-action yang jelas akan lebih efektif daripada web app rumit yang belum kamu butuhkan. #### Tanda-tanda kamu butuh web app - Customer perlu login dan melihat sesuatu yang spesifik untuk *mereka* — pesanan mereka, booking mereka, data mereka. - Ada alur kerja berulang yang terjadi di dalam website itu sendiri: booking, checkout, mengajukan request, melacak status. - Kamu perlu mengelola user, role, atau permission (customer vs. staff vs. admin). - Nilai yang kamu jual adalah tool-nya itu sendiri, bukan sekadar informasi tentangnya. #### Jalan tengah: website dengan fitur mirip app Banyak bisnis sebenarnya tidak butuh web app penuh — mereka hanya butuh website dengan satu bagian interaktif spesifik yang ditempel: form booking yang mengecek ketersediaan real, portal klien sederhana, form order yang terhubung ke stok. Ini seringkali cara termurah untuk mendapat 80% manfaat web app tanpa biaya membangunnya dari nol. #### Cara praktis mengambil keputusan Tanya: "Kalau customer perlu melakukan hal yang *sama* setiap kali — lihat data mereka sendiri, mengulang transaksi, melacak status — itu masalah web app. Kalau mereka kebanyakan hanya perlu *tahu sesuatu lalu mengambil satu tindakan* (telepon, chat, beli sekali) — itu masalah website." Kalau kamu belum yakin idemu masuk kategori yang mana, [chat kami di WhatsApp](/api/whatsapp?intent=contact&lang=id) dan ceritakan apa yang mau kamu bangun — kami akan kasih jawaban jujur mana yang benar-benar cocok, bahkan kalau itu berarti merekomendasikan opsi yang lebih murah. # English Pages in this language: https://nobledevco.com/en ## Bastian: Full Stack Developer · Indonesia Noble Dev is led by Bastian, a Full Stack Developer based in Indonesia who builds business websites, landing pages, dashboards, web apps, mobile apps, and focused MVPs. Through Noble Dev, Bastian helps small businesses, service brands, courses, tutoring businesses, and personal brands build a stronger digital presence with websites that feel clear, professional, and easy to navigate. His approach is simple: a good website should not only look modern. It should help people understand your business, trust your offer, and contact you without confusion. Instead of adding unnecessary complexity, Noble Dev focuses on clean structure, practical features, responsive layouts, and development decisions that fit the actual project scope. - **Full Stack Development**: Frontend, backend, database, and deployment support for complete web projects. - **Business-Focused Websites**: Page structure and messaging are planned around your offer, your audience, and your conversion path. - **Clean & Reliable Execution**: A calm, organized development process with clear communication from planning to launch. ## Or pick a service ↓ - **websites**: A business website that makes people trust you before they get in touch. - **landing pages**: One page, one goal: getting visitors to send a message. - **dashboards**: An admin dashboard to manage data, orders, or schedules without messy spreadsheets. - **web apps**: A web app that follows your workflow, not the other way around. - **mobile apps**: A mobile app MVP to test your idea before a big investment. - **automations**: Connecting tools and APIs so repetitive work runs by itself. - **maintenance**: Updates, fixes, and monitoring after the site is live. ## Tech stack - **Frontend**: React, Next.js, HTML, CSS, Tailwind CSS - **Backend**: Node.js, Express, FastAPI - **Database**: MongoDB, PostgreSQL, Firebase - **Deployment**: Vercel, Railway, Supabase - **Tools**: GitHub, Figma, Canva, Notion - **AI / API**: OpenAI API, Third-party APIs, Form workflows, Notification systems ## Common questions ### You have no real clients yet. How do I know you can actually deliver? That's a fair question. I'm still building my client base, so I don't want to pretend I have a long list of client results that I don't have. What I can show you instead is real, working portfolio projects, clear thinking, clean implementation, and a transparent process. You can open the live demos, see how each product is put together, and judge the quality before deciding to work with me. I'd rather earn trust through visible work and honest communication than through fake testimonials. ### You use AI to build things. Does that mean the quality will be lower? No. AI is part of my workflow, not a replacement for judgment, planning, testing, or responsibility. I use AI to move faster, explore solutions, write cleaner drafts, and speed up repetitive development work. But the final decisions, the structure, the testing, and the quality control are still mine. The goal isn't to ship random AI-generated code. It's to deliver working products faster without cutting the parts that matter. ### Why should I hire you instead of an agency? An agency can be a good choice for large projects with many moving parts. But for many small businesses, it can also mean higher costs, slower communication, and too many layers between the client and the person doing the work. With me, you talk directly to the person building your project. The process is simpler, the communication is clearer, and the work moves faster because there are no unnecessary handoffs. If your project needs a lean, practical, well-built web solution, working with a focused solo developer can make a lot of sense. ### What if I don't know exactly what I need yet? That's normal. You don't need to arrive with a perfect brief. Start by telling me about your business, the problem you're facing, what you want to improve, and the outcome you're hoping for. From there, I can help work out whether you need a business website, a landing page, a web app, an API, a dashboard, or something simpler. The first step isn't about buying right away. It's about finding the right direction. ### Can you handle both design and development? Yes, within the right scope. I can help with website structure, UI direction, responsive frontend, backend logic, database setup, API development, and deployment. For most small to medium web projects, that's enough to take you from idea to a working product. If a project needs advanced branding, complex illustration, enterprise architecture, or a large multi-person build, I'll be honest about what a specialist or a bigger team should handle. ### What kind of projects do you build? I focus on practical web projects that help businesses look more professional, run better, or turn an idea into a product people can use. That includes business websites, landing pages, full stack web applications, admin dashboards, REST APIs, database-backed systems, and simple tool integrations. I don't try to offer every digital service out there. I stick to the areas where I can build clean, useful products that actually work. ### How long does a project usually take? It depends on the scope. A simple business website or landing page usually moves faster than a full stack web application with authentication, database logic, dashboard features, and API integrations. Before development starts, I'll clarify the scope, timeline, and priorities so you know what to expect. I'd rather give you a clear timeline than a vague promise. ### What happens after the project is launched? After launch, I can give you a basic walkthrough, explain how the project works, and help with the handoff so you understand what's been built. Depending on the project, ongoing support, small fixes, improvements, or maintenance can also be discussed. My goal isn't to publish something and disappear. The handoff should be clear enough that you understand the final product and know what to do next. ### What if something is outside your current skill or scope? I'll tell you upfront. I don't want to promise something I can't deliver properly. If a feature is too complex, beyond what I can do right now, or better handled by another specialist, I'll say so before the project starts or before that feature is approved. Honesty is part of how I work. It protects your project, your budget, and my reputation. ## Case studies ### Klinik Cahaya Medika Page: https://nobledevco.com/en/case-studies/klinik-cahaya-medika Live demo: https://cahaya-medika-nu.vercel.app/ A one-page website for a family clinic, with a lightweight admin panel so the owner can update doctor schedules and service info on their own, without waiting on a developer for routine changes. Klinik Cahaya Medika is an illustrative case study, built to show my process from planning documents through to technical implementation. It is not presented as a client project. Scope: 9 screens, 5 admin endpoints, 1 admin role. Topics: Public landing page, Admin panel, Row Level Security, On-demand ISR. **Doctor schedules, service info, and open/closed status often live apart from the website: in the owner's head, in a WhatsApp group, or in notes that never get updated.** - Doctor schedules go stale fast: Every schedule change means contacting a developer and waiting, while patients show up based on outdated info. - Service info is inconsistent: Services or prices that change on the ground aren't automatically reflected on the website. - Patients call to check manually: Without a clear open/closed status, reception takes calls just to confirm opening hours. - No trace of what changed: When some data is wrong, it's unclear who changed what, and when. **One system, two sides with clear roles. Visitors get information that stays accurate, and the owner gets the control to keep it that way, without needing to understand code.** - Open/closed indicator: Status is calculated automatically from doctor schedules and shown in the hero and footer, so it's never stale. - Doctor photo upload: Clear, consistent photos build trust before a patient ever calls. - Self-service admin panel: Edit schedules, services, and doctor profiles from the browser, without touching code. - Real-time preview: Every edit screen shows the public view before the admin presses save. - Change history: Every change is logged automatically as an audit trail: who, what, and when. - Frontend (Next.js 15 · App Router · Tailwind): Public pages, admin forms, the schedule table, and real-time preview. - Backend API (Route Handlers · Zod · requireAdmin()): Thin route handlers: validation, admin guard, then call the service. - Database (Supabase Postgres · RLS · RPC): Row Level Security as the primary authorization layer, atomic writes through RPC. - Deployment (Vercel (sin1) · Supabase SG): An explicit region for low latency in Indonesia, with on-demand revalidation. ### EduCentre Page: https://nobledevco.com/en/case-studies/educentre Live demo: https://educentre-apps.vercel.app/ A self-initiated web app concept to help tutoring centres manage students, educators, classes, attendance, payments, and parent visibility from one calm, tidy dashboard system. EduCentre is a self-initiated portfolio project to show product thinking, interface structure, and full-stack ability. It is not presented as a client project. Scope: 4 roles, 4 desktop dashboards, 6 phone screens. Topics: Role-based dashboard, Education system, Admin panel, Full-stack concept. **Student data, schedules, attendance, billing, and parent communication are often split across spreadsheets, chat apps, paper notes, and manual reminders.** - Student data is scattered: Identity, status, and learning records need one reliable source. - Attendance is hard to track: Educators and admins need a consistent recording workflow. - Parents lack visibility: Progress and payment updates shouldn't depend on chat messages. - Daily work feels manual: Schedules, reports, billing, and notices need to stay connected. **Everyone works in the same product, while the information hierarchy and available actions adapt to their daily responsibilities.** - Role-based access: Different dashboards keep every user focused. - Attendance: Consistent tracking supports follow-up across roles. - Billing summary: Active payment status is clear to students and parents. - Announcements: Important updates stay visible inside the system. - Frontend (React · Next.js · Tailwind): Role pages, dashboards, tables, forms, status badges, and responsive layouts. - Backend API (FastAPI · Node.js): Authentication, permissions, classes, attendance, billing, and announcements. - Database (MongoDB · PostgreSQL): Users, roles, schedules, student records, payments, and learning progress. - Deployment (Vercel · Railway): Environment configuration, frontend hosting, API hosting, and monitoring. ## Blog ### How Long Does It Actually Take to Build a Website or Web App? Page: https://nobledevco.com/en/blog/how-long-to-build-a-website Published: 2026-09-05 "How long will it take?" is usually the first question after "how much does it cost?" — and the honest answer is: it depends more on decisions than on code. #### Rough timelines by project type **Landing page (1 page, no CMS).** 3–7 days once content and design direction are locked. Most of the time here goes into copy and visuals, not development. **Company profile website (5–10 pages, CMS-backed).** 2–4 weeks. This includes structure, content for each page, a CMS setup so the client can edit things later, and a round or two of revisions. **MVP or simple web app (auth, database, one core workflow).** 4–8 weeks. This is where scope really matters — a booking app with one flow is a different project from one with payments, notifications, and admin roles. **Custom platform or multi-role system.** 2–4+ months, often longer. Multiple user types, integrations, and more complex data models mean more to design, build, and test properly. These ranges assume a dedicated small team working consistently — not a single freelancer splitting time across five clients. #### What actually slows a project down **Unclear or changing content.** Developers often wait on copy, images, or product data. A site with placeholder text can sit "almost done" for weeks if the real content never arrives. **Decision-making bottlenecks.** If every button color or page structure needs sign-off from a committee, timelines stretch — not because building is slow, but because waiting is. **Scope creep mid-build.** "Can we also add a members area?" is a reasonable request, but adding it after the timeline is set usually means either the deadline slips or something else gets cut. **Third-party dependencies.** Payment gateway approvals, domain transfers, and API access from other vendors are often outside the developer's control — and they're a common source of delay nobody accounts for upfront. **Feedback in batches vs. all at once.** Getting five rounds of small feedback spread over five weeks takes far longer than getting one clear round of feedback after the first full draft. #### How to keep your timeline realistic 1. Have your content — copy, images, logo, key pages — ready *before* development starts, not during. 2. Agree on scope in writing before the build begins, and treat additions as a separate discussion, not a quiet add-on. 3. Assign one person to give final sign-off, instead of routing feedback through multiple stakeholders. 4. Ask upfront which parts of the timeline depend on you (content, approvals) versus the developer (build, testing) — so delays are visible early, not on launch week. If you have a project in mind and want a realistic timeline instead of a generic estimate, [message us on WhatsApp](/api/whatsapp?intent=contact&lang=en) and tell us what you're building. ### How to Choose a Web Developer or Agency in Indonesia Page: https://nobledevco.com/en/blog/how-to-choose-a-web-developer-indonesia Published: 2026-08-05 Most people choosing a web developer in Indonesia are comparing prices, not capability — because price is the only thing that's easy to compare. The problem is that the cheapest quote and the most expensive one can both come from people who have never shipped a working product. Here's what actually separates them. #### Look past the portfolio screenshots Screenshots show design, not whether the thing works. Before you commit, ask to see a live link — not a screenshot, not a Figma file — and actually use it on your phone. A portfolio full of polished mockups with no live links is a warning sign, not proof of skill. - Does the site load fast on a normal 4G connection? - Do forms actually submit and send you a confirmation? - If it's a web app, can you log in and use the core feature yourself? #### Questions that expose the risky ones **"Who will actually build this — you, or someone else?"** Agencies routinely sell a senior developer's portfolio and then hand the project to a junior or a freelancer they've never worked with before. Ask who's on the project by name. **"What happens if I want to change developers halfway through?"** A serious developer hands over clean, documented code you can move elsewhere. If the answer is vague, or the code is deliberately hard to hand off, that's leverage they're keeping over you. **"What's not included in this price?"** Get this in writing before you start. The most common source of budget blowups isn't the quote — it's everything quietly excluded from it: revisions, hosting, a domain, post-launch bug fixes. **"Can I own the code and the domain?"** Some cheaper offers keep the domain or hosting account under the developer's name. That's fine while the relationship is good and a real problem the moment it isn't. #### Red flags worth walking away from - A firm price given before any conversation about what the site actually needs to do. - No written contract or scope document — just a chat thread and a verbal agreement. - Reluctance to give you admin access to your own domain, hosting, or CMS once the project is paid for. - A portfolio that's all landing pages when you're asking for a real web app with a database and logins — those are different skill sets. #### What good looks like A developer worth hiring will ask you more questions than you ask them in the first conversation — about who your users are, what the site needs to do, and what happens after launch. They'll be upfront about what a realistic budget and timeline look like for your specific scope, even if that number is higher than you hoped, rather than quoting whatever gets you to say yes. If you want a second opinion on a quote you've already received, or you're not sure how to scope what you need, [message us on WhatsApp](/api/whatsapp?intent=contact&lang=en) — we're happy to give you an honest read before you commit to anyone. ### MVP vs. Prototype vs. Landing Page: Which Do You Need First? Page: https://nobledevco.com/en/blog/mvp-vs-prototype-vs-landing-page Published: 2026-07-15 A lot of first conversations with founders start the same way: "I need an MVP." Ten minutes in, it usually turns out they need something else entirely — and building the wrong one first wastes both time and budget. #### The three, defined plainly **Landing page** — a single page that explains an offer and captures interest (an email, a WhatsApp message, a signup). No app behind it. Its job is to answer one question: *does anyone care about this?* **Prototype** — a clickable, realistic-looking design that simulates the product experience without real functionality underneath. Its job is to answer: *does this flow make sense to real users, before we write backend code?* **MVP (Minimum Viable Product)** — a real, working product with just enough functionality to deliver actual value to real users and generate real usage data. Its job is to answer: *will people actually use this, and pay for it, repeatedly?* #### Why the order matters Each one is cheaper and faster than the next, and each one is designed to kill a bad idea before you spend more on it: 1. A landing page can validate demand for a few hundred thousand rupiah and a week. 2. A prototype can validate the flow and get investor or stakeholder buy-in without touching a database. 3. An MVP is where real money and months go in — worth doing once you already have signal that people want it. Skipping straight to an MVP because it "sounds more serious" is the single most common way founders overspend on the wrong first version. #### A quick way to decide - If you're not sure anyone wants this at all → **landing page** first. - If people want it but you're unsure about the experience/flow → **prototype** next. - If the flow is validated and you need to prove people will actually use and pay for it → **MVP**. #### What we usually recommend Most projects that come to us saying "we need an MVP" are better served starting one step earlier. It's a shorter, cheaper step, and it directly shapes what the MVP should even include — so nothing in the "real" build gets thrown away later. If you're not sure which of the three fits your situation, [tell us what you're building on WhatsApp](/api/whatsapp?intent=contact&lang=en) — we'll help you figure out the right starting point before any code gets written. ### How Much Does a Website Cost in Indonesia? Page: https://nobledevco.com/en/blog/website-cost-indonesia Published: 2026-07-22 If you've asked a few developers or agencies "how much for a website?", you've probably gotten wildly different answers — anywhere from a few hundred thousand rupiah to well over a hundred million. That range isn't developers padding quotes; it reflects genuinely different scopes hiding behind the same word: "website." #### What actually drives the price Three things move the number more than anything else: - **Custom design vs. a template.** A templated landing page is fast to ship. A fully custom design — your own layout, illustrations, and interaction details — takes real design hours before a single line of code is written. - **Static content vs. a real system.** A brochure site with a contact form is a different project from a dashboard with logins, roles, and a database behind it. The second one is a web app, not a website, even if it looks similar from the outside. - **Who's maintaining it after launch.** Some quotes include a year of hosting, monitoring, and small updates. Others hand you the files and disappear. Ask which one you're getting. #### Rough budget tiers (Indonesia, 2026) These are directional, not quotes — every project still needs a scope conversation. **Landing page / small business site** — a home page, a few sections, a contact form, mobile-friendly, decent SEO basics. This is the entry point for most small businesses that just need a credible online presence. **Multi-page business website** — several pages, maybe a blog or case studies section, more custom design work, integrations like WhatsApp or email notifications. **Web app / dashboard / MVP** — user accounts, a database, business logic specific to your operation (bookings, billing, inventory, student/parent portals, etc.). This is where "website" pricing stops being a useful comparison — you're commissioning software, not a page. #### Questions worth asking before you commit 1. Does the quote include revisions, or is every change billed separately? 2. Who owns the code and the domain once the project ends? 3. What happens if the site goes down after launch — is that covered, or extra? 4. Is the price fixed, or will "small additions" during the build change it? #### The honest answer If someone gives you a firm number before understanding what you're actually trying to run online, treat it as a starting estimate, not a quote. The fastest way to get an accurate number is a short conversation about what the site needs to *do* — not just look like. If you want a straight answer for your specific case, [message us on WhatsApp](/api/whatsapp?intent=contact&lang=en) and describe what you're trying to build — we'll tell you honestly which tier it falls into. ### Website Maintenance: What Actually Happens After Launch Page: https://nobledevco.com/en/blog/website-maintenance-after-launch Published: 2026-08-12 A lot of quotes end at launch day, and a lot of clients assume that's the end of the work too. It isn't. A website that's never touched again slowly gets slower, less secure, and harder to update — even if nothing about it looks different from the outside. #### What maintenance actually covers **Security updates.** Frameworks, plugins, and libraries get patched constantly. Skipping updates for a year on a WordPress site, for example, is one of the most common ways sites get hacked or defaced — not through a sophisticated attack, but through a known, published vulnerability nobody bothered to patch. **Hosting and uptime.** Servers need monitoring. Traffic spikes, expired SSL certificates, and quietly full disks all cause downtime that nobody notices until a customer complains the site is down. **Backups that actually restore.** Having a backup and having a *tested* backup are different things. The bad time to find out your backup is corrupted or three months old is right after something breaks. **Small content and fix requests.** Swapping a photo, updating a price, fixing a typo, adjusting a form field — none of these need a full redevelopment, but they do need someone with access and the context to do it safely. **Dependency and platform drift.** Payment gateways change their APIs. Browsers deprecate old behavior. A site built two years ago and never touched can quietly stop working in ways nobody notices until checkout breaks. #### What happens if you skip it Nothing, for a while — which is exactly why it's easy to skip. Then a plugin vulnerability gets exploited, or a certificate expires on a Friday night, or a developer who built the original site is unreachable and nobody else understands the codebase. The cost of neglect is usually invisible until the moment it's very visible and very urgent. #### Do you actually need a maintenance plan? - **A brochure site that never changes** — probably just needs occasional security patching and uptime monitoring, not a monthly retainer. - **A site with a blog, forms, or regular content updates** — benefits from someone with standing access who can make small changes quickly. - **A web app with logins, payments, or user data** — needs ongoing attention. This is the category where "we'll deal with it if something breaks" gets expensive fast. #### What to ask before you sign anything 1. Does the maintenance plan include security patches, or just content changes? 2. How often are backups taken, and has a restore ever actually been tested? 3. What's the response time if something breaks at 11pm on a weekend? 4. Who has admin access to the hosting, domain, and codebase — and what happens if you switch providers later? If you're not sure whether your current setup needs ongoing maintenance, or you inherited a site nobody's touched in a while, [message us on WhatsApp](/api/whatsapp?intent=contact&lang=en) and we'll give you a straight read on what shape it's actually in. ### Website or Web App: Which One Does Your Business Actually Need? Page: https://nobledevco.com/en/blog/website-vs-web-app-which-one Published: 2026-09-05 A lot of founders come to us asking for "a website" when what they actually need is a web app — or the other way around. Getting this wrong doesn't just waste budget, it can mean rebuilding from scratch six months later. #### The core difference A **website** presents information. People visit, read, and leave — or fill out a contact form. It's largely the same for every visitor. A **web app** does something *for* each user. It has logins, stores data per account, and changes based on who's using it — a dashboard, a booking system, an ordering platform. Neither is "better." They solve different problems, and a lot of businesses eventually need both. #### Signs a website is enough - You're mainly explaining what you do and building trust before someone contacts you or buys elsewhere. - Your "product" is a service delivered offline or through a call, not something used inside the site itself. - Content changes occasionally (services, pricing, portfolio) but there's no ongoing interaction per user. - You need something live fast and don't yet know if the business model will need more. If this is you, a well-built website with clear calls to action will outperform an over-engineered web app you don't need yet. #### Signs you need a web app - Customers need to log in and see something specific to *them* — their orders, their bookings, their data. - There's a repeatable workflow happening on the site itself: booking, checkout, submitting requests, tracking status. - You need to manage users, roles, or permissions (customers vs. staff vs. admin). - The value you're selling is the tool itself, not just information about it. #### The middle ground: a website with app-like features Plenty of businesses don't need a full web app — they need a website with one specific interactive piece bolted on: a booking form that checks real availability, a simple client portal, an order form that talks to inventory. This is often the cheapest way to get 80% of the benefit of a web app without the cost of building one from scratch. #### A practical way to decide Ask: "If a customer needs to do the *same thing* every time — see their own data, repeat a transaction, track a status — that's a web app problem. If they mostly need to *learn something and take one action* (call, message, buy once), that's a website problem." If you're not sure which category your idea falls into, [message us on WhatsApp](/api/whatsapp?intent=contact&lang=en) and describe what you're trying to build — we'll tell you straight which one actually fits, even if it means recommending the cheaper option.