Software Development Company Thailand: 2026 Selection Guide

“We need a system built in Thailand, but we have no idea who to give the work to.” Among the manufacturing groups operating in Bangkok and the Eastern Seaboard industrial estates, this is one of the most common conversations we have. The phrase *software development company Thailand* covers four very different kinds of organisation — foreign-affiliated specialist vendors, Thai local vendors, the Thai arms of global system integrators, and offshore development centres — and they differ in the projects they handle well, the prices they quote, and the way they behave once the system is live. This guide sets out where the Thai market stands in 2026, how the four vendor types compare, which selection criteria matter more than price, how to read a quotation properly, what the contract and data-protection landscape looks like, and how to sequence a procurement so that you can stop early if it is going wrong.

The Thai Software Development Market in 2026: The Numbers That Matter

Before comparing vendors, it is worth understanding the state of the market they operate in. Whether a quoted rate or a proposed schedule is reasonable or unreasonable is almost impossible to judge without a sense of supply and demand.

The market is expanding, and engineering capacity is being competed for

Mordor Intelligence estimates the Thai IT and security market at USD 10.03 billion in 2026, growing at a compound annual growth rate of 10.26% to reach USD 16.72 billion by 2031. Five consecutive years of double-digit growth is the working assumption — which, read from the buyer’s side, means five more years of competition for the same pool of engineers.

The narrower IT services market tells a different story. Data Bridge Market Research puts it at roughly USD 2.5 billion as of 2025, with a 2025–2030 CAGR of just 3.31%. Within that total, IT outsourcing is the largest single segment at USD 1.03 billion, software services account for USD 1.13 billion (CAGR 4.46%), and digital services show by far the highest growth rate at approximately 34%.

Put those two figures side by side and the character of the market becomes clear. The overall market — including hardware, security products and cloud infrastructure — is growing in double digits, while traditional IT services, the “people on site running things” business, grows slowly. The growth is concentrated in digital services: cloud-native architecture, data platforms, and AI-related work.

Translated into procurement terms: the conventional model of custom development plus a resident maintenance team is no longer a growth area on the supply side either. That has a practical consequence. When you evaluate a vendor, look at where the company has been investing over the past five years, not only at its historical project list. Whether it has been putting people into cloud, API integration and data engineering is a reasonable predictor of the quality of support you will receive five years from now.

Public-sector cloud migration is raising the baseline

Regulatory momentum matters here too. Thailand’s Digital Government Development Agency (DGA) has set a policy of moving 70% of new public-sector workloads to the cloud by 2027, and 412 government agencies are required to migrate at least one core system by December 2026.

When public procurement shifts to a cloud-first assumption, the default design skills of the vendors serving that market shift with it. The inverse is also informative: a vendor that in 2026 can still only produce on-premise proposals may simply have stopped refreshing its skill set, and that is worth probing.

The infrastructure options have widened as well. Google Cloud has launched a Bangkok region, which makes “keep the data inside Thailand and still use a hyperscaler” a realistic architecture rather than a compromise. As we will see in the section on data protection, the existence of an in-country region has real design consequences.

Generative AI adoption in Thailand is among the fastest in the world

One statistic tends to surprise overseas head offices. According to BigGo Finance reporting, the share of people in Thailand actively using generative AI reached 12.4% in Q1 of fiscal 2026, up 36.4% year on year, moving Thailand to second place globally in speed of AI adoption.

The assumption that Thailand is slow to absorb new technology is common in head-office IT departments, and on this measure it is simply wrong. In practice we often see the opposite distortion: Thai staff on the shop floor are already using AI tools in their daily work while the company’s internal policy has not caught up. In vendor selection, whether the other side can hold a grounded conversation about how AI affects development productivity is one useful signal about the realism of their estimate.

The Four Types of Software Development Company in Thailand

Options for a *system development Bangkok* project fall into roughly four categories. None of them is inherently the wrong choice — the question is always fit with the character of the project.

Type 1: Foreign-affiliated specialist vendors (Thai subsidiaries)

