When a small business hires an outside company to build software, three things protect it more than anything else: a written brief that describes the work in terms of real tasks, payments tied to deliveries that you have tested yourself, and a contract that clearly gives you the source code, admin accounts, data and documentation at handover. Most painful disputes come from leaving one of these vague, not from bad intentions on either side.
Do you really need custom software?
Before talking to any agency, it is worth asking whether you need custom work at all. Ready-made software, rented by the month, already covers most standard needs of small businesses: sales, inventory, accounting, bookings, customer records. It is cheaper, ready immediately and maintained by someone else.
Custom software makes sense in narrower situations. Your process is unusual and central to how you win customers. You need to connect several existing systems in a way no standard connector supports. Or you are building a product that you will sell, where the software itself is the business.
There is also a middle path that many small companies overlook: a ready-made system with small custom additions, such as a special report, an import tool or a connection to a partner. These projects are smaller, easier to specify and much less risky than building from scratch.
If you decide that custom work is justified, the rest of this guide applies. If you are unsure, an hour with an independent adviser who does not sell development services is usually money well spent.
An example: the booking app that almost went wrong
Imagine a language centre with three branches that wanted its own booking app for classes and trial lessons. The owner found an agency through an acquaintance, described the idea in a meeting, received a one-page quote with a single price and signed. Half the money was paid up front.
Three months later the first version arrived. It looked good, but it did not handle the thing that mattered most: teachers who worked at several branches with changing timetables. The agency said that was "a new requirement". The owner said it was obvious. Neither could prove their point, because nothing had been written down beyond the one-page quote.
The project was rescued, but at extra cost. The owner and agency sat down and wrote what should have existed at the start: a list of user roles, the main tasks for each, examples of tricky cases such as a teacher moving branches mid-week, and acceptance tests for each task. Payments were reorganised around tested deliveries.
The lesson is not that the agency was dishonest or the owner careless. A spoken idea simply means different things to different people. Writing it down, with examples, is the cheapest insurance in any software project.
Writing a brief that vendors can quote properly
A good brief is written in business language, not technical language. It should take a few days, not a few months.
- Describe the problem and the goal. What is going wrong today, who suffers from it and what will be different when the software works.
- List the users and what each must do. For example: customer books a trial, receptionist confirms, teacher sees the timetable, manager sees attendance.
- Write the tricky cases. Exceptions are where cost and disputes hide: cancellations, refunds, staff covering two roles, offline periods.
- State what already exists. Current software, data that must be imported, systems the new one must connect to.
- Separate must-have from nice-to-have. Mark clearly what the first version cannot do without, and what can wait.
- Describe constraints. Devices staff use, languages needed, expected number of users, any deadline tied to the business calendar.
- Ask vendors to respond in the same structure. This makes quotes comparable and reveals which vendor actually read your brief.
Common pricing models and when each fits
No model is always best. The key is matching the model to how well you can define the work today.
| Model | How it works | Fits when | Main risk |
|---|---|---|---|
| Fixed price | Agreed total for an agreed scope | Scope is small, clear and unlikely to change | Every change becomes a dispute or an extra charge; vendor may cut corners to protect margin |
| Time and materials | You pay for actual hours or days worked at agreed rates | Scope will evolve and you can review progress closely | Costs grow if nobody controls priorities |
| Fixed price per phase | Small fixed-price phases, each re-scoped after the last | Medium projects with some uncertainty | Needs discipline to define each phase properly |
| Monthly retainer | A set amount of work capacity each month | Ongoing maintenance and small improvements after launch | Paying for unused capacity; vague deliverables |
| Revenue share or equity instead of fees | Vendor is paid from future income or ownership | Rarely suitable for a small business system | Complicated ownership, conflicts over direction |
For most small businesses, small fixed-price phases or carefully managed time and materials work better than one large fixed price for a vague scope.
Contract clauses worth reading slowly
Ownership of the source code. Who owns the code once paid for? Some agencies keep ownership and only license it to you; that may be acceptable, but you must know.
Third-party components. Software often includes libraries or paid services. Ask which licences apply and who pays for them later.
Accounts and infrastructure. Servers, domains, app store listings and cloud accounts should be registered to your company, with the vendor given access, not the other way round.
Data ownership. All business and customer data entered into the system belongs to you and must be exportable at any time.
Acceptance criteria. How a delivery is judged complete, who tests it and how long you have to report problems.
Payment schedule. Payments tied to accepted deliveries, with only a modest upfront amount.
Warranty period. How long the vendor fixes defects at no extra cost after launch, and what counts as a defect versus a change.
Termination and handover. What you receive if either side ends the contract early, and in what timeframe.
Confidentiality and subcontracting. Whether the vendor may hand work to other companies, and how your data is protected if they do.
Acceptance testing: check before you pay
Acceptance testing simply means checking, on your side, that a delivery does what was agreed. You do not need technical skills, only patience and real examples.
- Write test cases from the brief. Each user task becomes a short script: "receptionist books a trial for a new customer on a phone".
- Include the tricky cases. Test cancellations, wrong inputs, two people editing at once, slow connections.
- Test on the devices staff actually use. The cheapest phone and the oldest office computer, not only the vendor's laptop.
- Use realistic data. A copy of real records, anonymised if needed, reveals problems that sample data hides.
- Record each problem clearly. What you did, what you expected, what happened, with a screenshot.
- Classify problems. Blocking issues must be fixed before acceptance; minor ones can go on a list with an agreed deadline.
- Sign off in writing. Accept each delivery formally, so both sides know what is finished and what payment is due.
If deadlines keep moving and nothing usable reaches the testing stage, the signs described in warning signs that a tech project is burning money apply, and it is time to pause rather than pay the next instalment.
Handover checklist: what you must hold at the end
The complete source code. In a code repository your company controls, not only a zip file sent by email.
Admin access to everything. Servers, databases, cloud accounts, domain names, app store accounts, email sending services.
Technical documentation. How the system is built, how to install it on a new server, how to make a backup and restore it.
User guides. Short instructions for each role, usable for training new staff.
A list of third-party services and their costs. Every paid service the system depends on, with renewal dates.
A recent full backup. Code and data together, tested by restoring it at least once.
The list of known issues. Problems the vendor knows about but has not fixed, so they do not surprise you later.
A handover session. A recorded walkthrough where the vendor explains the system to whoever will maintain it next.
After launch: maintenance, hosting and who holds the keys
Launch is the start of the system's life, not the end of the project. Security updates, small fixes, changes in partner systems and new business needs will keep coming. Decide before launch who will handle them: the same vendor on a maintenance contract, another company, or a capable person inside your team.
Hosting deserves a deliberate choice too. Many custom systems run on cloud servers. The same principles as for any move to the cloud apply, which are covered in moving a small business to the cloud: accounts in your name, two-factor authentication, backups you control and a clear split of responsibilities.
Keep a simple record of who has access to what, and review it every few months. Developers come and go; their access should not stay behind them.
Finally, budget for maintenance from the start. A custom system that nobody maintains slowly becomes insecure and incompatible with new devices. A modest yearly maintenance budget is part of the true cost of building software.
Common mistakes when hiring a vendor
Choosing on price alone. The cheapest quote often reflects the smallest understanding of the work, and the difference returns as change requests.
Paying most of the money up front. This removes your main leverage if quality or deadlines slip.
Letting the vendor register everything. Domains and servers in the vendor's name can turn a disagreement into a hostage situation.
Skipping your own testing. Accepting a delivery because it looked fine in a demo leaves defects for your staff to discover.
No single decision owner. When several managers give the vendor different instructions, the project drifts and costs rise.
Treating every idea as urgent. Mid-project additions without a priority list are the fastest way to double the budget.
Ignoring the end of the contract. Without handover terms, ending the relationship can mean losing access to your own system.
Hiring friends without a contract. Informal arrangements feel easier but leave both sides exposed when expectations differ.
When to bring in a lawyer or an independent reviewer
A lawyer is worth involving before signing any contract that is large for your business, that grants the vendor ownership of the code, or that has unclear termination and data clauses. The questions above give a lawyer a useful starting point, but they are not legal advice; contract law and intellectual property rules should be checked against current regulations.
An independent technical reviewer, someone with development experience who is not part of the vendor, is valuable at three moments: when comparing quotes, at the midpoint of a larger project, and at handover. They can tell you whether the code is reasonably organised, whether documentation is usable and whether the system depends on fragile or expensive components.
Your accountant should check how payments, invoices and any software capitalisation are recorded, and whether the system produces the records you need for tax purposes.
If a dispute does arise, gather the written brief, emails, test records and sign-offs before discussing it. Disputes are resolved far more easily when both sides can look at the same documents rather than at memories of a meeting.
Frequently asked questions
Should we choose a local or an overseas software agency?
Local agencies are easier to meet, understand local business practice and usually support Vietnamese users better. Overseas teams may bring specific skills but add time-zone and language friction. For most small business systems, the clarity of the brief matters more than location.
How much should we pay up front?
Enough to show commitment and cover early work, but small enough that you keep leverage. Most of the payment should follow tested deliveries. Discuss the exact structure with the vendor and, for large contracts, your lawyer.
What if the vendor refuses to hand over the source code?
Check what the contract says about ownership and handover first. If the contract is silent or unclear, seek legal advice before escalating. This is exactly why ownership and handover should be settled before signing.
Can a non-technical owner manage a software project?
Yes, if they focus on what they know best: the business tasks, the tricky cases and testing results with real staff. Technical judgement can be borrowed from an independent reviewer at key moments.
Is a warranty period enough instead of a maintenance contract?
No. A warranty covers defects in what was delivered for a limited time. Maintenance covers security updates, changes in other systems and small improvements over the life of the software.
How do we compare quotes that look completely different?
Ask every vendor to answer against your brief, task by task, and to state assumptions and exclusions. Differences in what is excluded often explain differences in price better than hourly rates.
