Labtek Indie
Published in

Labtek Indie

Memilih Stack Teknologi untuk MVP

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

Saya senang kalau saya salah. Dulu saya pernah bilang bahwa salah satu misi hidup saya adalah menghindari PHP. Namun ternyata, saat seorang kolega menganjurkan Laravel untuk membuat MVP, saya terbukti salah. Membuat web app dengan Laravel ternyata menyenangkan. Ada konsensus struktur project yang masuk akal dan membuat front end dengan template, bisa menjadi rekreasi dari kebiasaan membuat UI dengan pendekatan component-based. Dengan Laravel, kita bisa mendapatkan full stack front-end dan back-end. Meski saya tetap bukan penggemar PHP, tapi menggunakan Laravel adalah pengalaman positif.

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

Apabila data yang dibutuhkan MVP kita bisa dengan cukup mudah dimodelkan dengan pendekatan ala CMS, maka opsi menggunakan headless CMS seperti Strapi adalah solusi yang sangat menggoda. Strapi memungkinkan kita untuk dengan cepat memodelkan serta mengelola data dengan antarmuka CMS yang user friendly. Tidak hanya itu, semua data yang ditulis di Strapi bisa langsung diakses melalui REST API (ada GraphQL juga, namun butuh plugin tambahan). Selain itu tambahan seperti autentikasi dan autorisasi juga langsung disediakan oleh Strapi. Sungguh sebuah pilihan yang menarik. Tambahan lain, kita juga perlu memilih database mana yang akan digunakan dengan 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

Berbicara soal deployment, bagaimana jika kita ingin meminimalisir deployment? Next.js adalah sebuah framework React yang memungkinkan kita untuk melakukan deployment front end sebagai sebuah static page dan rute API custom sebagai sebuah FaaS (Function as a Service) yang kemudian bisa dideploy di Vercel, platform deployment mereka. Ini benar-benar memudahkan kita, karena kita tidak perlu memikirkan aspek deployment aplikasi, terutama front end.

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

Itulah beberapa kombinasi stack teknologi yang bisa dipilih untuk membuat MVP. Secara filosofis, saya berusaha untuk se-monolithic mungkin dengan menggabungkan sebanyak mungkin pekerjaan front-end dan back-end sembari tetap meminimalisir hal yang harus saya lakukan. Kombinasi-kombinasi di atas memungkinkan saya untuk bisa fokus membedah kompleksitas alur proses bisnis dan meng-outsource pekerjaan lain ke stack teknologi yang saya pilih. Sekali lagi, ini bukan stack teknologi ajeg. Saya yakin, Anda pasti punya pilihan teknologi yang berbeda.

Selamat membuat MVP.

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