আপনি কি Lovable বা Replit দিয়ে একটি POS তৈরি করতে পারেন? UI-এর পরে যা যা অনুপস্থিত থাকে

এক অর্থে হ্যাঁ। আপনি Lovable বা Replit দিয়ে একটি POS তৈরি করতে পারেন, যতক্ষণ না আপনার POS-এর সংজ্ঞাটি স্ক্রিনেই সীমাবদ্ধ থাকে। উভয় প্ল্যাটফর্মই এক বিকালের মধ্যে একটি চেকআউট ইন্টারফেস, একটি প্রোডাক্ট গ্রিড এবং একটি কার্ট তৈরি করে দেবে, এবং এটি দেখতে এমন অনেক সফটওয়্যারের চেয়েও সুন্দর হবে যার জন্য মার্চেন্টরা আসল টাকা খরচ করেন। তবে ইন্টারফেসের (UI) পরেই আসল ব্যবধানটি তৈরি হয়, পয়েন্ট অব সেলের এমন কিছু অংশে যা আপনি দেখতে পান না: ইনভেন্টরি, রিপোর্টিং, ট্যাক্স এবং পেমেন্ট যা প্রতিবারই নিখুঁত হতে হয়।

শুরুতেই একটি সতর্কবার্তা: Lovable এবং Replit প্রতিনিয়ত পরিবর্তন নিয়ে আসে, তাই নিচের সুনির্দিষ্ট বিষয়গুলোকে প্রকাশের সময়কালের জন্য সঠিক হিসেবে ধরে নিন এবং পরবর্তীতে পুনরায় যাচাই করে নেওয়া ভালো।

Lovable এবং Replit আসলে আপনাকে কী দেয়?

সংশয়বাদীরা যা ভাবেন তার চেয়ে অনেক বেশি। Lovable একটি ফুল-স্ট্যাক ওয়েব অ্যাপ তৈরি করে: একটি হোস্টেড ব্যাকএন্ডের সাথে যুক্ত React ফ্রন্টএন্ড যাতে ডেটাবেস, অথেন্টিকেশন এবং ফাইল স্টোরেজ রয়েছে, পাশাপাশি অনলাইন চেকআউটের জন্য পেমেন্ট ইন্টিগ্রেশনও থাকে। Replit সার্ভার সাইডে আরও এক ধাপ এগিয়ে যায়: এর এজেন্ট বিল্ট-ইন ডেটাবেস, হোস্টিং এবং অথেন্টিকেশন সহ অ্যাপ তৈরি ও হোস্ট করে, ফলে থার্ড-পার্টি সার্ভিসগুলো একসাথে জোড়াতালি দেওয়া ছাড়াই ব্যাকএন্ড লজিক কাজ করে।

একটি বড় শ্রেণির সফটওয়্যারের জন্য (অভ্যন্তরীণ টুল, বুকিং পেজ, ড্যাশবোর্ড) এটিই আসলে পুরো কাজ, আর এই কারণেই এই প্ল্যাটফর্মগুলো এত দ্রুত বৃদ্ধি পাচ্ছে। সমস্যা হলো, পয়েন্ট অব সেল এই শ্রেণির অন্তর্ভুক্ত নয়, ঠিক একই কারণে একটি ফ্রন্টিয়ার মডেল যা এক চান্সে একটি ওয়েব অ্যাপ তৈরি করতে পারে তাও একটি কার্যকর POS তৈরিতে আটকে যায়: কঠিন অংশটি কখনোই ইন্টারফেস ছিল না।

UI-এর পর কী বাদ থেকে যায়?

কমার্স লেয়ার। একটি পয়েন্ট অব সেল হলো রেকর্ডের একটি সিস্টেম (আপনার টাকা এবং স্টকের একমাত্র নির্ভরযোগ্য উৎস) যার ওপর একটি অ্যাপ বসানো থাকে। কোনো প্ল্যাটফর্মই কমার্স প্রিমিটিভ সরবরাহ করে না, তাই জেনারেট করা কোডকে এগুলো একদম শূন্য থেকে তৈরি করতে হয়:

• ইনভেন্টরি যা কনকারেন্সি সামলাতে পারে (একই মুহূর্তে দুটি ক্যাশ কাউন্টারে বিক্রি হওয়া)। ডেমোতে স্টকের কলাম কমানো কাজ করলেও, প্রথম শনিবারেই যখন দুটি কাউন্টার থেকে একই সাথে শেষ ইউনিটটি বিক্রি হবে, তখন এটি ব্যর্থ হবে।

• একটি অর্ডারের লাইফসাইকেল। আংশিক রিফান্ড, এক্সচেঞ্জ, ভয়েড এবং ডিসকাউন্ট—প্রতিটিই এমন স্টেট পরিবর্তন যা ইনভেন্টরি, রিপোর্টিং এবং পেমেন্ট রেকর্ডকে একসাথে আপডেট করতে হবে; একটি বাদ গেলেই আপনার হিসেব এলোমেলো হয়ে যাবে।

• রিপোর্টিং যা সামঞ্জস্যপূর্ণ হয় (মোট হিসাব যা আপনার পেমেন্ট ডিপোজিটের সাথে পয়সায় পয়সায় মিলে যায়)। যে রিপোর্ট কেবল "কাছাকাছি" মেলে, তা আসলে বুককিপিংয়ের একটি সমস্যা যা আপনি ট্যাক্স দেওয়ার সময় আবিষ্কার করবেন।

• ট্যাক্স লজিক যা প্রকৃত এক্তিয়ারের নিয়ম অনুসরণ করে এবং প্রতিটি রসিদ, রিফান্ড ও রিপোর্টে সঠিকভাবে প্রতিফলিত হয়।

একটি এআই এজেন্ট এই চারটিরই আপাতদৃষ্টিতে গ্রহণযোগ্য সংস্করণ তৈরি করবে। এই আপাতদৃষ্টিতে গ্রহণযোগ্য হওয়াই হলো ফাঁদ: একটি ভাঙা বা অকার্যকর বাটন ট্যাপ করার সাথে সাথেই চোখে পড়ে, কিন্তু একটি রিকনসিলিয়েশন বাগ অলক্ষ্যে পড়ে থাকে যতক্ষণ না আপনার অ্যাকাউন্ট্যান্ট কয়েক মাস পর এটি খুঁজে পান।

একটি জেনারেট করা অ্যাপ কি আসল পেমেন্ট গ্রহণ করতে পারে?

অনলাইনে হ্যাঁ: ওয়েব চেকআউটের জন্য উভয় প্ল্যাটফর্মই পেমেন্ট ইন্টিগ্রেশনের সাথে বেশ ভালোভাবে যুক্ত হতে পারে। তবে সশরীরে পেমেন্ট নেওয়া সম্পূর্ণ ভিন্ন বিষয়। কার্ডের উপস্থিতিতে পেমেন্ট নেওয়ার জন্য সার্টিফাইড টার্মিনাল হার্ডওয়্যার এবং PCI DSS কমপ্লায়েন্স (কার্ডের ডেটা স্পর্শ করে এমন যেকোনো কিছুর জন্য কার্ড ইন্ডাস্ট্রির নিরাপত্তা নিয়মাবলী) প্রয়োজন। কোনো জেনারেট করা কোডবেস নিজে থেকে এটি পূরণ করতে পারে না; এই সার্টিফিকেশন পেমেন্ট প্রোভাইডারের হার্ডওয়্যার এবং প্ল্যাটফর্মে থাকে, আপনার অ্যাপে নয়। বিরোধ নিষ্পত্তি, মূল কার্ডে আংশিক রিফান্ড এবং টিপ অ্যাডজাস্টমেন্ট—সবকিছুই এই একই সার্টিফাইড লেয়ারের মাধ্যমে পরিচালিত হয়।