These are vendors led or substantially staffed by expatriate management — most commonly Japanese — that handle everything from requirements definition to maintenance in the head office’s working language. Many of them have deep experience in production management, accounting integration, time and attendance, and cost accounting for foreign-owned factories, and can communicate directly with the head-office IT function.

Their strength is structural: the bridge between head-office-language requirements and Thai-language implementation is built into the organisation rather than improvised, and they understand both sets of business conventions — formal acceptance testing, internal approval workflows, reporting granularity on one side; Thai operational reality on the other. Their weakness is capacity. Most are not built to absorb a very large programme in a single contract, and their rates tend to sit above those of local vendors.

Type 2: Thai local vendors

Thai-owned, Thai-managed development companies. They are the most numerous group and the most price-competitive. Many carry genuine implementation know-how in Thai taxation, e-Tax Invoice, social security and labour law, which makes them strong for systems whose scope is contained within Thailand.

The trade-off is communication. English or Thai is the working language, and although a vendor may advertise Japanese or other foreign-language support, in practice that capability often sits only with the sales team and does not extend to the development squad. There is also a recurring product problem: locally built accounting and back-office packages frequently do not support multiple currencies or multiple UI languages, and screens available only in Thai make it very hard for a non-Thai-speaking manager to exercise internal control. If your project has to survive head-office reporting and group audit, verify this before signing anything.

Type 3: Thai subsidiaries of global system integrators

The Thailand offices of large international SIs and consulting firms. For ERP replacement, deployment of a global template, or simultaneous multi-country rollout, their methodology and their ability to mobilise people are in a different league, and their governance and audit deliverables are properly structured.

The counterpart is cost. Their rates are the highest, and small projects run into minimum engagement thresholds. Consultant turnover also tends to be fast, so the person who actually understands your Thai plant floor may not be there at go-live. For projects that reach into shop-floor terminals or OT networks, a local partner is often required alongside them.

Type 4: Offshore development centres

Using development capacity in Vietnam, India, the Philippines or Myanmar to build for a Thai entity remotely — or working with a Thailand-based company that keeps an offshore back end in another country. This is the classic *offshore development Southeast Asia* model.

For web and application projects that need a large volume of implementation effort, this is cost-efficient and scales quickly. Where it becomes risky is any project that assumes someone can physically walk onto the site: production lines, equipment, shop-floor terminals. When something fails at 02:00 in a plant running three shifts, a team that cannot be on site the next morning is a structural problem, not a contractual one.

Four-type comparison

In practice, more companies are moving away from “one vendor for everything” and towards layered sourcing: a specialist vendor for the plant-facing core, an offshore centre for the web layer, a global SI for group ERP. That works, but only if the responsibility boundary at each integration point is written into the contracts rather than assumed.

Seven Selection Criteria to Check Before You Look at Price

Our honest advice is to read the price last. Most of the spread between quotations is not a difference in efficiency — it is a difference in what each vendor decided to include or leave out along the following seven axes.

Criterion 1: What language is requirements definition conducted in?

This is the single biggest fork in the road. If requirements are written in the head office’s language and implemented in Thai, a translation happens somewhere. If you do not decide explicitly who performs that translation and who reviews the result, you get the most common failure mode in this market: requirements that were clear in one language arriving distorted in the implementation.

The question to ask is not “do you have staff who speak our language?” It is “how many language conversions sit between the person who writes the specification and the person who writes the code?” Zero conversions, one (head-office language to English), or two (head-office language to English to Thai) produce very different degrees of specification decay. Ask for the answer as a number, and ask who reviews the output of each conversion.

Criterion 2: How does the plan involve the business functions?

The dominant cause of failed system implementations at foreign-owned operations in Thailand is not technical. It is that the business functions never commit, the IT department runs alone, and the customer never performs a genuine acceptance test because everything was delegated to the vendor.

A vendor whose proposal states, at the bid stage, how many hours of which business stakeholder’s time the project will consume in each phase has probably learned this the hard way. Conversely, “leave it all to us, your team’s burden will be minimal” sounds accommodating and should be treated as a warning sign.

Criterion 3: What the support arrangement actually is

