Custom software engagements go wrong in predictable ways. Having been on the developer side of these projects for over twenty years, and having spoken to many clients who came to me after a previous engagement went poorly, I can identify the failure patterns reliably. Most of them trace back to something that should have been established in the first conversation but was not.
I am going to give you the questions you should ask before signing any custom software contract — including questions that some developers will not like being asked, which is exactly the reason to ask them.
Before the Questions: What You Are Evaluating
A custom software engagement has three components you are evaluating simultaneously: the developer’s technical competence, the developer’s professional process, and the fit between your needs and their experience. Technical competence is hard to assess directly if you are not technical. Process and fit are easier to evaluate through conversation.
The questions below are primarily designed to surface process and fit. A developer with strong professional process will answer these questions confidently and with specifics. A developer with weak process will give vague answers, become defensive, or redirect. The quality of the answers tells you more than the content of a portfolio or resume.
The Questions
1. “Can you show me something you built that is similar to what I am describing?”
This is not a portfolio review question — it is a relevance question. You are not looking for a system that looks like yours. You are looking for evidence that the developer has worked in your domain or solved similar problems, and that they can articulate what they learned from it.
A developer who has built clinic software and is now quoting for clinic software has domain context that matters. A developer who has built only e-commerce systems quoting for a clinic management system is not necessarily unqualified, but they are starting without domain knowledge you will need to supply.
Listen for specifics in the answer — the challenges they encountered, the decisions they made, the things they would do differently now. Vague descriptions of generic projects are a yellow flag.
2. “Who will actually build this?”
In the custom software world, the person you meet in the sales conversation is not always the person who builds the software. Some agencies have sales people who bring in projects and hand them to a development team. Some freelancers outsource the actual development to contractors in another country. Neither of these arrangements is inherently wrong, but you need to know about them.
Ask specifically: “Will you personally be writing the code for this project?” or “Who are the specific developers who will work on this?” A good answer includes names, roles, and specifics about their experience. A vague answer about “my team” warrants follow-up.
3. “How do you handle requirements that turn out to be incomplete or wrong during development?”
Requirements always have gaps. No matter how thoroughly a project is scoped, some things are discovered during development that were not anticipated in the initial specification. The question is not whether this will happen — it will. The question is how the developer handles it when it does.
A developer with a good process will describe a change control mechanism: when a scope change is identified, it is documented, priced separately, and approved by you before any work proceeds. You should never be surprised by a cost change because a scope change should have a clear approval step before it happens.
A developer who says something like “we are flexible, we will work it out as we go” is describing a process that will produce scope disputes and budget overruns. Flexibility without process is not a feature.
4. “What does the payment structure look like?”
Standard professional practice for custom software: deposit at project start (typically 30-40% of total), milestone payments at agreed delivery points during development, and final payment at acceptance — when you have received and accepted the working software. This structure gives you protection: you are not paying for work that has not happened, and the developer has motivation to reach each milestone.
Non-standard structures to be cautious about:
- Full payment upfront: Removes the developer’s accountability for delivery milestones
- Payment only on final delivery: Creates cash flow problems for the developer and may incentivise rushing to finish rather than finishing well
- Continuous billing without deliverables: Can become an open-ended cost with no clear end state
5. “Who owns the source code?”
You should own it. Full stop. You are paying for a piece of software to be built for you, and the code that is produced belongs to you. This should be explicit in the contract.
Some developers include licensing clauses that give them ongoing rights to the code, or retain ownership and license it to you. Some use proprietary frameworks or platforms that mean the code “belongs” to them even though you commissioned it. Ask explicitly: “Is the source code delivered to me at project completion, and do I own it without encumbrances?” If the answer is anything other than a clear yes, investigate further before signing.
6. “What happens if I need to move to a different developer after this project?”
Businesses change. Your current developer may not be available in two years, or you may decide to bring development in-house, or the relationship may not work out. The question is whether the software they build can be taken over by someone else without a complete rewrite.
Good answers include: standard technology choices (not proprietary frameworks that only the developer knows), documentation of the system architecture and key decisions, clean code with comments on non-obvious logic, and willingness to assist in a handover process.
A developer who responds to this question defensively — “Why would you want to leave?” or “This won’t be a problem” — is answering a question about their own job security rather than yours. The question is legitimate and the answer should be practical.
7. “How do you test the software before delivery?”
Testing is the most frequently underestimated part of software development by non-technical clients — and by some developers. Bugs discovered after deployment are significantly more expensive to fix than bugs discovered during development. A developer with a clear testing process will describe: unit tests for key business logic, integration testing for connected systems, user acceptance testing in a staging environment before production deployment, and a bug fix period after delivery.
A developer who says “I test as I build, it will be fine” is describing a process that will produce bugs in production.
8. “What is the post-delivery support arrangement?”
Software that is deployed to production will have bugs discovered by real users that no testing caught. Some of these will be critical. You need to know what the response commitment is when something breaks after go-live.
Standard arrangements include: a defined warranty period (typically 30-90 days) during which bugs are fixed at no additional cost, followed by a maintenance contract for ongoing support. Know what the warranty covers (bugs from the original scope) and what it does not (new feature requests, changes to requirements).
The Questions That Tell You the Most
| Question | Strong answer indicators | Weak answer indicators |
|---|---|---|
| Who will build this? | Specific names, roles, experience | “My team,” vague descriptions |
| How do you handle scope changes? | Change control process, documented approval | “We’re flexible,” no specific process |
| Who owns the code? | “You do, explicitly in the contract” | Licensing clauses, proprietary frameworks |
| What if I change developers? | Standard tech, documentation, handover plan | Defensiveness, “won’t be an issue” |
| How do you test? | Specific testing stages, staging environment | “I test as I build” |
| Post-delivery support? | Defined warranty period, maintenance contract | “We’ll sort it out,” no specifics |
What a Good Contract Looks Like
Beyond the questions, a well-structured custom software contract should include:
- A scope of work that lists specific deliverables, not vague descriptions
- A timeline with milestone dates and what is delivered at each milestone
- A payment schedule tied to milestones, not just dates
- An explicit clause granting you ownership of all source code
- A change control clause specifying how scope changes are handled
- A warranty clause defining the defect correction commitment and period
- A termination clause for both parties (if either party needs to exit, what happens to work completed and payment owed)
Any of these elements missing from a contract is worth discussing before signing. The conversation about what should be in the contract is as informative as the contract itself.
Quick Summary
- Custom software engagements fail in predictable ways, most traceable to things that were not established in the initial conversation.
- Key questions: who builds it (not who sells it), how scope changes are handled, who owns the code, whether the project can be handed to another developer, how testing works, and what post-delivery support looks like.
- Payment should be milestone-based: deposit, milestone payments, final payment on acceptance — not full upfront and not indefinite monthly billing.
- Source code ownership must be explicit in the contract — you paid for it, you should own it without encumbrances.
- Strong answers to these questions are specific and practical; weak answers are vague, defensive, or dismissive.
The goal of these questions is not to catch developers out — it is to find the ones who have built good process into their practice. Good process produces better software and fewer surprises. The questions surface it quickly. If you want to see how I answer them, start with a conversation here.