← All posts

Seven questions to ask before you pay for custom software

If you've never commissioned software before, the hard part isn't choosing between quotes. It's that two quotes for "an inventory system" can differ by ten times in price and both be reasonable, because they describe completely different things.

These are the questions that surface what you're actually buying. Ask them of anyone you're considering — including us.

1. Who owns the code when it's finished?

The answer should be you, in writing, in the agreement. Not "you have a licence to use it." Not "we host it for you."

The practical test: if you fell out with this developer next year, could you hand everything to someone else and carry on? If the answer involves them exporting something for you first, you don't own it in any way that matters.

Ask specifically about the source code, the database, the domain, and the hosting accounts. All should be in your name.

2. What happens if you disappear?

Small development shops close. People take other jobs. This isn't an accusation, it's planning.

What you want to hear: the code is in a repository you have access to, the accounts are yours, and there's documentation good enough for another developer to pick it up. What should worry you: hosting on their personal account, no documentation, and everything only they understand.

3. What's not included?

More projects go wrong here than anywhere else. Get explicit answers on:

  • Data migration from whatever you use now
  • Training your staff
  • Bug fixes after launch, and for how long
  • Hosting and running costs, monthly
  • Changes after you've seen it working

That last one matters most. You will want changes once you use it — that's normal, not a failure. What you need to know is whether they're included, charged hourly, or a separate project.

4. Can I see something in two weeks?

Not a finished product. Something running that you can click.

A developer who can show you working software early is managing risk properly. One who wants three months before you see anything is asking you to trust that they understood you correctly at the start — and they may not have. That's not dishonesty, it's how requirements actually work: you don't know what you want until you see what you didn't want.

5. What are the ongoing costs?

Software has running costs: hosting, domain, SMS or email delivery, payment gateway fees, app store fees, backups. Some are small, some aren't.

Get a monthly figure before you commit. A quote that covers building it but not running it isn't a complete quote.

6. Have you built something like this before, and can I use it?

Not a portfolio screenshot — a URL you can open, or an app you can install.

Anyone can show you a design. Working software that real people use every day is a much harder thing to fake, and it tells you whether they finish what they start.

For example, ZoRide is a live regional ride-hailing and parcel-delivery deployment we built, not a concept screen or portfolio mockup.

7. What would you do instead of building this?

The most useful question, and the one that tells you most about who you're dealing with.

A lot of business problems don't need custom software. Sometimes an existing product at a few hundred rupees a month does the job. Sometimes it's a process change. Someone who has thought seriously about your problem will have considered those options and be able to explain why they don't fit — or tell you they do, and lose the sale.

If they've never seen a problem that didn't need custom software, ask yourself what that means.

The pattern

Every one of these is really the same question: if this goes wrong, what happens to me?

Good answers reduce your exposure — you own things, you see progress early, costs are known, you could leave. Bad answers concentrate risk with the developer and ask you to trust it'll be fine.

You don't need to be technical to tell the difference. You just need to ask before you pay.

If you already know a bespoke build is justified, read how we handle custom software development. If you are still deciding whether to build, buy, or change the process, start with software consulting.


Working through this for a project of your own? Tell us what you're trying to build — we'll give you our answers, and you can compare them with anyone else you're talking to.