Commerce
Anyone can build a cart. What decides whether a store survives its first busy week is what happens when a payment webhook arrives twice, when a customer double clicks, and when a background job fails at three in the morning.
What is ecommerce development at The Cubas?
The Cubas builds custom ecommerce platforms including multi-vendor marketplaces, with vendor dashboards, payouts, coupons, refunds and audit trails. Order writes are protected with idempotency keys and a transactional outbox so a retried payment cannot create a duplicate order.
When people call us
Usually a business that has outgrown a hosted platform, needs vendor or marketplace logic the platform cannot express, or is bleeding margin on transaction fees that a custom build would pay back inside a year.
Built by
Ashraful Islam Hridoy, Lead Engineer
Ashraful builds the systems behind The Cubas engineering work, from typed REST APIs and data models to the React interfaces on top of them. His focus is the part most builds skip: secure access, reliable background jobs, and what happens to a system after launch.
What people search before they call
We rank for these ourselves. That is the shortest demonstration available that the search side and the build side are the same team.
How we approach it
Four decisions that separate a build which holds up from one that needs rescuing inside a year.
Every write that takes money carries an idempotency key, so a retried request resolves to the same order instead of a second one. On Buynux this is paired with a transactional outbox and an interleave test covering concurrent writes specifically.
Payouts, emails and inventory sync run as queued jobs with retry budgets. A job that cannot succeed surfaces rather than retrying forever against a downstream service that is already struggling.
Roles and permissions enforced at the API, not hidden in the front end. A route that deletes data checks who is calling it. This sounds obvious until you audit a store and find that it does not.
Sales and inventory reporting, generated invoices and an audit trail, so the people running the business can answer their own questions without a developer.
Deliverables
No tiered packages with features withheld to force an upgrade. Every engagement covers what the project genuinely requires.
Stack for this work
Evidence
Not a capability list. Systems in production, described by what was genuinely hard about each one.
ProductionEcommerce · 2025
Multi-vendor marketplace running in production
A bilingual storefront, vendor dashboards and an admin back office in one marketplace, running in production on its own domain.
ProductionEcommerce · 2025
Home and decor store, hardened after launch
A home and decor storefront with customer and admin dashboards, Chart.js reporting and PDF invoices, maintained in production across more than 200 commits.
Questions
When the business model does not fit the platform: multi-vendor payouts, unusual pricing logic, complex fulfilment, or integrations that need to run server side. For a straightforward single vendor catalogue, a hosted platform is usually the right answer and we will say so.
Idempotency keys on every write that takes payment, so a retried request resolves to the existing order rather than creating another. On larger builds this pairs with a transactional outbox, which keeps the order record and the downstream event from ever disagreeing.
Yes, and building both sides is the point. Product schema, faceted navigation that does not generate thousands of thin URLs, canonical logic for variants and a crawl budget that is not spent on filter combinations are architecture decisions, not a task for afterwards.
Other engineering services
Send the brief, the existing codebase or just the problem. We will tell you what it takes, what it does not need, and whether we are the right people for it.
Prefer to skip the form? Message us on WhatsApp or email yousuf@thecubas.com