Choosing a software development company in Thailand: ten checks before signing

Assess a software partner through delivery evidence, team ownership, scope, testing, source-code rights and support, rather than the pitch alone.

By UNIXDEV Team · 13 min read
Original published 2026-06-05 · English edition 2026-11-03

Editorial illustration for Choosing a software development company in Thailand: ten checks before signing

Proposals are easier to compare when they answer the same questions. The goal is to understand what the supplier will deliver, who will do it and how both teams will respond when the project changes. Clear selection criteria from the start, and not comparing quotes on the bottom-line figure alone, reduce the risk of paying for months of work that never becomes a usable system, or of a vendor disappearing partway through.

This guide is for IT managers, executives and procurement teams who already hold proposals from several companies and need to choose. If you are still preparing the brief before asking for quotes, read what to prepare before asking for a software quote first.

In short: do not choose on price or presentation alone. Run ten checks, from delivery evidence and the actual team to testing and source-code ownership, then put every proposal into the same nine-row comparison table so the prices can genuinely be compared before you decide.

Why is choosing a software development company harder than it looks?

Every supplier can present well on paper, but the result depends on the team, the process and the contract terms, none of which show on a slide. The way to reduce risk is to ask questions whose answers can be verified and to compare proposals under the same headings.

Suppliers in Thailand range from individual freelancers to large companies. Common risks to check before signing:

The team that pitches is not the team that delivers.
A small requirement change triggers a large price increase.
Support disappears once the system is delivered.
The source code is not handed over at the end of the project.

Ten checks before signing

1. Relevant experience

Ask about a comparable workflow or technical problem, not only a recognizable logo. Systems in different industries carry different requirements; a financial system, for example, must consider compliance, audit trails and transaction integrity. Establish what the team actually owned and what evidence can be shared with permission. If a client cannot be named, ask to discuss the work under an NDA or for a contact you can use for a reference check.

Ask: "Can we see a project close to our use case, and is there a contact we can speak to for a reference check?"

2. The delivery team

Clarify the people and roles assigned after the sale, their availability and how substitutions are handled. A strong pitch does not identify the eventual delivery team by itself: senior engineers may present while other people, or an undisclosed subcontractor, do the work. Keeping people who understand the context on the project reduces the risk of requirements being lost in handoffs. Name the lead and their time allocation in the proposal.

Ask: "Who will lead this project? How involved will today's presenters be throughout? Which parts, if any, will be subcontracted?"

3. Requirement changes

Ask how an open question becomes a decision and how a change affects cost, scope and timing. Change is normal in software projects; the problem is having no process for it. A process should allow useful change without leaving commitments ambiguous. A transparent change request process assesses the impact and is agreed before extra work starts, separately from fixing defects against the acceptance criteria.

Ask: "If scope changes mid-project, how are approval and price adjustment handled? Is there a change log? How is the rate for additional work calculated?"

4. Support after launch

Distinguish warranty fixes, maintenance and additional development. Warranty length and coverage vary widely between proposals; some state only a duration without saying what it covers, and some state no SLA at all. Agree coverage hours, severity definitions, response targets and escalation. A response time is not the same as a resolution time. Mission-critical systems need managed support that states the response time in hours and how escalation works; contract details are covered in our MA and SLA contract checklist.

Ask: "How long is the warranty and what does it cover? What SLA levels apply after it ends? How quickly is a critical bug fixed? Is there an on-call team?"

5. Quality practices and certifications

Check certification status and scope, and ask how the process appears in day-to-day delivery. ISO 9001 (quality management) and ISO/IEC 29110 (software engineering lifecycle profiles) show that a company's process has been audited by an external certification body. They are process standards and do not replace industry-specific requirements, such as those of a banking regulator or a government agency, which must be checked separately. ISO/IEC 29110 was developed for very small entities, which Laporte and O'Connor cite as organizations, departments or projects of up to 25 people. For information security, ask about ISO/IEC 27001. For every standard, check the certification body, the scope and the expiry date. A certificate is supporting evidence, not a guarantee that a particular project will succeed.

Ask: "Which certifications do you hold? Who issued them, and does the scope cover software development? Are they current, and when was the last audit?"

6. Code and data ownership

