Anything demos well for ten minutes. These are the questions that reveal whether a team can keep software working on a production store two years from now.
Choosing a development partner on the basis of a demo is like hiring a chef after tasting a photograph. Everything works when the person who built it is driving. These are the questions we would ask if we were on the buying side — and yes, we answer them for our own clients, which is the point of publishing them.
1. How do you know it works?
Not 'did you test it' — how. Ask for the shape of the verification: what is automated, what runs before each release, what is checked against live data. A team that tests by clicking through the admin will ship a regression into your production store eventually, and neither of you will notice for a week.
2. What happens the first time it breaks at 2am?
Who finds out, how, and how fast. Monitoring that tells the builder before the merchant finds out is the difference between an incident and an embarrassment. If the answer is 'let us know and we will look into it', you are the monitoring.
3. Who actually writes the code?
In agencies, the person in the pitch is frequently not the person on the keyboard, and never the person maintaining it in year two. Ask by name. With a small company you get a plainer answer, and that continuity is most of what you are buying.
4. What do you do when the requirement is wrong?
Clients often ask for a solution rather than the problem. A team that builds exactly what is asked, silently, will deliver something you do not use. The first deliverable of any good engagement is a plain restatement of the problem that the client agrees is the right one.
5. How do you handle Shopify's platform changes?
- API versions are deprecated on a schedule — who tracks them and who does the upgrade?
- Theme updates and Online Store changes can break integrations; is there a release process for a live store?
- App Store requirements shift, and a listing can be pulled for a compliance detail nobody read.
- Webhook reliability and rate limits are where naive apps quietly lose data at scale.
6. What will you hand over?
Source, deployment process, environment configuration, and documentation a different developer could pick up. The test is uncomfortable and fair: if you replaced this team next month, how long until someone else could ship a change safely?
7. Can you show the numbers, not the screenshots?
Ask what metric previous work moved and how it was measured. A portfolio of nice-looking pages proves design. Instrumented outcomes prove engineering.
At LeelaRam Technologies these are not hypothetical: every product ships with an automated suite and its own monitoring, the founder is the person on the keyboard, and measurement is built into the product rather than bolted on for a report. Whether you hire us or not, ask the seven questions.
