How to Choose a Software Development Partner in Asia

Most partner-selection processes optimise for the wrong variables. Buyers compare hourly rates, headcount and logo walls, then act surprised when the engagement fails for reasons none of those signals could have predicted. In our experience running delivery from Cebu and Dublin — and inheriting several platforms from vendors who failed before us — the factors that actually predict a good outcome are different: who will personally do the work, how decisions get made when requirements are ambiguous, and whether anyone senior stays engaged after the contract is signed.

The Asian market amplifies this problem because the range is enormous. The same city can host a two-hundred-person body shop billing juniors at senior rates and a fifteen-person team shipping venture-backed products. Both will show you a polished deck. Your evaluation process has to see through the deck, and this article sets out the framework we would use if we were buying rather than selling.

Ask precisely who will design your architecture, who reviews code, and how many concurrent projects those people carry. A common offshore pattern is a senior architect who appears during the sales cycle and vanishes at kickoff, leaving a rotating cast of junior developers. Insist on meeting the actual delivery lead and, ideally, the engineers — not their managers — before signing.

Small senior teams routinely outperform large mixed ones on custom product work. A 13-person cross-disciplinary team with genuine architectural oversight can operate enterprise platforms with 99.5%+ uptime; a fifty-person team without it usually cannot. Founder-led firms have a structural advantage here: the people whose reputation is on the line are inside the delivery loop, not two management layers above it. Ask directly how often the founders or CTO review your project, and treat a vague answer as data.

How a partner works day to day matters more than which methodology label they use. Before shortlisting anyone, get concrete answers to these questions:

• What does a normal week look like — standups, demos, written updates, and in whose time zone?
• Who owns the backlog and who can say no to a bad requirement?
• Where does the code live, who controls the repositories and cloud accounts, and what happens to them if you part ways?
• What are the testing and code-review standards, and can they show evidence from a live project?
• How do they handle the first production incident — escalation path, response expectations, post-mortems?
• What is developer retention like, and how is knowledge preserved when someone leaves?

Intellectual property assignment should be unambiguous: all code, designs and infrastructure configuration belong to you, delivered into repositories and cloud accounts you control from day one. Be wary of vendors who host everything in their own accounts — it is a soft form of lock-in that becomes expensive to unwind.

On pricing, understand what model you are actually buying. Fixed-price bids reward vendors for cutting scope quietly; pure time-and-materials rewards them for going slowly. In practice, the healthiest arrangements we have seen combine a fixed, well-scoped initial phase with a transparent team-based model afterwards, plus the contractual right to audit the codebase at any time. Also confirm the boring things early: contract jurisdiction, data-protection obligations under the laws that apply to you and them, invoicing currency and payment terms. Ambiguity here is cheap to fix before signature and painful afterwards.

No amount of evaluation replaces watching a team actually work. Structure a paid pilot of two to six weeks around a small but real slice of your product — not a toy exercise — and judge it on the things that matter long term: quality of questions asked, honesty about trade-offs, code quality under review, and how the team responds when you change your mind mid-sprint, because you will.

Pay for the pilot properly. Free pilots select for vendors desperate enough to work unpaid, and give you no ethical standing to demand senior attention. At the end, review the work with an independent engineer if you do not have one in-house. A good partner will welcome that scrutiny; the wrong one will resist it. That reaction alone is one of the most reliable signals in the entire process, and it costs you a fraction of what a failed engagement would.

Some signals justify walking away regardless of price or polish. A vendor who agrees with everything you say is not being agreeable — they are being commercial, and they will keep agreeing while your project drifts off course. We have written elsewhere that saying no sometimes leads to a much better result; a partner incapable of saying no is a partner incapable of protecting you from yourself. Other reliable red flags: refusal to name the engineers who will do the work, portfolios full of screenshots but no products you can actually use, resistance to your ownership of repositories and infrastructure, and case studies that cannot survive a reference call. Finally, be sceptical of any firm whose answer to every question is that they can do everything. Depth in a few domains beats claimed breadth in all of them — ask what they would not take on, and listen carefully to the answer.