Bisakah Anda Membangun POS dengan Lovable atau Replit? Apa yang Hilang Setelah UI

Bisa dibilang begitu. Anda bisa membangun POS dengan Lovable atau Replit, asalkan definisi Anda tentang POS hanya sebatas di layar saja. Keduanya akan menghasilkan antarmuka checkout, kisi produk, dan keranjang belanja dalam waktu satu sore, dan tampilannya akan terlihat lebih baik daripada banyak perangkat lunak yang dibeli pedagang dengan uang sungguhan. Kesenjangan mulai terlihat setelah UI, pada bagian-bagian point of sale yang tidak terlihat: inventaris, pelaporan, pajak, dan pembayaran yang harus selalu akurat setiap saat.

Satu catatan penting di awal: Lovable dan Replit terus meluncurkan perubahan secara konsisten, jadi anggap detail di bawah ini akurat pada saat publikasi dan perlu diperiksa kembali.

Apa yang sebenarnya diberikan oleh Lovable dan Replit kepada Anda?

Lebih dari yang diasumsikan oleh para skeptis. Lovable menghasilkan aplikasi web full-stack: frontend React yang terhubung ke backend ter-host dengan database, autentikasi, dan penyimpanan file, ditambah integrasi pembayaran untuk checkout online. Replit melangkah lebih jauh di sisi server: agennya membangun dan meng-host aplikasi dengan database bawaan, hosting, dan autentikasi, sehingga logika backend berjalan tanpa perlu menyatukan layanan pihak ketiga.

Untuk sebagian besar kelas perangkat lunak (alat internal, halaman pemesanan, dasbor) itu memang sudah mencakup seluruh pekerjaan, itulah sebabnya platform-platform ini berkembang sangat cepat. Masalahnya adalah point of sale tidak termasuk dalam kelas tersebut, karena alasan yang sama model frontier yang dapat membuat aplikasi web dalam sekali coba tetap terhambat pada POS yang berfungsi: bagian yang sulit bukanlah antarmukanya.

Apa yang hilang setelah UI?

Lapisan perdagangan (commerce layer). Point of sale adalah sistem pencatatan (sumber kebenaran tunggal untuk uang dan stok Anda) yang kebetulan memiliki aplikasi di atasnya. Kedua platform tersebut tidak menyediakan fungsi dasar perdagangan, sehingga kode yang dihasilkan harus membuatnya dari nol:

• Inventaris yang tahan terhadap konkurensi (dua kasir melakukan penjualan di saat yang bersamaan). Mengurangi kolom stok memang berfungsi dalam demo, tetapi akan gagal pada hari Sabtu pertama ketika dua stasiun kasir menjual unit terakhir secara bersamaan.

• Siklus hidup pesanan. Pengembalian dana sebagian, penukaran barang, pembatalan, dan diskon masing-masing merupakan perubahan status yang harus memperbarui inventaris, pelaporan, dan catatan pembayaran secara bersamaan; lewatkan satu saja maka angka-angka Anda akan meleset.

• Pelaporan yang sinkron (total yang cocok dengan setoran pembayaran Anda hingga ke pecahan sen terakhir). Laporan yang hanya "mendekati" adalah masalah pembukuan yang baru akan Anda temukan saat musim pajak.

• Logika pajak yang mengikuti aturan yurisdiksi nyata dan tercantum dengan benar pada setiap tanda terima, pengembalian dana, dan laporan.

Agen AI akan menghasilkan versi yang tampak meyakinkan untuk keempat hal tersebut. Tampilan meyakinkan inilah yang menjebak: tombol yang rusak akan langsung terlihat saat Anda mengetuknya, sementara bug rekonsiliasi tidak terlihat sampai akuntan Anda menemukannya beberapa bulan kemudian.

Bisakah aplikasi hasil buatan AI menerima pembayaran sungguhan?

Secara online, ya: kedua platform terhubung ke integrasi pembayaran dengan cukup baik untuk checkout web. Namun, pembayaran langsung secara tatap muka adalah hal yang sangat berbeda. Pembayaran dengan kartu fisik memerlukan perangkat keras terminal yang tersertifikasi dan kepatuhan PCI DSS (aturan keamanan industri kartu untuk apa pun yang menyentuh data kartu). Tidak ada basis kode hasil buatan AI yang dapat memenuhi hal itu dengan sendirinya; sertifikasi tersebut berada pada perangkat keras dan platform penyedia pembayaran, bukan pada aplikasi Anda. Sengketa, pengembalian dana sebagian ke kartu asli, dan penyesuaian tip semuanya berjalan melalui lapisan bersertifikat yang sama ini.

Ini adalah tembok yang pada akhirnya akan ditabrak oleh setiap jalur DIY, apa pun alatnya. Kami menemukan hal yang sama saat menguji apa yang bisa dan tidak bisa dibangun oleh model AI melalui MCP.

Apa yang pertama kali rusak di lingkungan produksi?

Sanggahan yang jelas: "Baiklah, saya akan menghubungkan sendiri aplikasi hasil buatan AI tersebut ke database ter-host dan integrasi pembayaran." Anda bisa melakukannya, dan banyak orang harus mencobanya; ini adalah cara tercepat untuk mempelajari batas kemampuannya. Namun pahamilah apa yang Anda hadapi: Anda sekarang adalah satu-satunya pemelihara sistem keuangan kecil tersebut. Ketika jaringan terputus di tengah penjualan, ketika printer struk membutuhkan driver yang tidak dimiliki browser, ketika pengembalian dana berhasil melalui integrasi pembayaran tetapi tidak pernah masuk ke laporan Anda, tidak ada vendor yang bisa dihubungi. Pembuatan adalah bagian yang murah. Kepemilikan adalah bagian yang mahal, dan itu dimulai sejak hari pertama Anda menerima pembayaran sungguhan.

Jadi, bisakah Anda membangun POS dengan Lovable atau Replit?

Anda bisa membangun bagian depannya: antarmuka nyata, logika nyata, yang diluncurkan dengan cepat. Anda tidak bisa menghasilkan bagian belakangnya, karena inventaris di bawah beban kerja tinggi, rekonsiliasi, pajak, dan pembayaran kartu fisik bersertifikat bukanlah kode yang bisa diciptakan oleh agen AI; semua itu adalah infrastruktur yang harus sudah ada sebelumnya. Hal itu menyisakan dua jalur yang jujur: membangun kembali infrastruktur itu sendiri dan memeliharanya selamanya, atau menghasilkan checkout Anda di atas infrastruktur perdagangan yang sudah berjalan, yang merupakan pendekatan di balik Final, di mana sebuah prompt atau alat AI Anda sendiri membangun POS di atas backend perdagangan langsung.

Bagaimanapun, satu aturan praktis sebelum Anda membiarkan AI apa pun membangunnya: jika sebuah bug merugikan uang alih-alih piksel, Anda sedang membangun infrastruktur, bukan UI. Jika Anda ingin melihat apa yang ada di balik checkout ketika lapisan perdagangan sudah disertakan, begini tampilannya dalam praktiknya.