Most software projects that fail do not fail on the code. They fail because nobody asked the right questions before signing: nobody defined the scope clearly, nobody asked what happens if the project overruns, and nobody checked whether the team understood the business problem before writing code.
Scope and ownership: the two settled before signing
If code ownership is not in the contract, you are not buying an asset.
Ask how they define scope before developing. A serious team invests time understanding your process before writing a line: interviews, flow mapping, a clear definition of what is in and what is out. If you get a generic quote without them having understood your process, you will probably end up with a system that does not fit.
And ask who owns the code at the end. It should be explicit from the start, not negotiated later. Custom development only works as a long-term investment if your company fully owns the code and is not tied to a single supplier to maintain it.
Scope changes and how they work
A project you only see at the end is a risk, not a delivery.
Scope changes are normal: almost no project ends exactly as defined. What you should ask is how they are handled — whether there is a clear process to assess and quote changes, or whether every adjustment becomes a murky negotiation halfway through.
Ask too how often there are visible deliveries. A project only shown at the end is high risk: if something is being built wrong, you find out too late. Look for teams working in increments you can see and test.
Technology, support and communication
Launch is not the end of the project: it is the start of the system's real life.
You do not need to be technical to ask why they chose a given technology for your case. A good team can explain it in plain terms: it fits your needs on scalability, maintenance and budget, not because it is fashionable.
Ask explicitly what happens after launch: whether support is included, for how long, what happens with a critical production bug, and how ongoing maintenance is quoted. And settle communication: a build can run for months, and you need to know whether you will have constant visibility or vanish off the radar until it “is ready”.
The questions, and what a good answer looks like
The answer matters less than how concrete it is.
Use this table as the script for the first meeting. Do not look for the perfect answer: look for specific ones.
| Question | Good sign | Warning sign |
|---|---|---|
| How do you define scope? | A discovery phase that maps the process | A fixed quote without knowing your operation |
| Who owns the code? | Stated explicitly in the contract | “We'll sort that out at the end” |
| How are changes handled? | A defined process to assess and quote them | Resolved as you go |
| How often are there deliveries? | Reviewable progress every few weeks | A single handover at the close |
| What happens after launch? | Support with defined scope and response times | Not mentioned at all |
| Can you show previous work? | Projects of comparable complexity | No verifiable example |
Warning signs that should give you pause
Almost every warning sign is a different shape of ambiguity.
None of these disqualifies on its own, but two or more together do:
- A fixed price without having understood your process in depth.
- Ambiguity over who owns the code at the end.
- Extremely short timelines for projects with complex integrations.
- No mention of post-launch support, as if it were not part of the conversation.
- No verifiable example of previous work.
What a well-run hiring process looks like
Discovery, written scope, reviewable milestones, clear contract. In that order.
It starts with discovery that understands your real process, not just what you think you need to build. It continues with a clear scope proposal: what is included, what is not, estimated timelines and how changes are handled.
Then a work plan with visible milestones you can validate along the way, an explicit contract on code ownership and support, and defined communication: how often updates arrive and through which channel.
Frequently asked questions
Is it better to hire a freelancer or an agency?
It depends on complexity and how critical the project is. A freelancer can be enough for small, well-bounded projects; for critical systems with complex integrations, a full team with development, design and QA reduces the risk of depending on one person.
Should the project be fully defined before contacting a developer?
Not necessarily. A good team helps define scope during discovery. It does help to be clear on the business problem you want to solve, even if the exact technical solution is still open.
How much should an initial discovery meeting cost?
Most serious agencies offer that first conversation at no cost, as part of assessing whether there is a good fit before quoting formally.
What guarantees should I ask for in the contract?
At minimum: full ownership of the code at the end, an included post-launch support period, and clarity on how scope changes or extra features are quoted.
How do I know the team understood my problem?
If after the first meeting they can explain your own process back to you accurately and in their own words, that is a good sign. If they only repeat what you said in generic terms, they probably did not go deep enough.
Summary: what to remember
- Scope, code ownership, change handling and post-launch support: the four that go in writing.
- A project with no intermediate deliveries hides mistakes until they are expensive to fix.
- The vague answer is the signal: measure concreteness, not how pleasant the sales meeting was.
About to hire a custom build?
We start every project by understanding the real business process before proposing a single line of technical scope.
See our web development service
