Protocore
যোগাযোগ করুন

তুলনা / Build vs Buy

Build বনাম buy: আপনার core banking stack

সৎ উত্তর হলো, কোনোটিই ডিফল্টভাবে জেতে না। Build করলে পুরো নিয়ন্ত্রণ মেলে, সঙ্গে অনির্দিষ্ট বিল; buy করলে গতি মেলে, সঙ্গে এমন একটি সীমা যা আপনি ঠিক করেন না। আসল প্রশ্ন হলো কোন ঝুঁকিগুলো আপনি নিজের হাতে রাখবেন — আপনার কোডের ঝুঁকি, নাকি অন্যের roadmap-এর ঝুঁকি।

আলোচনা করুনProtocore Pay দেখুন

পাশাপাশি তুলনা

যে পাঁচটি দিক আসলে সিদ্ধান্ত নেয়

Dimension
ইন-হাউসে build করুন
Platform কিনুন
Time to market
প্রথম আসল transaction-এর আগে 12–24 মাস: ledger, account, reconciliation ও card rail — একজন গ্রাহক onboard হওয়ার আগে সবই আপনাকে design করতে, লিখতে ও প্রমাণ করতে হবে।
পাইলট পর্যন্ত কয়েক সপ্তাহ। Ledger, account ও rail আগে থেকেই আছে এবং ব্যবহারে যাচাই করা, তাই প্রথম transaction একটি configuration-এর কাজ, build নয়।
Control ও নমনীয়তা
পুরোপুরি। প্রতিটি table, প্রতিটি state machine, প্রতিটি edge case আপনার হাতে — পণ্য বদলালে নতুন করে গড়ার দায়ও আপনার।
Platform-এর model দ্বারা সীমিত। সে যা expose করে, তা-ই পান; বাকি সবই অন্যের roadmap-এ একটি feature request।
Compliance-এর পরিধি
পুরো পরিধি আপনার: audit trail, data residency, key management এবং review-এ চাওয়া প্রমাণ — সবই design করতে ও রক্ষা করতে হবে।
পরিধির বড় অংশ আসে এমন platform থেকে যা আগে থেকেই তা পরিচালনা করছে — তবে ব্যবহার কীভাবে করছেন তার দায় আপনার, আর নিজের controls-এর পাশাপাশি তাদের controls-ও বিশ্বাস করতে হয়।
Maintenance ও on-call
স্থায়ী একটি team। Ledger কখনো 'শেষ' হয় না — যতদিন চলে, ততদিন patch, migrate, monitor করতে হয় এবং on-call থাকতে হয়।
মূলত vendor-এর দায়িত্ব। Upgrade, uptime ও বেশিরভাগ incident আপনার team-এর কাঁধ থেকে নামে — বিনিময়ে তাদের গতি ও তাদের status page-এর ওপর নির্ভর করতে হয়।
খরচের ধরন
শুরুতে ভারী ও স্থির — বেতন আর বছরের পর বছর — তারপর live হলে প্রতি account-এ marginal cost কম। আপনি একটি asset কিনছেন, সঙ্গে তার liability-ও।
শুরুতে হালকা, পরে recurring — ব্যবহারের সঙ্গে বাড়া license বা revenue-share। অনুমানযোগ্য, কিন্তু কখনো শূন্য নয়, আর নির্ধারণ করে vendor।
01

যখন build জেতে

