Building a business application usually means working with an outside team for months, sometimes years. The cost of choosing the wrong software house rarely shows up straight away. It appears in month three, when the schedule slips, the budget grows and you realise you have no access to the code you have been paying for.
This article sets out what to check before choosing a software house or development partner, from preparing the scope to the points that belong in the contract. The advice applies to any vendor, including when you are comparing several quotes at once.
Start with a clear scope
Quotes can only be compared if every vendor is reading the same requirements. Before you contact anyone, write your needs down in a short document. Who the users are, what problem you want to solve, which processes currently run by hand, and which systems the new one has to connect to.
The document does not need to be technical. For a distributor, it could describe the flow from a field sales order to a delivered invoice, with examples of the forms and reports in use today. For a clinic, a description of the patient journey from registration to payment is enough.
Separate what must be in the first version from what can come later. A good software house will help you sharpen this list. If a vendor gives you a fixed price without asking many questions, they probably have not understood what you need.
How to choose a software house by its portfolio
A long portfolio is not necessarily a relevant one. Look for projects with similar problems, such as an internal system with many user roles, an app connected to a payment gateway, or an integration with accounting software. Polished screens in a pitch deck say little about how well the system behind them is built.
Ask the vendor to walk you through one or two projects in depth. What problem the client had, which technical decisions were made, what did not go to plan, and how the system is maintained today. If possible, ask to speak with one of their clients. Check whether the vendor has experience running systems over the long term, because building software and maintaining it are different skills.
Process and communication
Many software project problems are really communication problems. Ask how the vendor breaks down the work, how often you will see progress, and who your main point of contact will be.
Staged delivery with regular demos, say every two weeks, gives you a chance to give feedback before it is too late. You see working software you can try, and misunderstandings surface early. Make sure there is also a clear way to handle changing requirements. Changes will almost certainly happen. What matters is that their effect on schedule and cost is discussed openly.
On your side, appoint one person with the time and authority to answer the vendor's questions. Projects often slow down because the vendor is waiting on a decision from the client.
Code ownership and access
This is the part most often overlooked. Agree from the start that the source code, designs and documentation belong to your company once payments are made as agreed. The code should live in a repository your company controls, and never only in a developer's personal account.
The same applies to cloud accounts, domains, email services and app store accounts such as Google Play and the App Store. Ideally all of them are registered in your company's name, with the vendor given access as an administrator. If the relationship ends, you keep everything and can carry on with another team.
Ask for enough technical documentation that another developer could understand the system. If the app stores customer or employee data, ask how the vendor keeps it secure. Indonesia's Personal Data Protection Law (UU PDP, Law No. 27 of 2022) makes this worth checking carefully.
Post-launch support and the contract
A live application still needs looking after. Some bugs only appear once many people use it, and there are security updates, adjustments for new Android and iOS versions, and small feature requests. Ask how the vendor handles all of this, how long the warranty period is, and what support looks like after that.
Points worth putting in writing in the contract:
- Scope of work and features per stage, with the requirements document attached.
- Schedule and payment milestones tied to work you can actually review.
- A change request procedure, including how extra cost and time are calculated.
- Acceptance criteria that define when a stage counts as finished.
- Ownership of source code, designs, documentation and all related accounts.
- Bug-fix warranty period and the support arrangement after it.
- Confidentiality and data protection, and what happens if the engagement ends early.
A clear contract protects both sides. A serious vendor will usually be happy to go through these points in detail.
A second opinion before you decide
If you are comparing several proposals, or are unsure whether a technical plan makes sense, an independent view can help before the budget is committed. Averoa offers architecture reviews, build vs buy analysis and technical due diligence, based on our experience running our own SaaS products. You can read more on our Technology Consulting service page.