যেকোনো DIY (নিজে করুন) পদ্ধতি শেষ পর্যন্ত এই দেয়ালে এসেই আটকে যায়, টুলটি যাই হোক না কেন। একটি এআই মডেল MCP-এর মাধ্যমে কী তৈরি করতে পারে এবং কী পারে না তা পরীক্ষা করার সময় আমরা একই জিনিস দেখতে পেয়েছি।

প্রোডাকশনে সবার আগে কী ভেঙে পড়ে?

স্বাভাবিক আপত্তিটি হলো: "ঠিক আছে, আমি নিজেই জেনারেট করা অ্যাপটিকে একটি হোস্টেড ডেটাবেস এবং একটি পেমেন্ট ইন্টিগ্রেশনের সাথে যুক্ত করে নেব।" আপনি তা করতে পারেন, এবং অনেকেরই এটি চেষ্টা করে দেখা উচিত; সর্বনিম্ন সীমাটি কোথায় তা জানার এটিই দ্রুততম উপায়। কিন্তু আপনি কিসের দায়িত্ব নিচ্ছেন তা বুঝে নিন: আপনি এখন একটি ছোট আর্থিক সিস্টেমের একমাত্র রক্ষণাবেক্ষণকারী। বিক্রির মাঝপথে যখন নেটওয়ার্ক চলে যাবে, যখন রসিদ প্রিন্টারের এমন একটি ড্রাইভারের প্রয়োজন হবে যা ব্রাউজারে নেই, যখন পেমেন্ট ইন্টিগ্রেশনের মাধ্যমে রিফান্ড সফল হবে কিন্তু আপনার রিপোর্টে তার কোনো চিহ্ন থাকবে না, তখন কল করার মতো কোনো ভেন্ডর থাকবে না। এটি তৈরি করা ছিল সস্তা অংশ। মালিকানা ধরে রাখাটাই হলো ব্যয়বহুল অংশ, এবং এটি শুরু হয় যেদিন আপনি আপনার প্রথম আসল পেমেন্ট গ্রহণ করেন।

তাহলে, আপনি কি Lovable বা Replit দিয়ে একটি POS তৈরি করতে পারেন?

আপনি এর সামনের অংশটি (ফ্রন্টএন্ড) তৈরি করতে পারেন: একটি আসল ইন্টারফেস, আসল লজিক, যা দ্রুত ডেলিভারি করা যায়। কিন্তু আপনি এর পেছনের অংশটি (ব্যাকএন্ড) জেনারেট করতে পারবেন না, কারণ চাপের মুখে ইনভেন্টরি ম্যানেজমেন্ট, রিকনসিলিয়েশন, ট্যাক্স এবং সার্টিফাইড কার্ড-প্রেজেন্ট পেমেন্ট এমন কোনো কোড নয় যা কোনো এজেন্ট নিজে থেকে উদ্ভাবন করতে পারে; এগুলো এমন অবকাঠামো যা আগে থেকেই বিদ্যমান থাকতে হয়। এটি দুটি সৎ পথ খোলা রাখে: এই অবকাঠামোটি নিজে আবার তৈরি করুন এবং চিরকাল এর মালিকানা বজায় রাখুন, অথবা আগে থেকেই চালু থাকা কমার্স অবকাঠামোর ওপর আপনার চেকআউট জেনারেট করুন, যা Final-এর পেছনের মূল ভাবনা, যেখানে একটি প্রম্পট বা আপনার নিজস্ব এআই টুল একটি লাইভ কমার্স ব্যাকএন্ডের ওপর POS তৈরি করে।

যাই হোক না কেন, কোনো এআই-কে এটি তৈরি করতে দেওয়ার আগে একটি সহজ নিয়ম মনে রাখবেন: যদি কোনো বাগের কারণে পিক্সেলের বদলে টাকা খোয়া যায়, তবে আপনি ইউজার ইন্টারফেস (UI) নয়, বরং অবকাঠামো তৈরি করছেন। কমার্স লেয়ারটি অন্তর্ভুক্ত থাকলে চেকআউটের নিচে কী থাকে তা যদি আপনি দেখতে চান, তবে বাস্তবে এটি কেমন দেখায় তা এখানে দেখুন।