ساخت اپلیکیشن و پلتفرم خرید و فروش طلا: مراحل، هزینه‌ها و اشتباه‌هایی که گران تمام می‌شود
۱۹ مهر ۱۴۰۵·۱۱ دقیقه مطالعه
بیشتر کسانی که می‌خواهند یک اپلیکیشن خرید و فروش طلا بسازند، کار را از ظاهر شروع می‌کنند: چند صفحه‌ی زیبا، یک نمودار قیمت، دکمه‌ی خرید و فروش. ظاهر مهم است، اما بخش کوچکی از کار است. پلتفرمی که پول و طلای واقعی مردم را نگه می‌دارد، بیشتر از آنچه روی صفحه دیده می‌شود، به چیزهایی وابسته است که کاربر هرگز نمی‌بیند: دقت حساب‌ها، قیمت قابل اتکا، امنیت و پنل مدیریتی که تیم شما هر روز با آن کار می‌کند.
این راهنما برای کسی نوشته شده که قصد دارد چنین پلتفرمی را سفارش بدهد یا بسازد و می‌خواهد قبل از خرج‌کردن، تصویر درستی از کار داشته باشد. بخشی از آنچه می‌خوانید از تجربه‌ی مستقیم خود ما در ساخت و اجرای گلدینکس آمده است، یک اپلیکیشن معاملات آنلاین طلای آب‌شده که با کاربر و تراکنش واقعی در حال کار است. جایی که اشتباه کرده‌ایم هم همان‌جا نوشته‌ایم، چون درس‌های گران‌تر معمولاً از همان‌جاها می‌آید.
۱. اول مدل کسب‌وکار را مشخص کنید، نه صفحه‌ها را
«پلتفرم خرید و فروش طلا» یک چیز واحد نیست. سه مدل رایج وجود دارد و هر کدام معماری، ریسک و هزینه‌ی خودش را دارد:
- طلای حسابی یا دیجیتال: کاربر طلا را به‌صورت وزن (مثلاً گرم یا میلی‌گرم) در حساب خودش نگه می‌دارد و هر زمان بخواهد می‌فروشد یا تحویل می‌گیرد. اینجا شما در عمل امانتدار دارایی مردم هستید و دقت حسابداری و قیمت‌گذاری حیاتی‌ترین بخش کار است.
- فروش سکه، شمش و زیورآلات با تحویل فیزیکی: کالا مشخص است و تحویل، موجودی انبار و ارسال به مدل اضافه می‌شود. پیچیدگی بیشتر در موجودی و لجستیک است تا در دفترکل.
- سامانه‌ی معاملات اختصاصی: مشتری‌ها شناخته‌شده‌اند و معامله بیشتر شبیه رابطه‌ی بازار سنتی است، اما با ثبت دقیق، تسویه‌ی چندطرفه و گزارش‌گیری. مقاله‌ی «سامانه معاملات اختصاصی چیست» در همین بلاگ این مدل را جداگانه توضیح داده است.
اگر جواب این سؤال روشن نباشد، هر پیشنهاد قیمتی که بگیرید روی حدس بنا شده است. دو شرکت می‌توانند برای «اپلیکیشن طلا» دو عدد کاملاً متفاوت بدهند، فقط چون هر کدام مدل دیگری را در ذهن دارد.
۲. اپلیکیشن موبایل، وب‌اپ یا هر دو؟
بیشتر کاربران ایرانی از موبایل وارد می‌شوند، پس تجربه‌ی موبایل نباید فکر دومتان باشد. اما «اپلیکیشن» همیشه به معنی نسخه‌ی نیتیو جداگانه برای هر سیستم‌عامل نیست. یک وب‌اپ پیش‌رونده (PWA) که روی صفحه‌ی گوشی نصب می‌شود، هزینه و زمان کمتری دارد و برای شروع اغلب کافی است. نسخه‌ی نیتیو یا بسته‌بندی‌شده برای اندروید را می‌توان بعداً و با داده‌ی واقعی استفاده‌ی کاربران اضافه کرد.
تصمیم درست به مخاطب بستگی دارد. اگر کاربران شما بیشتر گوشی اندروید دارند و انتشار در بازارهای داخلی مثل کافه‌بازار و مایکت برایتان مهم است، نسخه‌ی اندروید زودتر ارزش پیدا می‌کند. اگر هنوز نمی‌دانید، با یک تجربه‌ی موبایل‌محور شروع کنید و تصمیم درباره‌ی نسخه‌ی نیتیو را به بعد از اولین ماه‌های فعالیت واقعی بسپارید.
۳. قیمت لحظه‌ای: قلب پلتفرم و اولین جایی که خراب می‌شود
کاربر پلتفرم طلا یک چیز را بیش از همه نگاه می‌کند: قیمت. این قیمت باید از منبع یا منابع قابل اتکا بیاید، به‌سرعت به کاربران برسد و در لحظه‌ی معامله دقیقاً همان چیزی باشد که کاربر دیده است. سه نکته‌ی عملی در اینجا هست.
اول، منبع قیمت یک نقطه‌ی شکست است. هر منبع بیرونی روزی کند می‌شود، قطع می‌شود یا عدد غلط می‌دهد. باید از قبل تصمیم بگیرید در آن لحظه چه می‌شود. گزینه‌ها دو تاست: معامله را موقتاً ببندید یا آخرین قیمت معتبر را نگه دارید و به تیم هشدار بدهید. هر دو را می‌شود دفاع کرد، ولی تصمیم نگرفتن قابل دفاع نیست. ما در گلدینکس ترجیح دادیم اپلیکیشن بدون قیمت نماند و حتی همین تصمیم هم باید با یک سازوکار هشدار کامل شود تا قیمت کهنه بی‌صدا ماندگار نشود.
دوم، قیمتی که کاربر می‌بیند باید همان قیمتی باشد که معامله با آن ثبت می‌شود. در تجربه‌ی خودمان، کاربر صفحه‌ی تأیید خرید یا فروش را باز می‌کرد، قیمت پشت صحنه عوض می‌شد و معامله با قیمت تازه ثبت می‌شد، بدون اینکه کاربر چیزی ببیند. راه‌حل این است که صفحه‌ی تأیید یا قیمت را قفل کند و مهلت آن را نشان بدهد یا قیمت زنده را همان‌جا به‌روز نشان بدهد و کاربر دقیقاً همان چیزی را تأیید کند که ارسال می‌شود. گاهی خطا از جای ساده‌تری می‌آید: مبلغی که کاربر در پنجره‌ی تأیید می‌خواند و مبلغی که درخواست واقعاً با آن ارسال می‌شود از دو منبع مختلف پر شده‌اند.
سوم، تحویل سریع به کاربر مهم است. قیمتی که هر چند ثانیه یک‌بار با ریفرش دستی عوض شود با قیمتی که از طریق اتصال زنده (WebSocket) در کمتر از یک ثانیه به همه‌ی کاربران می‌رسد، حس اعتماد کاملاً متفاوتی می‌سازد.
۴. دفترکل: جایی که اشتباه کوچک، بدهی بزرگ می‌شود
هر پلتفرمی که موجودی کاربران را نگه می‌دارد، یک دفترکل لازم دارد. یعنی هر حرکت پول یا طلا (واریز، برداشت، خرید، فروش، انتقال، پاداش، بازگشت وجه) به‌صورت یک ردیف ثبت شود، با مقدار، نوع عملیات و موجودی بعد از آن و هیچ ردیفی عوض نشود. موجودی فعلی باید همیشه با جمع این ردیف‌ها بخواند. چند قاعده‌ی فنی که از همان ابتدا باید رعایت شود:
- مبلغ و وزن را عدد صحیح و در کوچک‌ترین واحد ذخیره کنید (ریال یا تومان صحیح، میلی‌گرم یا سوت)، نه عدد اعشاری. خطای گردکردن در اعشاری، در حجم بالا به اختلاف حساب واقعی تبدیل می‌شود.
- هر درخواست مالی یک کلید یکتا (idempotency key) داشته باشد. وقتی شبکه ضعیف است و کاربر سه بار روی «فروش» می‌زند، باید یک معامله ثبت شود، نه سه تا.
- عملیاتی که موجودی را عوض می‌کند باید در یک تراکنش دیتابیس و با قفل مناسب انجام شود تا دو درخواست هم‌زمان از یک حساب نتوانند هم‌دیگر را دور بزنند.
- مغایرت‌گیری دوره‌ای بگذارید: برای هر کاربر، موجودی فعلی را با جمع کل تاریخچه‌اش مقایسه کنید و هر اختلافی را هشدار بدهید.
این‌ها را از کتاب یاد نگرفتیم. در گلدینکس، چندبار ثبت‌شدن درخواست‌های فروش در شرایط شبکه‌ی ناپایدار باعث ردیف‌های تکراری در حساب چند کاربر شد. بعد از مدتی که یک مقایسه‌ی کامل موجودی هر کاربر با تاریخچه‌اش انجام دادیم، اختلاف‌ها پیدا شد و باید یکی‌یکی اصلاح می‌شد. اگر از روز اول کلید یکتا و مغایرت‌گیری داشتید، هیچ‌کدام از این‌ها لازم نبود.
۵. احراز هویت و واریز و برداشت
ثبت‌نام کاربر در پلتفرم طلا فقط شماره و رمز نیست. معمولاً شامل تأیید شماره‌ی موبایل، تطبیق کد ملی با مالک شماره و کارت بانکی و گاهی تصویر مدارک است. این کار به سرویس‌های استعلام نیاز دارد که هزینه و محدودیت خودشان را دارند و باید از ابتدا در برنامه‌ریزی بیایند.
مسیر واریز و برداشت هم یکی از سخت‌ترین بخش‌هاست. واریز می‌تواند از درگاه پرداخت باشد یا از طریق انتقال بانکی که ادمین تأیید می‌کند. هر کدام مزایا و دردسر خودش را دارد. برداشت معمولاً با تأیید دستی یا نیمه‌خودکار، سقف روزانه و بررسی ریسک همراه است. نکته‌ی مهم این است که هر دو مسیر باید وضعیت‌های روشن داشته باشند (در انتظار، تأییدشده، ردشده، بازگشت‌خورده) و هر تغییر وضعیت در دفترکل اثر درست بگذارد، از جمله برگشت وجه وقتی برداشتی رد می‌شود.
قبل از شروع هم باید مجوزها و الزامات قانونی فعالیت خودتان را با مراجع مربوط و یک مشاور حقوقی بررسی کنید. این بخش از تخصص ما بیرون است و حدس‌زدن درباره‌اش خطرناک است. آنچه از دست ما برمی‌آید این است که نرم‌افزار را طوری بسازیم که اعمال هر محدودیت و گزارش‌گیری لازم بعداً ممکن باشد.
۶. پنل مدیریت نصف محصول است
بیشتر سفارش‌دهنده‌ها فقط اپلیکیشن کاربر را تصور می‌کنند و پنل مدیریت را یک ضمیمه می‌دانند. در عمل، تیم شما هر روز ساعت‌ها با پنل کار می‌کند و کیفیتش مستقیماً روی سرعت و خطای انسانی اثر می‌گذارد. یک پنل خوب حداقل این‌ها را دارد:
- تنظیم قیمت، حاشیه‌ی خرید و فروش و روشن و خاموش‌کردن معامله
- صف تأیید واریز و برداشت با جزئیات کافی برای تصمیم سریع
- مشاهده‌ی تاریخچه‌ی کامل هر کاربر و موجودی او
- نقش‌ها و سطح دسترسی جدا برای اپراتور، حسابدار و مدیر
- گزارش روزانه‌ی معاملات، موجودی کل و مغایرت‌ها
- گزارش اقدام‌های ادمین، تا هر تغییر حساس قابل ردیابی باشد
۷. امنیت و پایش، نه به‌عنوان مرحله‌ی آخر
وقتی پلتفرم پول واقعی جابه‌جا می‌کند، امنیت فهرستی نیست که آخر کار تیک بخورد. حداقل‌ها از روز اول: رمزنگاری رمزها با الگوی استاندارد، محدودیت تعداد تلاش برای ورود و ارسال کد، نشست‌های قابل مدیریت و ابطال، تأیید دومرحله‌ای برای ادمین‌ها، جداسازی دیتابیس از اینترنت عمومی و بکاپ منظم که واقعاً یک بار بازیابی‌اش را امتحان کرده باشید.
پایش هم همین‌طور است. باید بدانید قیمت کهنه شده، پرداخت گیر کرده، سرور کند شده یا تعداد برداشت‌های ردشده ناگهان بالا رفته، پیش از آنکه کاربر برایتان پیام بگذارد. یک اعلان ساده به تلگرام یا پیام‌رسان داخلی برای رویدادهای مهم، خیلی زود هزینه‌اش را برمی‌گرداند.
یک قاعده‌ی کاری هم که ما رعایت می‌کنیم: هر تغییر در ساختار دیتابیس اول روی نسخه‌ی تست انجام می‌شود، بررسی می‌شود و بعد دقیقاً همان تغییر روی نسخه‌ی اصلی اعمال می‌شود. پلتفرمی که تغییر را مستقیم روی داده‌ی واقعی امتحان می‌کند، دیر یا زود گران پرداخت می‌کند.
۸. هزینه‌ی ساخت از کجا می‌آید
عدد دقیق بدون شناخت دامنه‌ی کار معنی ندارد و هر عددی که در یک مقاله بیاید، تا ماه بعد کهنه است. اما می‌توان گفت هزینه از کدام عوامل شکل می‌گیرد و با همین فهرست می‌توانید پیشنهادهای مختلف را مقایسه کنید:
- تعداد و نوع دارایی‌ها: فقط طلا یا طلا و نقره و سکه و ارز. اگر دارایی را از ابتدا یک موجودیت قابل تعریف در سیستم بگیرید (با واحد، دقت و منبع قیمت خودش)، افزودن دارایی جدید بعداً یک تنظیم است، نه بازنویسی.
- سطح احراز هویت و تعداد سرویس‌های استعلام
- روش‌های واریز و برداشت و میزان خودکارسازی
- تعداد خروجی‌ها: وب، وب‌اپ نصب‌شدنی، اندروید، iOS
- عمق پنل مدیریت، نقش‌ها و گزارش‌ها
- قابلیت‌های رشد مثل کدمعرفی، هدیه‌ی طلا، تحویل فیزیکی، چت پشتیبانی
- حجم کاربر و معامله‌ای که باید تحمل کند
- هزینه‌ی دائمی: سرور، پیامک، استعلام و مهم‌تر از همه پشتیبانی و توسعه‌ی بعد از راه‌اندازی
یک نکته‌ی تصمیم‌گیری: پیشنهاد ارزان‌تر همیشه به معنی ساخت ارزان‌تر نیست. گاهی فقط یعنی بخش‌هایی که در این مقاله آمده (مغایرت‌گیری، مدیریت خطای قیمت، تست) در پیشنهاد نیامده است و بعد از راه‌اندازی، با هزینه‌ی بیشتر و زیر فشار، ساخته می‌شود.
۹. مراحل ساخت، به ترتیب درست
- تعریف مدل کسب‌وکار، قواعد قیمت‌گذاری، کارمزد و سقف‌ها روی کاغذ
- طراحی دفترکل و وضعیت‌های هر نوع تراکنش، پیش از طراحی هر صفحه
- ساخت هسته: حساب‌ها، قیمت، خرید و فروش، واریز و برداشت و پنل مدیریت
- ساخت اپلیکیشن کاربر روی همان هسته
- تست جدی روی محیط جدا: سناریوی خطا، درخواست هم‌زمان، قطع شدن منبع قیمت
- راه‌اندازی آزمایشی با تعداد کم کاربر و سقف پایین معامله
- گسترش تدریجی، پایش و بهبود بر اساس رفتار واقعی کاربران
بسیاری از پروژه‌ها مرحله‌های سوم تا پنجم را کوتاه می‌کنند چون «از بیرون دیده نمی‌شود». ولی همین مراحل تعیین می‌کند اولین ماه فعالیتتان آرام می‌گذرد یا با شکایت و اصلاح حساب.
۱۰. اشتباه‌هایی که گران تمام می‌شود
- شروع از طراحی ظاهری و رسیدن به دفترکل در انتها
- ذخیره‌ی مبلغ و وزن به‌صورت عدد اعشاری
- نبودن کلید یکتا برای درخواست‌های مالی و مغایرت‌گیری دوره‌ای
- تعریف نکردن رفتار سیستم هنگام قطع یا اشتباه‌شدن قیمت
- فرض‌کردن پنل مدیریت به‌عنوان کار فرعی
- ساخت دارایی‌ها به‌صورت ستون ثابت (مثلاً یک ستون «طلا»)، که اضافه‌کردن نقره یا سکه را دردناک می‌کند
- آزمایش تغییرات مستقیم روی داده‌ی واقعی
- جدی نگرفتن هزینه و زمان پشتیبانی بعد از راه‌اندازی
- انتخاب سازنده فقط بر اساس کمترین قیمت یا زیباترین نمونه‌ی طراحی
۱۱. از سازنده چه بپرسید
قبل از امضای هر قراردادی، این سؤال‌ها را بپرسید. جواب‌دادن به آن‌ها برای کسی که واقعاً چنین سیستمی ساخته راحت است:
- آیا پلتفرم طلای فعال با کاربر و تراکنش واقعی دارید که بتوانم ببینم؟
- دفترکل را چطور طراحی می‌کنید و مغایرت‌گیری چطور انجام می‌شود؟
- با چندبار ارسال یک درخواست مالی چه می‌شود؟
- اگر منبع قیمت قطع شود، سیستم چه رفتاری دارد؟
- کد و دیتابیس مال کیست و در پایان کار چه چیزی تحویل می‌دهید؟
- بعد از راه‌اندازی چه کسی جوابگوست و پشتیبانی چگونه تعریف شده؟
اگر در حال تصمیم‌گیری برای ساخت چنین پلتفرمی هستید، می‌توانید با ما تماس بگیرید. نمونه‌های اجراشده را در صفحه‌ی نمونه‌کارها ببینید و درباره‌ی دامنه‌ی کارتان صحبت کنیم. حتی اگر در نهایت با ما کار نکنید، پرسیدن همین سؤال‌ها از هر سازنده‌ای شما را از بیشتر خطاهای گران محافظت می‌کند.
پلتفرم طلا را با ظاهرش نمی‌شود قضاوت کرد. با چیزی قضاوت می‌شود که در لحظه‌ی شلوغی و خطا انجام می‌دهد.
مطلب مرتبط با
قیمت‌ها و ساخت سفارشی ←