We wrote before about why most Bangladeshi businesses still run on spreadsheets, and the honest answer includes a hard truth: a lot of them got burned trying to fix it. A six-month project that took fourteen, a vendor who vanished after the deposit cleared, software nobody on staff actually uses. If you're evaluating a software partner in Bangladesh right now, the fastest way to avoid repeating that story is to know exactly what to ask before you sign anything — not after the first missed deadline.
Ask to see working software before you sign, not after
The single biggest predictor of whether an engagement will go well is whether the vendor can show you something real before the contract is signed — a past project you can click through, a live demo, a reference client willing to talk. A polished pitch deck describing what will eventually get built is not evidence of anything except the ability to make a deck. Ask specifically: "can I talk to a current client, and can I see something you shipped that's live in production right now, not a mockup?" A vendor who hesitates on that question is telling you something.
Insist on seeing something real within the first two weeks
A healthy engagement doesn't start with six weeks of requirements workshops and a document. It starts with a scoped plan in week one and something you can actually click through — even if incomplete — by the end of week two. That's not a nice-to-have pace, it's a diagnostic: it tells you within days, not months, whether the team behind the proposal can actually build, and it means every subsequent sprint is informed by your real feedback on real software instead of a hypothesis from a kickoff call.
Get clear, in writing, on who owns the code and infrastructure when it ends
This is the question that separates a partner from a trap. Some vendors structure engagements so the client never gets full ownership of the repository, the hosting account, or the deployment pipeline — which means the relationship can't end without the client losing access to their own system. Ask directly: at the end of this engagement, do we own the code outright, can we take it to another developer, and do we control our own infrastructure accounts? If the answer is vague, that vagueness is the business model.
Watch for open-ended retainers dressed up as flexibility
An open-ended monthly retainer with no fixed scope sounds flexible, but it inverts the vendor's incentive: they get paid for time spent, not outcomes shipped, which quietly rewards a slower pace and a longer engagement. A fixed-scope, sprint-based engagement with a defined endpoint aligns the incentive the other way — the vendor's interest is in finishing and handing over a working system, because that's what triggers the next engagement or the referral. Neither structure is universally wrong, but know which one you're signing, and be skeptical of a retainer proposed before any scope has been defined at all.
Ask what exception paths they're explicitly not handling in version one
Every real workflow has exception cases — the deal reassigned mid-pipeline, the document missing a signature, the customer without the usual identifying information. A vendor who's actually thought about your business will be able to name specific exceptions they're deliberately deferring past v1, and why. A vendor who says "we'll handle everything" without being able to name a single edge case hasn't looked closely enough at how your business actually runs — they're describing the 80% path and hoping the other 20% doesn't come up in the demo.
A quick checklist before you sign
- Can they show a live, current production system — not a mockup — and connect you with a reference client?
- Will you see working software, not just a document, within the first two weeks?
- Is full code and infrastructure ownership explicit and in writing at engagement end?
- Is the engagement fixed-scope with a defined endpoint, or an open-ended retainer with no natural finish line?
- Can they name specific exception paths they're not handling in v1, showing they've actually mapped your workflow?
- Do they understand data residency and compliance requirements relevant to your industry, before architecture is decided rather than after?
None of this is unique to Bangladesh — it's the same due diligence that protects a buyer anywhere. It matters more here because the trust deficit from past bad engagements is real, and it means a good vendor has to actively prove they're not the pattern you've heard about, not just claim to be different.