Choosing a software development partner: eleven questions that predict the result

Every serious vendor arrives with a good deck, relevant logos and a number close to everyone else’s. The pitch is designed to be persuasive, so it is the wrong place to make the decision. What separates the engagement you will be glad about from the one you will manage is visible earlier, in how a team answers questions about the ordinary mechanics of building software.

What follows is the list we would use ourselves. It is written so you can put it in front of three vendors and compare like with like, and it is deliberately weighted towards the parts of an engagement that are hard to change once it starts: who does the work, how decisions get recorded, and what happens when the plan meets reality.

Four questions about the work itself

1. Who writes the architecture, and when do I see it?

The strongest signal a vendor can give you is a written system design before development begins — data model, service boundaries, integration points, the decisions taken and the alternatives set aside. It should arrive early enough to argue with. A team that starts coding while the shape of the system is still a conversation is asking you to pay for the argument twice.

A strong answer names a document, names when you get it, and offers an example from another engagement with the client details removed.

2. What will you show me in week two?

Two weeks is long enough to produce something real and short enough that nobody can hide in it. The answer to look for is a running deployment on a URL you can open, however narrow the slice. Screenshots and progress percentages are much easier to produce than a working environment, which is exactly why the working environment is the better test.

3. How does work reach production?

Ask for the path a single change takes from a developer’s machine to your users. You are listening for: a pull request, a review by a second engineer, an automated test run, a deployment that someone can reverse in minutes. A team that has this describes it in one breath because they do it forty times a week.

4. What does the handover look like on the last day?

Ask this in the first meeting, when nobody is thinking about endings. Good answers are specific: the repository is yours throughout, the infrastructure lives in your accounts, the documentation is written as the work happens, and a named engineer stays available for a defined window afterwards. This question tells you how a vendor thinks about your independence, which is a fair proxy for how they will behave for the whole engagement.

Three questions about the people

5. Which of the people in this room will be on the work?

The classic gap between pitch and delivery is the seniority of the team. Ask for names, ask what each person will own, and ask to meet the engineer who will write the first architecture document. It is a reasonable request and a straightforward one to grant.

6. How long have your engineers been with you?

Tenure is one of the few numbers in this industry that is hard to dress up. A team whose engineers have been together for years carries shared conventions, shared tooling and shared judgment, and your project inherits all three on day one. At Fluvius many clients have worked with us for seven years straight, and the same continuity holds inside the team.

7. What hours do we overlap, and how do I reach you between them?

Ask for the mechanism, not the promise: a shared Slack channel, a named person, an agreed response window, a weekly call that exists in the calendar before the project starts. We work European business hours with full US-morning overlap, which gives most clients a real four-hour window every day — enough to settle in an afternoon what would otherwise take three days of asynchronous messages.

Two questions about how AI is used

This is the newest part of the conversation and the part where the answers vary most. The useful distinction is between a team that uses AI as an instrument inside an engineering process, and one that uses it as the process.

8. Where does AI sit in your workflow, and what stays human?

A confident answer is specific about both halves. Ours: every change is specified before it is written, generated code goes through the same review, security check and test suite as anything else, and architecture, data modelling and security decisions are made by senior engineers who read and write the languages themselves. The gain is speed with the same standard applied — a fourteen-year-old backend rewritten from Go to Node.js in six months, work that would ordinarily take about two years, done by one senior engineer with AI leverage and a full review process around it.

9. Show me code your AI tooling produced and your review of it.

Ask to see a real pull request: the change, the review comments, the tests that came with it. A team that works this way has thousands of these and can show you one in a minute. It is the single quickest way to see the standard a vendor actually holds.

Two questions about change

10. What happens when the scope moves?

It will move. What you want to know is the mechanism: who assesses the change, how quickly you get a revised number, and whether the schedule is re-planned openly or absorbed quietly. Ask for a worked example from a real engagement — the answer will tell you whether change is treated as normal or as an exception to be managed around you.

11. Tell me about an engagement that went differently than planned, and what you changed afterwards.

Every ten-year-old firm has one. The vendors worth working with answer it directly, describe what they adjusted in their own process, and can point to the practice that exists today because of it. The answer is less about the story and more about whether the team examines its own work.

Scoring a shortlist

Put the three vendors in a table and mark each question as evidence, description or intention. Evidence is a document, a URL, a pull request, a named person. Description is a clear account of how they work. Intention is what they plan to do for you specifically.

A vendor who returns mostly evidence has done this many times. A vendor who returns mostly intention may still be excellent — and the gap is worth one more conversation before you decide.

Two things worth more than the shortlist

Independent verification. Reviews on a platform the vendor does not control are the closest thing to a public record. Ours are on Upwork, where the Job Success Score stands at 100%, and on Clutch at 4.9 out of 5.

A small paid piece of work first. A short, fixed, well-defined engagement teaches you more about a team than any number of calls: you see the questions they ask, the way they write, the speed of the first environment, and whether the person who pitched is the person who appears. An independent code audit or a technology consultation both work well for this, and you keep the deliverable either way.

Where this list came from

Fluvius has been building production software since 2017, for more than 200 clients — among them a national ministry (the Qatar Ministry of Foreign Affairs mobile app, live on both stores), a national health platform for the Ministry of Health of Barbados, and a UAE retail bank’s digital onboarding flow. The questions above are the ones our own clients asked us before signing, plus the ones we wish more of them had asked.