Blog

How much user research before you build?

How much user research to do before building an app or web product in Bangladesh: which assumptions to test, how to interview in Dhaka, and when to stop.

Kazi Lotus11 min read

A magnifying glass reads what a shopkeeper said on a phone call before the app’s blocks are stacked, and the top block is still faint.

The cheapest place to be wrong about a product is before anyone has built it. If you are about to pay for a build, the question is not whether to do user research before building a product but how much: which assumptions to test, with whom, at what cost, and when to stop. No Scaledex client work appears below; the named cases are public and in the third person, the worked example is a hypothetical we label as one, and the judgement is ours.

Below, we walk through research priced as insurance, which assumption to test, how a round is run in Dhaka, the demand test Bangladesh already runs on Facebook, what research does not fix, and what to bring to an agency.

User research before building a product, priced as insurance

We price research before a build as a premium against building the wrong thing, and the premium is small because it is a fixed fraction of the build. Insuring a shipment works the same way: you never pay more for the policy than the crate is worth, and you insure the crate that would sink you.

A discovery round is the policy, and what it pays out is the option not to build. In the worked example of our website cost post, scope and discovery came to ৳60,000 of a ৳580,000 build, about a tenth.

A round of interviews sits inside that line and takes days for a marketing site, one to two weeks for a product. If the round kills the build, nine-tenths stayed in your account.

What is user research?

The first page defines it as the systematic study of what users need, do and think: true, and useless to a buyer. User research is the cheapest way to be wrong about any belief behind a build; a phone call to a future user costs an afternoon, and the code costs lakhs. In product management, the list of those beliefs is the roadmap.

Is market research the same as user research?

No, and buyers often pay for the wrong one. Market research sizes the market: how many households in Uttara order groceries online and what they spend. User research tells you whether these particular people will change what they do today, whether a shopkeeper who keeps stock in his head will type it into your app, and that has to be asked, in Bangla, one person at a time.

None of the first page’s method lists says how to find eight interviewees in Dhaka or how much research fits a build priced in lakh. The question is which assumption to insure, and that is a question about money at risk.

The assumption whose being wrong costs the most

Not every assumption deserves a test; the one to test is the one whose being wrong wastes the most build money and can be checked cheaply. Put two prices on each belief: what the build loses if it is false, and what it costs to find out. Skip where the wrong answer is cheap to fix after launch.

Take a hypothetical founder, Rumana, holding a quote of ৳20 lakh ($16,260) for a grocery delivery app in Uttara. Dollar figures use ৳123 to US$1, rounded from Bangladesh Bank’s interbank weighted average of 24 August 2026. Her quote rests on three assumptions. First, that households want groceries delivered: if that is false the whole quote is wasted, but a Facebook page tests it for the price of boosted posts.

Second, that shop owners will keep their stock accurate in her app: the shop-side module is about a quarter of the build, wrong orders lose customers, and ten phone calls to shopkeepers would settle it in a week. Third, that customers will pay by bKash rather than cash on delivery: if she is wrong, adding cash on delivery takes a week, not worth an interview.

An older form of the second assumption sank Chaldal’s first model: the Dhaka grocery service relied on local stores’ stock with no way to see it. In 2015 its co-founder Waseem Alim told TechCrunch what went wrong: a customer would order two litres of Coke, the store had one, and there was no way to tell them. A lot of customers did not come back, and that March Chaldal moved to its own warehouses. The figure below puts Rumana’s three assumptions on the two prices.

Which assumption to test first Rumana's delivery app: build money at risk if the assumption is wrong, against the cost of finding out. ৳0 ৳5 lakh ৳10 lakh ৳20 lakh build money at risk if wrong TEST BEFORE YOU SCOPE SPLIT THE BUILD, TIME-BOX A SPIKE ASK IN PASSING SKIP, FIX AFTER LAUNCH A households want delivery — ৳20 lakh; a Facebook page B shops keep stock accurate — ৳5 lakh + lost customers; ten calls C customers pay by bKash — a week of changes; ask in passing a few calls, a Facebook page a paid study, a built prototype cost to find out → Dots are the worked example's three assumptions; the taka values are the article's illustrative figures, not measurements.
Two of Rumana’s three assumptions earn a test, and neither needs a lab: one needs a Facebook page, the other ten phone calls. The third is cheaper to be wrong about than to research.

