Ecommerce development in Bangladesh: price the operating system, not the storefront.

The USD figures use the Bangladesh Bank average exchange rate of BDT 123.6969 per USD for 22 July 2026 and are rounded to the nearest $500. BDT remains the source of truth. Platform subscriptions, paid apps, payment fees, messaging, hosting, and consumption-based services remain separate unless a proposal names a temporary allowance.

New builds and substantial feature engagements start at BDT 1.5 lakh. A store audit, analytics review, checkout diagnosis, performance investigation, or small maintenance request can be quoted separately without forcing it into a build tier.

Choose Shopify when standardization is commercially helpful. Its managed core can shorten launch and reduce infrastructure responsibility, while custom themes, extensions, and integrations still allow differentiation. Confirm that required checkout behavior, markets, payments, product rules, and applications work on the intended plan before committing.

Choose WooCommerce when publishing and commerce need to share WordPress, the team values ownership of the application, and the operational requirements fit a maintainable extension set. More control also means responsibility for hosting, updates, plugin compatibility, security, performance, backups, and incident response.

Choose custom engineering when the operation itself is the product advantage or when forcing the workflow through extensions would create brittle dependencies. Custom does not mean rebuilding commodity capabilities without reason; it can combine a platform for standard commerce with purpose-built services for the differentiated domain.

Binnash scopes implementation through its ecommerce engineering service . Compare a content-led store with the WordPress and WooCommerce guide , and use the general software cost guide when commerce is only one part of a larger product.

Define products, variants, bundles, options, collections, attributes, price lists, stock states, media, downloadable assets, and relationships. A merchant with 20 configurable products can have more modeling work than one with 5,000 simple SKUs. Product information arriving from spreadsheets, suppliers, an ERP, or several teams needs ownership and validation rules.

Discovery includes navigation, search, filters, sorting, synonyms, empty-result handling, recommendations, and merchandising controls. Agree which attributes are filterable, how URLs behave, what must be indexable, how out-of-stock products appear, and who can tune results. Large or rapidly changing catalogues may require a dedicated search service and synchronization monitoring.

Migration should define transformations, duplicate policy, image handling, variants, customers, consent, orders, redirects, reviews, and reconciliation. Content cleanup and product enrichment are business work even when engineering provides import tooling. A sample migration early in the project reveals more than counting rows.

Payment integration includes more than opening a hosted payment page. Scope success and failure returns, signed webhooks, duplicate events, delayed confirmation, abandoned orders, reconciliation, partial and full refunds, chargebacks, and support visibility. Payment gateway fees and settlement terms belong to the merchant, while Binnash can implement and test the agreed integration.

For Bangladesh-facing checkout, options may include a direct mobile financial service integration such as bKash, an authorized payment gateway such as SSLCOMMERZ, cards, bank payments, and cash on delivery. Availability depends on merchant onboarding and the provider’s current product. Budget sandbox work, production credentials, transaction validation, callback or IPN handling, refunds, settlement reconciliation, courier status, failed delivery, and returned cash-on-delivery orders as connected operational states.

Promotions need precedence and examples. “Buy two, get one,” category exclusions, customer-specific price lists, coupon stacking, free-shipping thresholds, and partial returns can interact in surprising ways. Write representative baskets and expected totals before implementation; they become acceptance and regression cases.

Integration-heavy projects become expensive when systems disagree and nobody owns resolution. The scope should identify each system of record, synchronization direction, timing, duplicate handling, retry policy, alert, and manual recovery path. A dashboard that exposes failed orders can be more valuable than another automated retry.

Operational users need deliberately designed tools. Bulk actions, exports, reprocessing, stock correction, refund approval, order notes, and customer communication require permissions and audit history. Leaving these workflows to direct database access creates avoidable launch risk and support cost.

Google’s Core Web Vitals provide useful user-experience thresholds for loading, responsiveness, and visual stability, but a launch plan also needs representative devices, network conditions, catalogue pages, search results, cart, and checkout. Synthetic scores cannot replace real-user monitoring after traffic arrives.

Analytics scope should name the decisions the data supports. Define product views, search, promotion exposure, add-to-cart, checkout stages, payment outcomes, refunds, consent behavior, campaign attribution, and server-side events where appropriate. Test identifiers and revenue totals against the commerce source rather than assuming a tag firing means correct measurement.

Peak planning needs an expected traffic shape, marketing events, catalogue update behavior, cache strategy, integration capacity, rate limits, and a response owner. The platform may absorb infrastructure scaling while an app, custom service, search provider, or ERP remains the bottleneck.

A proposal should state the catalogue sample, platform and plan, environments, integrations, migration volume, design responsibility, analytics, performance approach, client-supplied content, acceptance cases, launch sequence, and handover. The included 90 days cover defects against accepted scope and launch stabilization—not continuing merchandising, content operations, provider changes, or a new roadmap.

Defined projects use scoped milestone pricing. Monthly product-engineering support is available for continuous experimentation, operations, and roadmap work, but no public monthly rate is presented because the required team and responsibility differ. The engagement should still define outcomes, cadence, access, and service boundaries.