“24/7 support” in a contract needs to be unpacked into operational reality. Who answers the first call? How many engineers exist at second line? Can somebody genuinely reach the plant at 03:00? A production management system that stops takes production with it, so the definition of response time matters: is the committed time to acknowledgement, or to restoration? Get that in writing.

Criterion 4: Physical distance to the site

Consistently underrated. If your plant is in Ayutthaya, Rayong, Chonburi or Prachinburi, it is a two- to three-hour drive each way from central Bangkok. The credibility of “we will come if anything happens” is inversely proportional to that distance.

Ask how many days of on-site attendance are built into the estimate — terminal installation, supervision of cabling work, communication testing against equipment — and confirm that travel and accommodation costs are included rather than billed later.

Criterion 5: Documentation language and depth

If deliverable documentation arrives only in English, a head-office IT team that works in another language cannot review it. If it arrives only in Thai, non-Thai-speaking managers lose the ability to exercise control.

The workable compromise is usually: design documents in English (or the head-office language), operating manuals in both English and Thai. Decide who produces which language version, and whether translation cost sits inside the quotation, before contract signature rather than after.

Criterion 6: Understanding of both Thai and head-office business practice

Two symmetrical failures occur here. Dropping the head office’s standard system into Thailand unchanged, where it collides with Thai tax rules, statutory document formats and shop-floor practice. Or building purely to Thai practice, and then struggling with group consolidation and audit.

VAT, withholding tax, the prescribed Tax Invoice format, and the documentation tied to import/export and BOI privileges — ask directly whether the vendor has implemented these, and ask for specific project examples. Vagueness at this point is informative.

Criterion 7: How easy it is to leave

The most frequently overlooked criterion. When the relationship with this vendor ends, can the system be handed to another one? Who owns the source code? Can the build environment be reproduced? Does the solution depend on a proprietary framework or vendor-specific libraries?

Ask yourself whether the architecture is quietly creating a structure in which only this vendor can continue the work. The generality of the technology stack — widely used languages, frameworks and databases — converts directly into your negotiating position later.

How to Think About Cost: A Rate Card Never Gives You the Total

“What is the person-month rate in Thailand?” is the most frequent question we receive, and it is not a very useful one for estimating total cost. Here is why.

Using neighbouring countries to calibrate expectations

As a reference point, the 2025 edition of the Offshore Development White Paper (figures as of 13 February 2026) reports the following person-month rates by country. These are JPY-denominated rates surveyed from the Japanese buyer’s perspective, and they are one of the few public datasets that cover the region at all.

The same source notes that the average programmer rate has fallen to JPY 340,000.

One caveat is essential: Thailand is not included in this dataset. Public rate statistics for Thailand are thin, and we are not aware of a figure we could present as reliable. The honest characterisation, based on what we see in the market, is qualitative: Thai rates commonly land somewhere between the Vietnamese and Philippine levels and modestly above them, and they move higher again when a dedicated bridge function in the client’s own language is part of the package. Anyone quoting you a precise “Thailand market rate” should be asked for their source. Get real quotations from several firms under identical conditions instead.

There is also a reading technique for tables like this one. Look at the bridge engineer and project manager columns, not the programmer column. The gap between programmer and PM rates approaches a factor of two. In projects that span two or three languages, the proportion of effort sitting in that translation-and-coordination layer is structurally high, and that is what drives the total. Selecting a vendor on the strength of a low programmer rate misses where the money actually goes.

Break cost into three layers: initial, recurring, and hidden

Most quotations show only the initial build. Over a five-year horizon, it is not unusual for the recurring side to exceed it. We suggest decomposing every proposal as follows before comparing.

Data migration and internal effort are the two that most often exceed the original assumption. Legacy Excel registers and old master data almost always contain inconsistent naming, duplicates and obsolete codes. Only the customer can clean that up, and underestimating it pushes the entire schedule to the right.

Align the assumptions before comparing quotations

When you request quotations from several firms, comparison is meaningless unless the following are fixed and identical for everyone:

• Scope of business processes covered
• Expected number of users and concurrent sessions
• Data migration period and record volume
• Test scope — which of unit, integration and acceptance testing the vendor performs
• Support coverage hours and response time commitment
• Types of documentation and their languages
• Post-go-live change allowance, expressed in effort per month

Writing these seven items onto a single sheet and issuing the same sheet to every bidder materially improves the quality of your comparison. It costs an afternoon and it removes most of the noise.

Contract and Legal Points Where Projects Get Stuck

Software contracting in Thailand raises issues that do not arise the same way elsewhere, and data protection rules have tightened enough that they need to be reflected in the architecture rather than patched afterwards.

PDPA and where the data sits

Thailand’s Personal Data Protection Act came into full force in June 2022. The first fact to establish is that Thailand has no general data localisation requirement. There is no economy-wide rule saying that data about Thai individuals must be stored inside Thailand.

There is, however, an important exception. In September 2024, the National Cyber Security Committee adopted cloud usage rules for Critical Information Infrastructure Organisations (CIIOs). Under those rules, information systems classified as “high” impact must keep their primary data centre inside Thailand, with backups either in Thailand or within ASEAN. Whether your entity falls within CIIO scope — energy, finance, public health, transport and telecommunications are the typical sectors — is a question for your legal team early, not late.

For cross-border transfers, the working framework is transfer to whitelisted jurisdictions or transfer under Standard Contractual Clauses (SCCs). Consolidating Thai employee HR data onto a head-office server is a very common architecture; where that happens, intra-group data transfer agreements need to be in place.

Government cloud is treated separately: data is to remain in Thailand as a rule, with exceptions requiring DGA approval. If your project touches public-sector delivery, the baseline assumptions change.

As noted earlier, Google Cloud’s Bangkok region and the broader growth of in-country capacity mean the old assumption that “using cloud implies sending data abroad” no longer holds automatically. That is a genuinely useful design option when a CIIO classification or a conservative head-office policy is in play.

Copyright and source code ownership

In many jurisdictions the default drafting is that copyright in deliverables transfers to the customer. In Thai vendor contracts, it is not unusual to be offered the opposite: copyright in the source code is retained by the vendor, and the customer receives a licence to use it.

Negotiate this explicitly. At a minimum, fix the following in the contract:

• The scope of ownership or usage rights over deliverables — source code, design documents, build instructions
• Whether you have the right to commission a third party to modify the system
• Treatment of the vendor’s pre-existing libraries and frameworks (background IP), and the terms on which you may continue to use anything that depends on them
• An obligation to deliver a full inventory of open-source licences used

Whether you can ever switch vendors is decided by this clause and almost nothing else.

Acceptance criteria and defect liability

A contract in which acceptance means “when the customer approves” serves neither party. Specify what constitutes a pass, down to test cases and pass criteria.

• Duration of the acceptance test window in business days, and whether a deemed-acceptance clause applies once it lapses
• Defect severity classification — operations stopped, workaround available, cosmetic — with a response deadline for each
• The defect liability period; shorter periods than you may be used to are commonly proposed
• Whether post-go-live performance requirements (response time, concurrent sessions) form part of acceptance

Contract language and governing law

In Thailand it is common to execute in English with a Thai version as a reference translation. Even between two foreign-owned entities, if both are Thai-incorporated, English is the practical choice.

What matters is stating explicitly which language version prevails in the event of a discrepancy. Governing law and dispute resolution — Thai courts, or arbitration in Singapore or elsewhere — will materially affect what enforcement costs if it ever comes to that. For contracts above a meaningful value, having a Thai law firm review the draft is easily worth the fee.

Where the system connects to a plant’s OT (control) network, security requirements and the responsibility boundary also belong in the contract. We have set out how to approach that division in OT Security for Manufacturing in Thailand.

BOI Incentives and Cost Design: Software Development Qualifies

An element often left out of the cost conversation is the Thailand Board of Investment (BOI) incentive regime. Manufacturing incentives are well known; less well known is that software development itself is an eligible activity category.

Up to eight years of corporate income tax exemption

BOI maintains a category covering “development of software, digital service platforms and digital content”, carrying corporate income tax exemption of up to eight years. AI-enabled system development, cloud services and data centre operations are also within scope.