Core-ই যখন পণ্য, তখন build করুন। আপনার স্বাতন্ত্র্য যদি ledger-এই থাকে — নতুন ধরনের settlement model, যে asset class কেউ সাপোর্ট করে না, বা সাধারণ platform যে latency budget ছুঁতে পারে না — তাহলে প্রতিটি লাইনের মালিক হওয়াই লক্ষ্য, বাড়তি বোঝা নয়। বেশিরভাগ team-এর যা থাকে না, সেই বিরল সুবিধা থাকলেও build জেতে: core-কে এক দশকের প্রতিশ্রুতি হিসেবে দেখে এমন একটি funded, স্থায়ী engineering team, এবং প্রতিদ্বন্দ্বী গ্রাহকের কাছে পৌঁছানোর আগে compliance অর্জনের মতো যথেষ্ট runway।

  1. 01আপনার সুবিধা ledger-এ — এমন settlement বা asset model যা কোনো platform দেয় না
  2. 02বছরের পর বছর on-call চালানোর জন্য funded একটি স্থায়ী team আছে, শুধু launch sprint-এর জন্য নয়
  3. 03নিয়ন্ত্রক বা data-residency বাধ্যবাধকতার কারণে অন্য কারও core-এ চালানো সম্ভব নয়
  4. 04Time-to-market সত্যিই বাধা নয়
শব্দকোষ: core banking পরিভাষা
02

যখন buy জেতে

Time-to-market যখন বাধা এবং core যখন table stakes, তখন buy করুন। বেশিরভাগ fintech পণ্য ledger দিয়ে জেতে না — জেতে app, distribution, onboarding আর niche দিয়ে। Core যদি এমন কিছু হয় যা গ্রাহকেরা ধরে নেন, আপনাকে বেছে নেওয়ার কারণ নয়, তাহলে তা বানাতে খরচ হওয়া প্রতিটি মাস সেই কাজ থেকে হারানো মাস যা সত্যিই জেতায়। স্থায়ী core team রাখতে না পারলে, বা অনির্দিষ্ট খরচের চেয়ে নির্দিষ্ট জানা খরচ ব্যবসার কাছে মূল্যবান হলেও buy জেতে।

  1. 01Core table stakes; আপনার সুবিধা app, audience বা distribution-এ
  2. 02কয়েক সপ্তাহে পাইলট দরকার, প্রথম transaction-এর জন্য কয়েক quarter অপেক্ষা করা যায় না
  3. 03অনির্দিষ্ট build-and-maintain বিলের চেয়ে জানা recurring খরচ আপনার পছন্দ
  4. 04আপনার স্থায়ী ledger team on-call নেই — বা আপনি চান না
Banking licence কি দরকার?
03

নিজের core-এর ওপর platform কোথায় মানায়

Build-vs-buy বিভাজনের আড়ালে একটি তৃতীয় পথ আছে: core কিনুন, app নিজের রাখুন। Whitelabel platform আপনাকে দেয় ইতিমধ্যে চালু ledger, account, card ও crypto — ফলে আঠারো মাসের build এড়ানো যায় — আর গ্রাহক যা সত্যিই দেখেন সেই surface থাকে আপনার team-এর হাতে। প্রতিটি screen আপনার designer-দের, feature mix আপনার product team-এর, আর নিচের platform প্রথম গ্রাহক আসার আগেই যাচাই করা। যা table stakes তা আপনি পান, যা আপনার নিজের তা রেখে দেন। এটি সবসময় উত্তর নয় — আপনার সুবিধা ledger-এ হলে build করুন — তবে বেশিরভাগ পণ্যের জন্য এটাই সৎ মধ্যপথ: সাধারণ app ছাড়া platform-এর গতি, আর স্থায়ী team-এর বদলে ব্যবহারের সঙ্গে চলা খরচ।

  1. 01Core build এড়ান; app, brand ও feature mix নিজের রাখুন
  2. 02Production demo-তে যাচাই করা ledger, নতুন করে প্রমাণ করার greenfield নয়
  3. 03খরচ নির্ভর করে চালানো account ও module-এর ওপর, স্থায়ী headcount-এর ওপর নয়
  4. 04Standalone বা পুরোপুরি whitelabel — আপনার brand-এ, না-লেখা rail-এর ওপর
Protocore Payগ্লসারি

কোন পক্ষে আছেন নিশ্চিত নন?

কী বানাচ্ছেন এবং ছয় মাস পরে কী সত্যি হওয়া চাই, আমাদের জানান। Build, buy, নাকি আপনার না-লেখা core-এ app চালানো — সে বিষয়ে আমরা সৎ থাকব।

আলোচনা করুনcontact@protocore.io