Review ownership, licenses, repository access, build instructions, credentials and data-export arrangements. If this is not checked before signing, you may find later that you do not receive the codebase or cannot modify it yourself, leaving you dependent on the original vendor. Section 10 of Thailand's Copyright Act B.E. 2537 (1994) (English translation of the original text on WIPO Lex) provides that copyright in a work created under commission belongs to the employer, unless the author and the employer have agreed otherwise. A contract can therefore depart from the default, so write ownership down explicitly. The Act has since been amended several times, most recently by Copyright Act (No. 5) B.E. 2565 (2022) (consolidated text on WIPO Lex), so have legal counsel check against the current text.

Separate three things clearly: code developed specifically for this project, components the vendor already owned and reuses, and third-party or open-source libraries used under their owners' licenses. Include a practical handover, not just a statement that the code will be yours.

Ask: "Does the contract state who owns the custom code and documentation? What rights do we get to components you already owned? Do any dependencies have licenses that restrict our use?"

7. Communication and progress

Agree a review cadence and what will be demonstrated. Ask how risks, decisions and dependencies are reported. Projects without regular reporting tend to hide problems until they are hard to fix. Progress should include inspectable work and open issues, through sprint reviews, progress reports or at least a weekly status update, not occasional chat replies.

Ask: "Which project management tool do you use? Can we see progress in real time? How do we escalate if the PM does not respond?"

8. Price and exclusions

Compare equivalent scope. Testing, migration, hosting, licenses and support can change the total substantially. A low amount is not proof of poor quality, but unexplained omissions deserve questions. If one quote is clearly lower than the others, find out why first: the difference may come from a different reading of scope, QA or documentation being left out, a less experienced team, or a low price to win the work followed by charges through change requests. The comparison table below is the practical way to check.

Ask: "What does this price cover? Are QA, DevOps, documentation and training included? If scope does not change, will the final price stay close to this quote?"

9. Testing and acceptance

Ask who defines acceptance, who tests it and what evidence is retained. Include permissions, exceptions, integration failures and recovery where they matter. Quality assurance should run through the development cycle, from unit and integration tests to UAT, not only before deployment. For security, NIST SP 800-218 (SSDF) describes itself as a common vocabulary for buyers and suppliers to use in acquisition processes, and it can be used to frame questions about code review and vulnerabilities in dependencies.

Ask: "Is QA separate from development? Is there a minimum test coverage? Which bug tracker do you use? How do you check the libraries you use for vulnerabilities?"

10. Escalation

Know who can make decisions when delivery stalls, a dispute arises or a serious incident occurs, and whom to speak to when the PM cannot answer. The process should identify responsibilities on both sides at each level.

Ask: "If we are unhappy with the work or the timeline slips, whom do we talk to? Is there a response target for escalations?"

How do you compare proposals from several companies fairly?

Put every proposal into the same table, row by row, then adjust prices onto the same scope before comparing. A lower proposal may exclude work another includes. Any cell a proposal leaves empty is a question to send back for a written answer. Build this as a spreadsheet with one column per vendor.

Item	A clear proposal states	Follow up if you see
Scope coverage	Features, users, systems to integrate and supporting work such as data migration, deployment and training, traced to the requirements you sent	Broad wording such as "develop the system per the TOR" without saying what each item includes
Assumptions	The conditions the price rests on, such as number of users, an existing API on the current system, or the customer preparing test data and servers	No assumptions listed, or assumptions that do not match your situation and will become extra costs later
Exclusions	Work explicitly outside the price, such as software licenses, cloud fees, certificates or translation	No such section, or "additional costs may apply" without conditions
Team	Roles, headcount, experience level, time allocation and any subcontracted parts	No named lead, or the presenting team does not appear in the plan
Delivery approach	Phases, frequency of deliveries or demos, progress reporting and the test environment	Only a start and end date, with no checkpoints in between
Acceptance	Measurable acceptance criteria, the UAT procedure, time allowed for customer review and defect severity levels	"Delivered when development is complete" with no definition of complete
Ownership and IP	Rights to custom source code, documentation, system accounts, pre-existing vendor components and third-party licenses	Not mentioned, or a usage right only, without the source code
Maintenance and change requests	Warranty period and coverage, price and SLA of post-warranty maintenance, and how additional work is charged, such as a man-day rate	Bug fixes not separated from new work, or no reference rate for additional work
Payment milestones	Payments tied to accepted deliverables, such as design approval, first feature set, passing UAT and delivery of source code with documentation	Payments by elapsed time not tied to deliverables, or a large payment before the system is seen working

Making prices comparable