The annual cap on the incentive is determined with reference to the cost of additional hiring of Thai IT personnel, their training costs, and the cost of obtaining international standard certifications such as ISO 29110 or CMMI Level 2 or above. The design intent is transparent: the more a company hires and develops Thai engineers and formalises its development process, the larger the benefit it can claim.

What this means for the buyer

Unless you are establishing your own software development subsidiary, BOI incentives are primarily the vendor’s concern. They still matter to you in two ways.

First, they are usable as a quality signal. ISO 29110 or CMMI Level 2 and above indicate that the development process is documented and that review and configuration management are actually running. Adding certification status to your RFP question list gives you a cheap read on organisational maturity.

Second, if your group is considering localising an IT function in Thailand — a development capability serving Thailand and extending to other ASEAN sites — the total cost picture changes materially once BOI is factored in. That is worth modelling properly rather than dismissing.

Eligibility is assessed case by case against the business plan, so avoid drawing conclusions from general descriptions. Take a concrete plan into a specific consultation.

Five Common Failure Patterns and How to Avoid Them

The failures we see repeatedly in Thailand are rarely caused by technical difficulty. They are caused by a small number of organisational patterns.

Pattern 1: IT runs alone and the business never commits

The most typical. Head office instructs the local IT lead to launch a project; production, procurement and finance regard it as somebody else’s work. They attend requirements interviews, skip testing entirely, and then announce after go-live that the system does not support how they actually work.

The fix is to name a business-side owner at kick-off, put the project into that person’s performance objectives, and require the business function head’s signature on the requirements deliverable. Signatures are not bureaucracy here; they are the mechanism that converts attendance into accountability.

Pattern 2: Starting before requirements are stable, then absorbing endless change

“Let’s build something and decide while looking at it” is not a bad approach in itself, but without change control it produces an unbounded queue of additional requests, and budget overrun and schedule slippage arrive together.

The fix is to agree the change control process at contract stage — who approves a change, what a change costs, and up to when changes are accepted — and to phase the work with an explicit statement of what is frozen at the end of each phase.

Pattern 3: Local software that does not support multiple currencies or languages

Business and accounting packages built for the Thai domestic market frequently assume a single currency and a Thai-only interface. After implementation, teams end up rebuilding reports in Excel for head office, and approval workflows become nominal because the approving manager cannot read the screen.

The fix is to specify, during selection, exactly which screens non-Thai-speaking managers will use and exactly which outputs will feed head-office reporting, and to have them demonstrated live. Do not accept a “multilingual” tick on a datasheet as evidence.

Pattern 4: Importing the head-office standard system unchanged

Global standardisation is a sound objective. Implemented without adaptation, it collides with Thai VAT and withholding tax rules, statutory document formats, and shop-floor operating reality — multi-skilled operators, shift patterns, attendance management including migrant workers — and the result is double entry for the people on the floor.

The fix is to draw the line in advance between what is non-negotiable and what is localised. Standardising the chart of accounts and consolidation granularity while localising shop-floor operational screens is usually the workable split.

Pattern 5: No bridge capability, so specifications arrive distorted

Requirements pass from the head-office language through English into a Thai-language implementation, and nuance disappears. Unstated assumptions are the most dangerous category — “obviously we close at month end” is business common sense in one office and simply absent from the specification in another. What is not written is not built.

The fix is to include an explicit “assumptions and implicit rules” section in the requirements document, and to require that bridge engineers understand the business, not merely the languages. The dividing line is whether a person can restructure a specification after understanding the process, rather than translate it word by word.

How to Run the Procurement: RFI, RFP, PoC, Phased Rollout

If you are in the comparison stage, the single most useful piece of advice we can offer is: do not place a large order first. Four steps let you reduce risk incrementally, and let you stop cheaply.

Step 1: Use an RFI to understand the market

Before requirements are stable, start with a request for information. You are asking several firms “here is our problem; what options exist for solving it?” and observing how their approaches differ.