Only the top-left corner earns a test before scoping. Putting it simply: research what would make you cancel the build, not what you would fix in a sprint. The verdict on her second assumption, though, belongs to shopkeepers in Uttara, not to a panel in a lab.

How a research round gets done in Dhaka

The people who can kill your assumption are already in Facebook groups and Messenger threads, and that is where we would recruit. Rumana needs no recruiting agency, only the Uttara buy-and-sell group, a traders’ page and a message that says what she wants and what she will pay.

Interviews happen in Bangla, by phone or Messenger call, after closing time. The thank-you is a bKash or Nagad send-money at the end of the call, sized to an hour of that person’s time rather than a flat rate.

Why “yes, I’d use that” means nothing here

The failure that sinks most local interviews is courtesy. Asked whether they would use your app, people say yes because you are a guest; survey researchers call it courtesy bias.

Jakob Nielsen put the general case bluntly in 2001: pay attention to what users do, not what they say, because people bend the truth toward what they think you want to hear, and their guesses about their own future behaviour are unreliable. A question about the future invites a courtesy; a question about last Tuesday gets a fact.

Rob Fitzpatrick’s The Mom Test, a book on how to talk to customers when everyone is lying to you, reduces it to three rules: talk about their life, not your idea; ask about specifics in the past, not opinions about the future; talk less. Rumana asks a shopkeeper when he last counted stock and what the last wrong order cost him, never whether he would use an app.

Then she asks for a commitment instead of an opinion: tonight’s stock list on WhatsApp, or a small deposit against the first week of orders. A yes that costs the person something is data; a compliment is data about your manners, not your market. Some assumptions, though, can only be tested with a sale, and Bangladesh has a way of making one without software.

How to validate a business idea before you build it

The cheapest validation in Bangladesh is a business you can run without software: a Facebook page, orders by Messenger, payment by bKash, delivery by hand. The country already runs this test at scale: in 2024 e-CAB’s executive director, Jahangir Alam Shovon, estimated that some 60,000 F-commerce pages were generating regular sales. Each is a product test that never needed a developer. A Facebook page for Uttara is the smallest form of that test: its boosted-post budget is the price of the answer, and two weeks of it settles Rumana’s first assumption.

Our rule is to commission software when the manual version breaks, and the breaks are specific. Orders get missed in the Messenger inbox: that earns an order form and a catalogue, nothing more. The same item is sold twice: that earns a stock ledger, and only now does a shop-side module make sense. The figure below puts all four breaks in the order they usually arrive, with the module each one pays for.

When the manual shop breaks, and what each break buys Four signals in the order they usually arrive; nothing on the software row is bought before its break is felt. THE MANUAL SHOP Facebook page Messenger orders bKash payment Delivery by hand THE BREAK, IN ORDER OF ARRIVAL → 1 orders missedin the inbox 2 the same itemsold twice 3 “where is my order?”all evening 4 bKash statement≠ order list order form+ catalogue stock ledger+ shop-side module order tracking+ SMS reconciliation+ payment integration THE SOFTWARE IT EARNS a break you have felt the module it pays for Break 2 is where the worked example's shop-side stock module, about a quarter of its quote, becomes worth scoping.
Nothing on the bottom row is bought before its break has been felt. The order of the breaks is the order of the build.

The scope then arrives with evidence instead of a wish list. You are not building a minimum viable product; you are running a shop that tells you which software to buy, in what order. The page proves demand and orders the build; it does not tell you when to stop asking.

What research does not fix, and when to stop