Fill the gaps: for work one proposal excludes, ask for an optional price or estimate it yourself and add it.
Align assumptions: for example, who provides the servers and who migrates the data.
Include post-delivery cost: warranty length and maintenance fees change the cost over the system's life.
Ask in writing: send the same questions to every vendor and attach the answers to the contract.

A hypothetical example: is the cheaper proposal really cheaper?

These figures are invented to illustrate the comparison; they are not market prices, quoted prices or client results. An organization receives two proposals for the same system: A at 1,200,000 baht and B at 1,500,000 baht, a 300,000 baht gap. In the nine-row table, A's exclusions list data migration from the old system and production deployment setup, while B includes both.

The organization asks vendor A for optional prices: 180,000 baht for data migration and 80,000 baht for deployment setup.
A on the same scope = 1,200,000 + 180,000 + 80,000 = 1,460,000 baht.
The real difference from B = 1,500,000 − 1,460,000 = 40,000 baht, not the 300,000 baht it first appeared to be.

With prices this close, the other rows decide: which proposal has clearer acceptance criteria, more complete IP terms or payments more closely tied to deliverables. If A is still much cheaper after filling the gaps, return to check 8 and ask where the difference comes from.

Which warning signs should stop you before signing?

Pause and ask further when you see any of these. They do not always mean a vendor is poor, but they need clear answers before you sign.

The portfolio cannot be verified: logos on a slide, no project detail and no reference contact.
The pitch team is only sales staff, with no technical lead able to answer technical questions.
The contract does not state who receives the source code, the documentation and rights to pre-existing vendor components.
QA is not measurable: "we test everything" without a test plan, bug tracker or acceptance criteria.
The quote changes after you award the work, citing incomplete information when the RFP was complete.
The proposal says "additional costs may apply" without stating the conditions.
Outcomes are guaranteed before the system or data has been examined.
Only demonstrations are offered as acceptance evidence.
Ownership and support are deferred until after signing.
Scope changes have no documented approval path.
References reveal confidential customer details without permission.

For warning signs after signing that the budget is starting to overrun, see the five budget-overrun warning signs.

What should you ask during the RFP or demo?

Bring a representative workflow and ask the team to explain how it would discover requirements, handle exceptions and test the result. Ask what remains unknown and what assessment is needed before committing to cost or timing. Questions that force answers from real experience carry more weight than general claims:

"Describe a project that failed or ran into trouble, and how you dealt with it."
"If 20% of the requirements change mid-project, what is the process?"
"How many people will work with us, and at what seniority?"
"When and in what form will you hand over documentation, runbooks and source code?" See our vendor handover checklist for what to request.

If the project improves an existing system, ask how the vendor will assess it before proposing an approach; see legacy system modernization.

Use a consistent scorecard, but keep the judgment tied to the project. A small, well-bounded engagement may need a different delivery model from a critical platform replacement.

What should you confirm last, before signing?

Confirm that every important answer is in writing, not only said in a meeting, and that the chosen proposal has been compared on the same scope as the others.

Run the ten checks on every shortlisted vendor, fill the nine-row table and keep the answers in writing.
Complete reference checks with the final vendors.
Have legal counsel review the IP terms and third-party licenses.
Name the lead and core team in the contract or an annex.
Tie payments to deliverables with acceptance criteria, and separate warranty, maintenance and change requests.

Summary: how do you reduce risk when choosing?

Use the ten checks to screen vendors and the nine-row table to compare proposals on the same scope. The right choice depends less on price than on process, transparency and whether the team that presents is the team that delivers.

A vendor ready to do the work should answer these questions specifically. Vague or evasive answers tell you something too.

UNIXDEV provides custom software development under a process certified to ISO/IEC 29110 (certificate details on the about page), with experience across government, finance and banking, telecommunications, media and large enterprises. Review our published experience, then send the project context for a proposal that states its scope, assumptions and exclusions.

Sources

WIPO Lex: Copyright Act B.E. 2537 (1994), Thailand (original text), section 10 on works created under commission.
WIPO Lex: Copyright Act B.E. 2537 (1994), amended up to Copyright Act (No. 5) B.E. 2565 (2022), the consolidated text for legal review.
Laporte and O'Connor: Systems and Software Engineering Standards for Very Small Entities, background and VSE definition for ISO/IEC 29110.
NIST SP 800-218: Secure Software Development Framework (SSDF) v1.1, secure development practices and a common vocabulary between buyers and suppliers.