Questions to ask before you hire a custom software partner
Strategy · 10 min read
Most software projects that go wrong were in trouble before the first line of code. The scope was vague, nobody agreed what "done" meant, ownership was never discussed, and support after launch was assumed rather than agreed.
The good news is that you can catch most of this with the right questions. This is the list we would want a client to ask us, and the list we would use ourselves if we were hiring a developer for our own business.
How to use this list
You do not need to ask every question in the first meeting. Use the first two sections early to see whether a company understands your business. Save the cost, ownership and support questions for when you are comparing proposals. Take notes on how each company answers, not just what they say. Hesitation, vagueness and "we'll figure it out" are answers too.
If you have not built a shortlist yet, start with our sibling post "How to choose a software development company in Johannesburg".
Questions about your problem
- What do you understand our problem to be? Ask them to describe it back to you. If they cannot, they are not ready to price it.
- What else do you need to know about how we work? Good developers ask about exceptions, month-end, approvals and what happens when something goes wrong.
- Have you built something similar? Similar in complexity matters more than same industry. A dispatch system and a repair job tracker share a lot.
- Would you recommend we build this at all? A partner who sometimes says "use an existing product for that part" is being honest with you.
Questions about the team
- Who will we deal with day to day, and who will write the code?
- Will the people who scope the project stay on it through launch?
- What happens if a key developer leaves or gets sick mid-project? Look for documentation, shared code ownership within their team, and more than one person who knows your system.
- How often will we see working software? Regular demos of real progress beat monthly status reports.
Questions about process and timeline
- How do you scope before you build? Expect a discovery phase that maps workflows, users, integrations and reports.
- How will you split this into phases? A first release that fixes one painful workflow is usually safer than a single big launch.
- How much of our time will you need? Someone on your side must answer questions and test. Ask how many hours a week they expect, and at which stages.
- How will our staff test the system before launch? User acceptance testing with real scenarios should be planned, not squeezed in at the end.
- What could delay this project? Honest teams will name integrations, data migration and slow feedback from your side.
Questions about cost and change
- What exactly is included in the quote, and what is excluded? Ask for discovery, design, build, each integration, testing, data migration, launch and support to be shown separately.
- Is this fixed scope, time and materials, or phased? Each has trade-offs. Make sure you understand which you are agreeing to.
- What happens when we want to change something mid-build? Requirements do change. You want a clear process: the change is described, priced and approved before it is built.
- What will this cost to run after launch? Hosting, support, third-party services such as SMS or WhatsApp messaging, and future changes.
- How are payments linked to milestones? Payments tied to delivered, working milestones protect both sides.
Questions about ownership, data and POPIA
- Who owns the code, and who owns the data? Models differ. Some developers hand over source code. Others, including ThinkinCode for most projects, run the system as a managed platform where you keep ownership of your data and can export it. Know which model you are buying.
- How do we get our data out if we part ways? Ask about format and how long it takes.
- Will you sign an NDA? Reasonable developers will, especially where your process is part of your edge.
- Where will our data be hosted, and who can access it?
- How do you handle POPIA? If the developer or their host processes personal information for you, POPIA Section 21 requires a written contract that makes sure they keep proper security measures in place, and that they notify you if there is unauthorised access. Ask how they cover this.
- What security measures are built in? Role-based access, audit trails of who changed what, backups that have actually been restored in a test, and no shared logins.
Questions about launch and support
- How will you move our existing data across? Excel sheets, Pastel exports and old systems need cleaning and mapping.
- What training do our staff get? Floor staff and office staff often need different training.
- What does support look like in the first weeks after launch?
- What are your response times for a critical fault versus a small change?
- How does the system behave when power or internet drops? For field staff, branches or yards, ask whether work can be captured offline and synced later.
- What happens if your company closes or stops supporting this? Ask about documentation, data export and handover arrangements.
Good answers and warning signs
| Topic | A good answer sounds like | A warning sign sounds like |
|---|---|---|
| Understanding | "Let me check I've got this right..." followed by a clear summary | "Yes, we can build that" with no follow-up questions |
| Price | "We'll scope it, then give you an itemised quote" | A firm number after one call |
| Team | "You'll work with me and the engineers building it" | "Your account manager will handle that" |
| Change | "Changes are written up and priced before we build them" | "Don't worry, we're flexible" |
| Ownership | A clear description of code, data and export terms | "We'll sort that out later" |
| Support | Defined response times and a change process | "Just WhatsApp us if anything breaks" |
| Offline and power | "Here's how capture and sync work if the connection drops" | "It's cloud, so that's not an issue" |
What to get in writing before you sign
Whatever you agree verbally, make sure the proposal or contract covers:
- The scope of the first phase, with what is excluded.
- Deliverables and acceptance criteria for each milestone.
- Payment schedule linked to milestones.
- How changes are requested, priced and approved.
- Ownership of code and data, and how data is exported.
- Confidentiality and POPIA obligations, including breach notification.
- Hosting arrangements and who pays for what.
- Support terms, response times and how new features are charged.
- What happens at the end of the relationship.
We are not lawyers, and this is not legal advice. For larger contracts, have an attorney review the terms.
Frequently asked questions
What questions should I ask a software development company?
Ask how they understand your problem, who will build it, how they scope and phase the work, what the quote includes and excludes, how changes are handled, who owns the code and data, how POPIA is covered, and what support looks like after launch.
What should be in a software development contract?
Scope with exclusions, milestones with acceptance criteria, payment schedule, change process, ownership of code and data, data export, confidentiality and POPIA obligations, hosting responsibilities, support terms and exit arrangements. Have an attorney review larger contracts.
What happens if my software developer disappears mid-project?
That is why you ask about it upfront. Reduce the risk by working with a team rather than one person, getting regular demos of working software, making sure documentation is kept, and agreeing in writing how your data and work in progress are handed over.
How do I protect my idea when working with a software developer?
Sign an NDA before sharing detailed processes, agree ownership and IP terms in the contract, and keep your own copy of the requirements and documents shared during scoping.
How much involvement will I need during software development?
More than most owners expect, especially in discovery and testing. Plan for one person on your side who can answer questions quickly, attend demos and organise staff testing. Ask the developer to estimate the time at each stage.
Can requirements change during custom software development?
Yes, and they usually do once people see working software. A good partner has a clear change process: each change is described, priced and approved before it is built, so the budget does not drift without you knowing.
Ask us these questions
We would rather you ask us hard questions now than discover gaps later. Bring this list to a Discovery call with a senior engineer and hold us to it. You can see examples of what we have built in our case studies and read how we approach custom software development.
Email [email protected] to book a Discovery call.
Ready when you are
Book a Discovery call
Tell us what you are trying to fix. We will tell you honestly whether custom software is the right next step.