Memilih Stack Teknologi untuk MVP

Adityo Pratomo
Oct 26, 2020 · 5 min read
Photo by Jo Szczepanska on Unsplash

MVP (Minimum Viable Product) adalah versi paling minimal dari sebuah produk yang dianggap sudah cukup untuk mewakili fungsi inti produk tersebut, yang kemudian dirilis untuk digunakan publik. Fase ini bisa dikatakan sebagai tahap awal sebuah produk, di mana seorang (atau sebuah organisasi) pemilik produk tersebut ingin menguji asumsinya: benarkah produk ini bisa menjawab permasalahan yang dibayangkan dan adakah yang rela menggunakan atau bahkan membayar untuk menggunakan produk tersebut. Dengan kata lain, di titik ini, niatan terbesarnya adalah untuk eksplorasi domain permasalahan serta validasi solusi dalam waktu secepat mungkin, karena kita tentu tidak ingin jatuh cinta pada produk yang salah dalam waktu lama.

Karena MVP ini harus digunakan oleh orang lain, tentu saja, dalam konteks produk digital, ia harus berupa implementasi kode yang sudah terpasang di sebuah mesin dan bisa diakses di perangkat setiap pengguna. Guna mencapai keadaan itu, maka seorang pembuat produk harus menentukan stack (susunan) teknologi seperti apa yang cocok untuk mengimplementasikan konsep MVP ini. Menariknya, ini ternyata bukanlah permasalahan sederhana, karena di satu sisi kita ingin memilih teknologi yang paling familiar, sehingga kita bisa cepat memvalidasi produk, namun di sisi lain, faktor suara dari luar seperti tren, buzzword , hingga masalah yang belum tentu kita temui seperti performa tinggi dan skalabilitas, bisa turut memberikan bias tersendiri dalam menentukan stack teknologi ini.

Untuk itu, dalam memilih stack teknologi, ada beberapa hal yang perlu kita perhatikan:

  1. Tingkat familiaritas dengan sebuah bahasa pemrograman/framework. Semakin familiar, maka kita bisa lebih fokus pada memecahkan permasalahan bisnis, alih-alih bergulat dengan sintaks ataupun konsensus
  2. Ketersediaan komponen pendukung. Tentu, kamu bisa membuat semuanya dari nol, tapi apakah itu cara menggunakan waktu yang bijak, di saat MVP justru bernilai saat kita ingin memvalidasi produk secepat mungkin?
  3. Derajat kustomisasi teknologi. Di saat kamu sudah memilih sebuah stack, apakah masih ada ruang bagi kita untuk melakukan kustomisasi demi memenuhi alur bisnis yang spesifik bagi organisasi kita?
  4. Performa serta skalabilitas super tinggi, bukan faktor yang kita perhitungkan. Kita tidak perlu terlalu memikirkan “apakah aplikasi ini bisa menunjukkan kinerja tinggi saat digunakan oleh 10 ribu pengguna secara bersamaan?” apabila kita pun belum punya 20 ribu pengguna aktif.

Berdasarkan poin-poin tersebut, ada beberapa contoh stack teknologi yang sudah pernah saya gunakan, yang menurut saya menarik untuk dicoba dalam rangka membuat MVP. Tentu, ini bukan stack pakem, saya yakin teman-teman pembaca pasti punya preferensi pribadi yang berbeda. Namun, kita mungkin bisa sedikit meniru kenapa saya memilih stack tersebut.

Laravel + Airtable

Di sisi penyimpanan data, Airtable juga solusi no-code yang menarik. Ia bisa langsung menyediakan endpoint REST API dari data yang kita miliki, sehingga query data dari Laravel bisa dilakukan dengan runut. Selain itu, di fase prototyping awal, struktur data bisa lebih mudah dilakukan, bahkan oleh pengguna non-teknis sekalipun, karena antarmuka Airtable yang lebih ramah dari database biasa ataupun Excel.

Alternatif lain, Laravel bisa digantikan dengan MVC framework seperti Rails ataupun .NET.

Vue + Strapi

Setelah REST API tersedia, dan apabila kita tidak membutuhkan banyak custom business logic, maka sebenarnya, kita hanya memerlukan aspek front-end. Terlebih lagi, inilah yang akan menjadi penilaian pertama oleh pengguna saat MVP digunakan. Vue bisa menjadi pilihan yang tepat, berkat kelengkapan ekosistemnya dan kompleksitasnya yang relatif lebih rendah dibandingkan React.

Alternatif lain, Strapi bisa digantikan dengan banyak headless CMS seperti Sanity, ataupun Prismic. Dan ada banyak solusi lain yang hosted, sehingga kita tidak perlu memikirkan deployment backend. Vue tentu saja bisa digantikan dengan React ataupun Angular, tergantung mana yang lebih familiar.

Next.js + Hasura

Jika kita sudah sepenuhnya percaya dengan GraphQL sebagai protokol akses data, maka Hasura adalah solusi yang bisa dengan mudah menyediakan abstraksi ini. Dengan Hasura, kita bisa langsung membuat sebuah database Postgres yang datanya langsung diekspos via GraphQL, tanpa perlu menuliskan scheme GraphQL sendiri, baik untuk query ataupun mutation. Saya cukup kaget ketika menggunakannya, karena ini benar-benar ajaib. Hasura juga menyediakan opsi deployment cepat ke Heroku. Oh, jangan lupa, ada juga GraphQL subscription jika kita ingin update data otomatis.

Alternatif lain, kita bisa menggunakan framework React seperti Gatsby, ataupun Nuxt dan Quasar di dunia Vue. Hasura bisa digantikan dengan Postgraphile, AWS App Sync ataupun Prisma. Jika membutuhkan data yang selalu terupdate, mungkin Firebase bisa menjadi opsi lain, meski querynya perlu dilakukan dengan metode bawaan Firebase.

Penutup

Selamat membuat MVP.

Labtek Indie

We help you solve problem and build prototype for your…

Labtek Indie

We help you solve problem and build prototype for your technology product.

Adityo Pratomo

Written by

Digital product maker. Do design and code just to see pixels give real-world values. Cyclist + Gamer + Metalhead. Also, proud dad and husband.

Labtek Indie

We help you solve problem and build prototype for your technology product.