How to choose a software outsourcing partner in Thailand

Outsourcing software development can get a product to market months sooner than building a team from scratch. It can also burn a budget on code nobody can maintain. The difference usually comes down to the partner you pick, and most of the warning signs are visible before you sign anything.

Here are the questions we'd ask if we were on your side of the table.

1. Who will actually write the code?

Many agencies sell with senior people and deliver with whoever is free. Ask to meet the engineers who will work on your project, not just the founders or account managers. Ask how long they have worked together and whether any part of the work will be subcontracted to another company.

2. Have they built something like this before?

A team that has shipped a booking platform understands seat locks, payment timeouts and traffic spikes. A team that has shipped a CRM knows that data quality is the real project. Ask for a case study that is close to what you need, and ask what went wrong on it. A partner who can't name a single problem from a past project is either new or not being honest.

3. How do they handle changing requirements?

Requirements always change. What matters is how the change is handled: is there a clear way to estimate a change, agree on it and see its effect on cost and timeline? If the answer is "we'll figure it out", expect disputes later. See our guide to fixed price vs. time and materials for how the contract model shapes this.

4. How often will you see working software?

Weekly or fortnightly demos of real, running software are the best early-warning system you can have. If the first thing you will see is a finished product three months from now, you are carrying all the risk until then.

5. Who owns the code, and where does it live?

Your contract should say that you own the source code and intellectual property once it is paid for. The code should live in a repository you control, such as your own GitHub or GitLab organisation, from day one, not handed over as a zip file at the end.

6. What happens after launch?

Launch is the start of a product's life, not the end. Ask who fixes bugs after go-live, how quickly, and at what cost. Ask whether they monitor the system or wait for you to report problems. Get the support terms in writing before development starts, when you still have leverage.

7. How do they communicate?

Time zone, language and tools matter more than they seem. A Thailand-based team overlaps well with the rest of Asia and with Europe in the afternoon. Agree on one channel for day-to-day questions, one place where decisions are written down, and a named person who answers for the project.

8. What does a small first step look like?

The safest way to test a partner is a small, paid piece of work: a discovery phase, a prototype or one well-defined feature. You learn how they think, estimate and communicate before you commit to the whole build. We explain what a good discovery phase covers in what happens in a discovery phase.

A quick checklist

---

If you're weighing up a project and want a second opinion, tell us what you're building. We're happy to talk it through, even if we're not the right fit.