Discovery finds the problem; it does not design the product, and it does not replace testing the built thing with users. Jakob Nielsen’s finding that five participants find 85% of the usability problems, published in 2000, is about usability tests of a design that exists. It says nothing about how many shopkeepers to interview before a design exists.

A 2022 systematic review by Monique Hennink and Bonnie Kaiser found that studies reached saturation within 9–17 interviews, particularly with a homogenous group and a narrow question, which describes Uttara’s shopkeepers. Our operating rule is simpler: when the last three interviews add no new problem, stop. The figure below keeps the two questions apart.

Two questions, two moments Discovery interviews before the scope; usability tests on the built thing. The five-user figure belongs on the right. Before the scope: discovery interviews Who shopkeepers, 9–17 until saturation Stop when the last three add no new problem Ask past behaviour, present workarounds Out a findings note, then a scope “five users find 85%” does not apply here decides whether, and what, to build the build scope → design → code On the built thing: usability tests Who five participants per round Result about 85% of usability problems found Then fix, test again with five more Out a checkout people can finish watched, on a prototype or the live app decides whether what was built works Left: Hennink & Kaiser, 2022 systematic review (saturation within 9–17 interviews). Right: Nielsen, 2000 (five participants, 85% of usability problems). Our stopping rule (last three add nothing) is an operating rule, not a measurement.
Two different questions at two different moments. Nielsen’s five-user figure lives in the right-hand box only; the first page of results puts it in both.

The left box decides what to build and the right whether it works; skipping the right because you did the left is how a well-researched product still ships with a checkout nobody can finish.

The opposite failure is as real: a six-month research phase spends the same money as a wrong build, and the premium has exceeded the crate. Research is proportionate when it costs about a tenth and ends on a decision, in a one-page note.

What to bring to the agency

A round that arrives as a one-page findings note shortens discovery, because the scope document consumes exactly that shape. Here is the sheet we would hand her.

The ten-question script, past and present tense only; the last two ask for a commitment and recruit the next call.

  • Tell me about the last time you ran out of something a customer wanted.
  • How do you keep track of stock today?
  • When did you last count it, and what made you count?
  • What did the last wrong or missed order cost you?
  • Who else touches stock or orders?
  • What have you tried to fix this, and why did you stop?
  • What did that attempt cost you?
  • Who do you call when it goes wrong?
  • If I send you a stock sheet tonight, will you fill it in? Then send it.
  • Who else should I be talking to?

The recruiting message, for a group post or Messenger:

আসসালামু আলাইকুম। আমি [নাম]। [এলাকা]-র দোকানদারদের সাথে কথা বলছি — আপনারা স্টক আর অর্ডার এখন কীভাবে সামলান, তা বুঝতে চাই। কিছু বিক্রি করছি না। ফোনে বিশ মিনিট সময় দিতে পারলে সময়টার জন্য বিকাশে সম্মানী পাঠাব। কখন সুবিধা হবে?

Hello, I’m [name]. I’m talking to shop owners in [area] about how you handle stock and orders today; I’m not selling anything. If you can spare twenty minutes on the phone, I’ll send a thank-you by bKash for your time. When would suit you?

The findings note, one page:

  • The assumption in one sentence, and the verdict: kept, killed or changed.
  • Who you spoke to, how you found them, what you paid.
  • What they do today instead, in their words, and what it costs them.
  • Commitments obtained: stock sheets sent, deposits taken.
  • What is still open.

Next from us: a printable version of this sheet, and a post on turning a findings note into a scope. If your Facebook page breaks in a way we did not name, tell us. The first step is tonight’s: write your three assumptions as sentences a stranger could disagree with, ranked by the build money each puts at risk.

If the top one needs a round you would rather not run yourself, our UX design service starts there; mobile app or PWA covers the decisions it feeds. In two weeks you will have either a scope built on what shopkeepers actually do or a page with its first orders, and both beat a quote as a place to start.

  • user-research
  • product-strategy
  • startups
  • bangladesh