On this page
In short
- Settle ownership first: the code, the cloud accounts, the domains and the data should be yours from day one, not transferred at the end.
- Ask who will actually do the work, and whether any of it is subcontracted. There's no wrong answer, only an unclear one.
- Fixed price and time-and-materials both work. What matters is that the pricing model matches how well the work can be described up front.
- Handover, security review and exit terms belong in the proposal. If they're missing before you sign, they'll be harder to get after.
Why the questions matter more than the pitch
Proposals can look alike on the surface: a capable team, a modern stack, an agile process. The differences show up in the details nobody volunteers, such as whose AWS account the system runs in, what happens when a requirement changes, and what you're left with if the relationship ends.
The questions below are grouped the way the risks tend to arrive. None of them is a trick. A firm that's set up to work with companies like yours should be able to answer each one plainly, in writing, before you commit.
Ownership: code, IP and cloud accounts
Ownership is the question with the longest tail. A system you don't control is a system you can't move, audit or hand to someone else without the original builder's cooperation.
Ownership questions and what a clear answer looks like
Who owns the code and IP when we've paid?
- A clear answer sounds like
- You do, with the assignment written into the contract, not implied
Whose repositories will the code live in?
- A clear answer sounds like
- Yours, from the first commit, with the firm given access
Whose cloud accounts will it run in?
- A clear answer sounds like
- Yours, set up so you hold the root or management access
What about domains, certificates and third-party services?
- A clear answer sounds like
- Registered to your company, billed to you or clearly listed for transfer
Is any of it licensed rather than owned?
- A clear answer sounds like
- Any reused libraries or frameworks are named, with their licenses
| Ask | A clear answer sounds like |
|---|---|
| Who owns the code and IP when we've paid? | You do, with the assignment written into the contract, not implied |
| Whose repositories will the code live in? | Yours, from the first commit, with the firm given access |
| Whose cloud accounts will it run in? | Yours, set up so you hold the root or management access |
| What about domains, certificates and third-party services? | Registered to your company, billed to you or clearly listed for transfer |
| Is any of it licensed rather than owned? | Any reused libraries or frameworks are named, with their licenses |
Who actually does the work
The people in the sales conversation aren't always the people who write the code. That's normal in firms of every size and location. What you need is a straight answer, so you can judge fit and plan access.
- Who will be on the project day to day, and what's their experience with systems like yours?
- Who is accountable for technical decisions, and will you be able to talk to them directly?
- Is any of the work subcontracted? If so, to whom, and does the same contract, NDA and security terms cover them?
- Where will the work be done, and does that matter for your data-handling or export rules?
- If someone leaves mid-project, how is their work picked up?
Location, team size and subcontracting are all legitimate choices. The warning sign is vagueness: if you can't find out who has access to your systems, your security team won't be able to either.
Fixed price or time-and-materials
Both models are honest when they're used for the right kind of work. The useful question isn't which one is better, but which risk each one puts on you.
Fixed price compared with time-and-materials
Who carries estimate risk
- Fixed price
- The firm, for the written scope
- Time-and-materials
- You
Works best when
- Fixed price
- The outcome can be described before work starts
- Time-and-materials
- The work is open-ended or exploratory
What to scrutinize
- Fixed price
- The scope, exclusions and acceptance criteria
- Time-and-materials
- Rates, reporting, and a cap or checkpoint on spend
Common failure
- Fixed price
- A thin scope that turns every question into a change
- Time-and-materials
- Hours that grow without a clear link to progress
| Aspect | Fixed price | Time-and-materials |
|---|---|---|
| Who carries estimate risk | The firm, for the written scope | You |
| Works best when | The outcome can be described before work starts | The work is open-ended or exploratory |
| What to scrutinize | The scope, exclusions and acceptance criteria | Rates, reporting, and a cap or checkpoint on spend |
| Common failure | A thin scope that turns every question into a change | Hours that grow without a clear link to progress |
We quote fixed prices, so we're not neutral on the first column, but time-and-materials with good reporting and agreed checkpoints is a reasonable choice for research-style work. Our guide to how fixed-price software projects work covers what a scope should contain if you go that way.
How changes are handled
Requirements move once people see working software. Ask the firm to walk you through a change from start to finish:
- Who can raise a change, and who on your side can approve one?
- How is a change priced or estimated, and do you see that before the work happens?
- Can you swap a new item for one that's no longer needed, rather than only adding?
- How is the scope document kept up to date as changes are agreed?
A good answer puts every change in writing before it's built. An answer like "we're flexible, we'll sort it out" sounds friendly, but it leaves the cost of a change undefined until the invoice arrives.
Security review and access
Bring your security team in before the contract, not after the build. The questions they'll want answered:
- Will the firm complete your security questionnaire and walk your team through the architecture?
- How will they access your systems: named accounts, least privilege, and access you can revoke?
- Where will your data live during development, and will real customer or employee data ever leave your environment?
- How are secrets handled, and are credentials ever shared in email or chat?
- Does the system use your identity provider for sign-in, so offboarding a user works the way it does everywhere else?
Documentation and handover
Ask what you'll receive at the end, specifically. "Full documentation" means different things to different firms. A useful answer names the pieces: repositories, infrastructure as code, deployment pipelines, runbooks, architecture notes and time with the people who will own the system.
Then ask what support looks like afterward, and how it's priced. There's no single right arrangement, but it should be something you choose rather than something you discover. Our guide to what a proper software handover should include has a checklist you can attach to a proposal.
References and proof you can inspect
References are useful, but they're chosen by the firm. Proof you can inspect for yourself is harder to curate:
- Working software. A live system you can use, with someone who can explain how it's built and run.
- An architecture walkthrough. How sign-in, data, hosting and deployment fit together, at the level of detail your team cares about.
- Sample documentation. A runbook or setup guide from real work, redacted if necessary.
- Relevant experience, specifically. Not "we've done integrations" but which kinds of systems, and what the hard part was.
If you do call references, ask what went wrong and how it was handled. How a firm deals with problems tells you more than the praise does.
Firms can only answer these questions well for your project if they know what it is. Our project brief builder turns eight short questions into a one-page description of the problem you can give every firm you talk to, so their answers are easier to compare.
Put these questions to us
Bring this list to a scoping call. We'll answer each one for your project, and you'll leave with a clear approach, the real risks and what a fixed-price quote would cover, whether or not you go ahead.
NDA and exit terms
Two contract questions are easy to leave until the end and awkward to raise later:
- NDA. Will the firm sign one before you share system details, data samples or internal documents? Does it cover anyone they subcontract to?
- Exit. If either side ends the engagement early, what do you receive for the work done so far, how is it priced, and how quickly does access transfer? Is anything withheld until a final payment?
A firm that's confident in its work shouldn't mind making it easy to leave. If the system is already in your repositories and accounts, most of the exit question answers itself.
The short list
Before you sign
- Code, IP, repositories, cloud accounts and domains are yours from the start, in writing.
- You know who will do the work, including any subcontractors, and they're covered by the same terms.
- The pricing model fits how well the work can be described today.
- There's a written change process, and every change is agreed before it's built.
- Your security team has reviewed the architecture, access and data handling.
- The handover deliverables are listed by name, and support afterward is optional and priced.
- You've seen proof you could inspect, such as working software or an architecture walkthrough.
- An NDA is signed, and the exit terms say what you receive if the engagement ends early.
Our How we work page answers these questions for us. If you're still deciding whether to build at all, start with custom web apps vs. low-code.
See it applied
- Illustrative sample. Not client work.See a sample scope for an internal tool →An invented request and approval portal that replaces a spreadsheet and email, on an existing SQL Server database with the company's existing single sign-on.
- Illustrative sample. Not client work.See a sample handover package →The handover index for an invented plant-floor dashboard: repositories, infrastructure as code, the pipeline, runbooks, a data dictionary, the credential handover list, alerts, known limitations and sign-off.
Share this guide
Related services
Topics