What makes a software development partner reliable?
A reliable partner keeps progress, responsibilities and risks visible throughout the project. You should always know what is finished, who is handling what and what could go wrong, without reading any code.
Run this two-minute check at any point. You should be able to name:
- The last thing finished and shown to you working.
- The next milestone, and when you will see it.
- The biggest open risk, and who is handling it.
If you cannot answer all three, ask for more visibility before you ask for more features.
Why start with a small, bounded project?
A small, clearly scoped piece of work, such as a discovery phase or a pilot, lets you see how a partner operates before a larger commitment. Where practical, start there. Its delivery can reveal communication quality and operational understanding that a sales call will not.
Judge the pilot on four things:
- Communication. Were questions answered clearly, and problems raised early?
- Understanding. Did the work reflect how your operation really runs, exceptions included?
- Demonstrations. Did you see working results, or only status updates?
- Handover. Did you receive the code, documentation and access you agreed?
If you are still choosing a company, start with how to compare custom software companies.
How should progress be reviewed during the build?
Review progress through demonstrations of usable outcomes, not progress percentages alone. "Seventy percent complete" is hard to check. "Office staff can approve a quote" is easy to see.
Set milestones as usable outcomes.
For example, "create and approve a quote" or "complete a field report".
Agree acceptance criteria first.
Write down what "done" means for each milestone before work starts, including one unusual case.
Ask to see each outcome working.
A live demonstration, with time for your questions.
Name who can approve changes.
One person on your side and one on theirs.
Keep one shared record.
Decisions, open issues and approved changes, where both sides can read them.
New requirements usually come up. A good process shows their effect on price and timing before anyone starts the work:
- 1You raise the request
- 2They estimate price and timing
- 3You approve or decline
- 4The decision is logged
- 5Approved work starts
For one example of a delivery process built on milestones, acceptance criteria and regular demos, see how OpenCollar approaches software development projects.
What should a custom software contract say about code, data and handover?
It should settle three things: who owns the custom code, who controls hosting and data, and what happens if the relationship ends or another authorized team takes over. These terms are easiest to agree while everyone is getting along.
Paying for software is not the same as having access to it
Agree on your authorized access to the source code, hosting, database exports and documentation, and get it during the project rather than at the end. Log in yourself and open an export to confirm it works. Access that exists only as a promise is hard to collect after a relationship ends.
Try this yourself
The contract and handover check
Put the proposal or draft contract next to this list, or the agreement you have with a current provider. Mark each line Written, Verbal or Missing.
- Milestones described as usable outcomes, each with a demonstration
- Acceptance criteria, and who signs off
- How changes are priced and approved before work starts
- Your access to source code, hosting and database exports
- Custom-code ownership and third-party licenses
- Documentation another authorized team could work from
- What happens if the relationship ends
- Support coverage, response expectations, escalation and exclusions
Settle anything marked Verbal or Missing in writing, before you sign or at your next review.
Read the payment, refund and start-of-work terms just as closely, especially the point at which a payment stops being refundable. OpenCollar's own terms are in its services contract policy, as one example.
If you are taking over software from a developer who is no longer available, modernizing outdated business software in stages explains where to begin.
Who fixes what after the software launches?
That depends on which of three kinds of work it is: defect correction, enhancements or operational support. Your software support agreement should treat each one separately.
| Type of work | Example | Agree in writing |
|---|---|---|
| Defect correction | An accepted feature stops working as agreed | Which defects are covered, and for what period |
| Enhancement | A new report you decide you need | How it is estimated, approved and scheduled |
| Operational support | Updates, backups, monitoring, user questions | Coverage, response expectations, escalation, exclusions |
Common mistake: accepting "unlimited support"
A promise of unlimited help sounds generous but says nothing about what is covered, how quickly someone responds, or where a problem escalates. Ask for those details in writing instead.
Some providers, us included, offer a monthly support and maintenance retainer as one way to scope ongoing support. Whatever the format, check what it includes and excludes.
Support is a running cost, like hosting and subscriptions. To budget for all three, see what custom software costs to own after launch.