What you want at this stage is not price but evidence of how they have solved similar problems: comparable industry and scale, the team structure they used, the duration, and what did not go well. Honest vendors will talk about the failures. Vendors who present an unbroken record of success are either lucky or editing.

Three to five firms over two to four weeks is a reasonable scale. The largest benefit of this stage is usually not vendor intelligence at all — it is the sharpening of your own problem definition.

Step 2: Use an RFP to make bids comparable

Build the RFP on what you learned. Include all seven alignment items listed in the cost section above. Adding the following will noticeably raise the quality of the responses:

• Current business flow and pain points, ideally with an As-Is diagram
• The target state, expressed qualitatively and where possible with quantified indicators
• An inventory of existing systems and the required interfaces
• Constraints: budget range, target go-live, internal standards, policy on where data may reside
• Evaluation criteria and their weightings — not only price, but team, track record, support and exit terms

Publishing the evaluation criteria in advance has two effects. Bidders can aim their proposals at what you actually value, and your internal selection process becomes defensible after the fact.

Step 3: Use a paid PoC to test working together

Rather than moving straight into full build, run something real within a deliberately narrow scope. The purpose of a proof of concept is not only to confirm technical feasibility. More importantly, it tests whether you can work with this organisation:

• Speed and accuracy of responses to questions
• How they report when something unexpected occurs
• How they communicate with Thai staff on site
• The quality of their documentation

Pay for the PoC. Unpaid proofs of concept get unpaid attention, the vendor cannot allocate real people, and both sides finish with no useful information.

Step 4: Design a genuine small start

Once the build begins, deliver in increments that produce value rather than building all functionality at once. The key discipline in designing a small start is defining who will feel what difference within the first three months.

For factory-side projects, the entry points that reliably work are:

• Start by collecting shop-floor actuals. Move production results, machine status and defect counts from paper and Excel into digital capture. Because the underlying work does not change, resistance is low.
• Start with visibility. Show the collected data on a dashboard. The experience of seeing numbers the next day that previously arrived at month end is what buys cooperation for the next phase.
• Start by removing paper. Digitise order forms, inspection records and daily reports. AI-OCR allows this transition without overturning the existing paper workflow, as we describe in AI-OCR Back Office Automation.
• Start with one line. Run the process on a single line and surface the problems before rolling out across the plant.

Sequenced this way, investment decisions also become incremental: approve phase two after phase one has produced a result. That structure tends to travel much better through a head-office capital approval process than a single large request.

For the functional selection criteria of production management systems themselves, we have set these out in MES Production Management System Thailand, which is the natural companion to this guide for anyone in the middle of *MES vendor selection*.

Factory Systems Have Different Ground Rules from Office Systems

Finally, the issues specific to *factory system implementation Thailand* projects. A vendor that does not understand these will cause difficulty after go-live rather than before it.

Production management systems must be designed on the assumption that they cannot stop

An accounting system can be taken down for a few hours overnight with no operational consequence. In a plant running around the clock, a production management system that stops takes production with it.

That turns the following into design requirements rather than nice-to-haves:

• A documented offline procedure for network or server failure, including running on paper and entering data afterwards
• Where the maintenance window sits, agreed against the production plan
• The level of redundancy, and its cost, decided explicitly rather than by default
• Agreed recovery time objective (RTO) and recovery point objective (RPO)

“We take backups” is not an answer. Ask for a record of an actual restore test and how many hours the restore took. If no such record exists, the backup is a hypothesis.

For IoT equipment monitoring, ninety percent of the work is confirming connectivity beforehand

In projects that collect data from equipment, the largest uncertainty is whether the equipment can produce data at all. Older machines with no communication interface, PLCs with proprietary protocols, and manufacturers unwilling to disclose specifications are all normal obstacles rather than exceptions.

For that reason, IoT projects should always begin with a paid on-site assessment. Without an inventory of equipment, model numbers, controller manufacturers and generations, and the existing cabling situation, no one can produce a meaningful estimate. A quotation issued without that survey will generate additional charges later; the only question is when. Our view of equipment-side automation and data acquisition is set out in Factory Automation Southeast Asia.

