Should we choose a local company or work remotely?

Time zone overlap matters more than geography. A few hours of shared working time is usually enough, and being in the same city has become a weak signal. Where local presence genuinely counts is on-site discovery, hardware work and field pilots - and those are specific phases you can plan for rather than a reason to restrict the whole search.

How important is sector experience?

Useful, and often overrated. Domain experience shortens discovery and means fewer obvious mistakes. It can also mean a supplier builds you the last client's system. Good questions are a better signal than a matching logo.

Is a fixed-price contract safer?

Safer against overspend on a scope that is genuinely understood. On unclear scope it is worse - the price gets padded for risk, and every change becomes a contractual negotiation at exactly the point the project needs flexibility.

What should be in the contract?

Code ownership, repository access from day one rather than at the end, documented deployment, your accounts in your name, a defined support period, and what happens if either side wants to stop. Anything that makes leaving difficult is a term working against you.

Buying software

How to Choose a Software Development Company

Most selection processes test the wrong things. Here are the questions that actually predict whether a build succeeds - including several we would rather you did not ask us.

19 September 2026 8 min read Plexowave

We are one of the companies you might be evaluating, which makes this article self-serving by construction. The mitigation is to include the questions that are awkward for us, and to be explicit about where a larger firm or a freelancer would serve you better. Judge the article on whether it holds up when applied to us.

What most selection processes test, and why it fails

The usual process compares portfolios, team size, technology lists and price. None of these predict much.

Portfolios show what was shipped, not whether it was on time, whether the client would buy again, or whether it still works. Screenshots are the easiest part of a project to produce and the least correlated with success.

Team size predicts capacity, not quality, and beyond a point it predicts coordination overhead. Technology lists are close to meaningless - every agency lists every technology, and what matters is whether the specific people on your project know the specific stack well.

Price we have covered elsewhere. The short version is that the lowest quote is usually the least complete one.

Questions that actually predict the outcome

Can you describe our business back to us?Ask this at the end of the first conversation. A supplier who has understood the problem can restate it in their own words, including the part that makes it awkward. One who cannot will build what you literally said, which is never quite what you meant.
What would make you turn this project down?Everyone who has been burned has an answer: no internal owner, a deadline set before the scope, a client who will not make decisions. A supplier with no criteria for declining work has either been lucky or is not being straight with you.
Who specifically will write this, and what else are they on?The people in the pitch are often not the people on the project. Ask for names and current commitments. This single question eliminates a whole category of disappointment.
Show us something you got wrong and what you changed.Every real project has one. An answer that is specific, technical and slightly uncomfortable tells you they reflect on their work. A polished answer about 'communication' tells you they have prepared for this question and nothing else.
What happens to the code and the accounts if we part ways?The answer should be structural: you own the repository, the deploy is documented, the stack is mainstream, your cloud and store accounts are in your name. If any of that is held by the supplier, you are buying a dependency rather than software.
How will we know it is going badly, and when?Good suppliers have a mechanism - working software at a fixed cadence, a demo you attend, a burn-down you can read. If the first real visibility is at delivery, the risk sits entirely with you and you will find out too late.

Warning signs worth walking away from

A quote arriving without any questions about your data. The data model is where the cost lives; a number produced without asking about it was produced without thinking about it.
Agreement with everything. A supplier who never pushes back is either not listening or is planning to bill for the rework.
No mention of migration, testing or a parallel run. This work exists whether or not it is quoted, and if it is missing from the quote it will arrive as a variation.
A demo that cannot be clicked. If the only evidence is screenshots and a video, ask for access to something real. There is a reason that is not being offered.
Pressure to sign before discovery. Discovery is where both sides find out whether the project is what they think it is. Skipping it benefits nobody except a supplier who suspects the answer.
Reluctance to name the individuals who will do the work, or to let you speak to them.

When a studio is the wrong choice

We are a small studio. That suits projects where the value is in understanding the domain properly, where you want the people who designed it to build it, and where direct access to the engineers matters more than process weight. It is the wrong shape for several situations, and saying so is cheaper for everyone than discovering it at month four.

If you need a hundred people on the ground for a two-year programme, you need a systems integrator, and the things that make a small studio good are irrelevant at that scale.

If the work is a well-defined, short, self-contained task - a WordPress theme, a one-page site, a small script - a competent freelancer will do it faster and cheaper, and you should not pay studio overhead for it.

If your organisation requires a named 24/7 support desk with contractual response times and a formal escalation path, ask directly what is actually provided rather than accepting a reassurance. This is a real requirement and small teams often cannot meet it honestly.

Check the references properly

Reference calls are usually wasted, because the questions invite a positive answer. 'Were you happy?' gets 'yes' from almost everyone, including people who would not buy again.

Ask instead: what was the biggest disagreement and how was it resolved; what did the project cost compared to the first estimate, and why; what did you have to do that you had not expected; and would you use them for something larger. That last question is the one whose hesitation is informative.

Ask for a reference in your sector if the supplier claims sector experience, and ask a client whose project finished at least a year ago. Recent clients are still in the glow. A year later they know whether the software still works and whether changes are still possible.

The one thing that predicts success most

Not the supplier. Whether your side has one person with the authority to decide and the time to engage. Projects with a real owner succeed with mediocre suppliers; projects without one fail with excellent suppliers, because every decision becomes a committee and every ambiguity becomes a delay.

If you cannot name that person and protect their time, fix that before selecting anyone. It will change the outcome more than any choice on this list.