Choose shop-floor terminals from the environment, not the spec sheet

Selecting terminals the way you would select office PCs fails. The plant floor means heat, humidity, dust, oil, vibration, gloved hands and high noise.

• Can it be operated with gloves on? Capacitive touch panels frequently do not respond through gloves.
• Is the ingress protection (IP) rating adequate for the actual location?
• Is the display readable in direct sunlight and in dark areas?
• Is the UI designed on the assumption that the operator is a Thai speaker?
• What is the spare unit and swap procedure when a terminal fails?

The factor that matters more than any hardware specification is reducing the number of input fields. A shop-floor terminal that asks for ten entries will not survive contact with a production shift. Barcode or QR capture with minimal manual entry is the design that stays in use.

The boundary between OT and IT networks

How the OT network carrying production equipment connects to the IT network carrying business systems is the most important security question in a factory project.

The principle is not to run them flat, but to establish an explicit boundary, typically a DMZ. Even where the production management system reads data from equipment, the first option to evaluate is a one-directional flow from the equipment side. Ransomware that reaches production equipment through the IT network produces the worst available outcome: a stopped plant.

What we see very often is ambiguity over whether IT or the OT side — maintenance and production engineering — owns this. Settle the responsibility boundary early in the project, in writing, while it is still an organisational question rather than an incident review.

Designing the scope through to where finished goods move into the warehouse and onward logistics is also what makes overall optimisation visible; we cover current developments in Southeast Asia Logistics DX 2026.

Conclusion: Build the Measuring Stick Before You Compare

When commissioning software development in Thailand, what ultimately separates a good outcome from a bad one is less which vendor you selected than what you measured them against.

To restate the essentials. The Thai IT and security market reaches USD 10.03 billion in 2026, with public-sector cloud migration and unusually fast generative AI adoption pulling the market forward, while traditional IT services grow only slowly. The vendors available to you fall into four types — foreign-affiliated specialists, Thai local vendors, the Thai entities of global SIs, and offshore development centres — each suited to different kinds of work.

Evaluate them on seven axes: the language of requirements definition, how business functions are involved, what support actually means in practice, physical distance to the site, documentation language, understanding of both Thai and head-office business practice, and how easily you could leave. Compare cost in three layers — initial, recurring and hidden — rather than by person-month rate. In contracting, work through PDPA and the CIIO cloud rules, source code ownership, acceptance criteria, and contract language and governing law. And sequence the procurement: RFI, RFP, a paid PoC, then a small start that expands in phases.

For factory projects, add the specifics: design on the assumption the system cannot stop, assess equipment connectivity before quoting, choose terminals from the physical environment, and define the boundary with the OT network. These are the areas that desk analysis does not reveal. They emerge when someone walks the floor.

Move deliberately, but keep moving. Beginning with a clear articulation of your own problem looks like a detour and is in fact the shortest route.

TOMAS TECH is based in Bangkok and works on system development and factory digitalisation for foreign-owned manufacturers across Thailand and ASEAN. A good share of the conversations we have start well before requirements exist — “we have not yet worked out what should be systemised” or “we want to compare several quotations but are not sure what to compare on.” If a local, practical perspective would be useful as one input among several, including as a reference point against other vendors, you are welcome to get in touch through our contact page. We work in English, Thai and Japanese.

Frequently Asked Questions

What do software development companies in Thailand typically charge?

Reliable public rate statistics for Thailand are scarce, and we would avoid asserting a specific person-month figure. As a regional reference, the 2025 Offshore Development White Paper (as of 13 February 2026) reports programmer rates of JPY 401,000 for Vietnam, JPY 372,000 for the Philippines and JPY 375,000 for India. Our practical read is that Thai rates commonly sit at a similar level to those two Southeast Asian markets or modestly above, and rise further when a dedicated bridge function in your own working language is included. Because the total is driven far more by estimating accuracy and hidden costs than by the headline rate, obtain quotations from several firms under identical conditions and compare those.

Should we choose a foreign-affiliated IT vendor or a Thai local vendor?

It depends on the project. Accounting and costing systems that must satisfy head-office reporting and internal control, and any project where requirements must be defined in your head-office language, favour a foreign-affiliated vendor. Work that is contained within Thailand, used mainly by Thai staff, and dependent on statutory compliance know-how plays to a local vendor’s strengths. The decisive question is how many language conversions sit between the person writing the specification and the person writing the code — the more conversions, the higher the risk of specification decay, and the choice comes down to whether you can absorb that risk.

What is the difference between offshore development and developing in Thailand?

Physical distance, primarily. Offshore development uses capacity in another country, which is cost-efficient and scales well for high-volume web and application work. But for projects involving shop-floor terminals, equipment integration or any work requiring physical attendance, an arrangement in which nobody can be on site tomorrow morning is itself the risk. A practical division is to place office-facing systems offshore and keep anything touching the plant floor with a Thailand-based team.

Can BOI incentives be used for contract software development?

BOI maintains a category covering the development of software, digital service platforms and digital content, with corporate income tax exemption of up to eight years. AI-enabled system development, cloud services and data centre operations are also in scope. The annual cap on the incentive takes into account additional hiring and training of Thai IT personnel and the cost of international certifications such as ISO 29110 or CMMI Level 2 and above. Eligibility is assessed against each business plan, so treat general descriptions as background only and seek a specific consultation.

Does the Thai PDPA require data to be stored inside Thailand?

There is no general data localisation obligation in Thailand. However, cloud usage rules adopted by the NCSC in September 2024 for Critical Information Infrastructure Organisations require that “high” impact information systems keep their primary data centre in Thailand, with backups in Thailand or within ASEAN. Cross-border transfers rely on whitelisted jurisdictions or Standard Contractual Clauses. Government cloud data remains in Thailand as a rule, with exceptions requiring DGA approval. Confirm early whether your entity falls within CIIO scope, because it changes the architecture.

How do we start a system implementation small?

The entry points that work best are those that capture data without changing the existing process: collecting production results and machine status, putting that data on a dashboard, digitising paper forms, and piloting on a single production line. What matters is defining who will feel what difference within the first three months. Approving the next phase only after the first has produced a measurable result also travels considerably better through a head-office approval process than a single large investment request.

Should we consolidate with one vendor or use several?

It depends on scale and scope. Layered sourcing is increasingly common: a locally strong specialist vendor for the production management core, an offshore centre for the web front end, a global SI for group ERP. The weakness of a multi-vendor arrangement is that responsibility becomes ambiguous exactly at the integration points. If you split the work, keep the owner of interface specifications on your own side of the table and write the responsibility boundaries into each contract.

References

• Mordor Intelligence — Thailand IT and Security Market: https://www.mordorintelligence.com/industry-reports/thailand-it-and-security-market
• Data Bridge Market Research — Thailand IT Services Market: https://www.databridgemarketresearch.com/reports/thailand-it-services-market
• Software Association of Japan — Information provided by the Thailand Board of Investment (BOI): https://www.saj.or.jp/NEWS/activity/government/210706_boi.html
• Cookie Information — What is the Thailand PDPA? 2026 guide: https://cookieinformation.com/blog/what-is-the-thailand-pdpa/
• Hogan Lovells — Thailand releases draft guidelines on government cloud adoption and data classification: https://www.hoganlovells.com/en/publications/thailand-releases-draft-guidelines-on-government-cloud-adoption-and-data-classification
• Offshore Kaihatsu.com — Person-month rate comparison across six countries (2026 edition): https://www.offshore-kaihatsu.com/faq/tanka.php
• BigGo Finance — Thailand rises to second globally in AI adoption speed: https://finance.biggo.jp/news/ENXbs54B-PfaobXfgh3Q
• Google Cloud — Bangkok region launch: https://cloud.google.com/blog/products/infrastructure/google-cloud-launches-new-region-in-bangkok-thailand
• Yamada Consulting Group — Challenges faced by Japanese companies after entering Thailand: https://www.ycg-advisory.jp/learning/oversea_28/
• Toyo Keizai Online — Why IT projects fail: https://toyokeizai.net/articles/-/894218