- Websites and apps in Thailand are built by three kinds of supplier: freelancers, small agencies and software houses. Each suits a different size of job.
- Measure every supplier with the same questions in five checks: proof, process, contract, fit and red flags.
- Ask three things first: who actually writes the code, who owns the code and every account, and how often you get to see real work.
- If a supplier trips any red flag, set it aside until it is fixed, even if its total score is high.
Three kinds of builder, and a fair way to compare them
Choosing a web development company is a lot like choosing a regular garage for the company car. You want to see cars it has fixed that still run well, know which mechanic does the work, get a clear written estimate, and keep the car's registration papers yourself. Software works the same way. Here the registration papers are the source code, the domain and every system account.
Three kinds of supplier work in the Thai market. Freelancers work alone or in pairs and suit small jobs with a clear scope. Small agencies are usually strongest in design and marketing, and they build company websites or online shops on ready-made platforms quickly. Software houses have a standing team of engineers, a testing process and care after handover, and they suit systems that connect to internal data or need to run for years. Every kind has good suppliers and ones to avoid. So this article ranks no companies. It gives you questions that work on any supplier, including us.
Check 1, proof: work you can open, and the people who write the code
Good proof is work you can open yourself. Ask for links to websites that are still online or the names of apps in the stores, then try them on your own phone. Look at the speed and at the Thai-language screens. A screenshot in a slide deck only shows that the job once existed. Then ask for the phone numbers of two past clients, and ask them whether the work finished on time, how fast problems were answered after handover, and whether they would hire this supplier again.
The question people forget is who actually writes the code. The person pitching to you is often in sales. Ask to meet the engineers who will build your system at least once before you sign. Ask plainly which parts go to people outside the company, and who takes over if a key person leaves halfway. A supplier with its own team answers on the spot.
Check 2, process: prototype, demos, testing and code review
A good process has four points you can see from outside. The first is a prototype, clickable screens made before any real code is written. Fixing a sketch costs far less than fixing a finished system. The second is the demo rhythm: will you see real work every week, or for the first time at handover? The gap between demos is where misunderstandings pile up unseen.
The third is testing. Who tests, and is there a staging environment, a trial system kept apart from the live one, where your team can try things before launch? If the system holds customer data, use the checks in Cybersecurity for vibe-coded apps. The fourth is code review. Ask, "When code is finished, who checks it before it goes live?" A good answer is the name of a senior engineer.
Check 3, contract: scope, price, payment stages, source code and every account
A good contract starts with a scope written as a list: what the system does, what is not included, and how requests added mid-project are charged. A fixed price on a fixed scope suits a clear brief. Paying for time used suits work where the answer is still being found. Both are fine, as long as the contract says which one applies. Tie each payment to work you have accepted against the acceptance criteria rather than to a date on the calendar.
The clause to read slowly is source code ownership. The contract should say that once you have paid in full, the source code, database, system documents and design work belong to your company, and that you can hand them to another team to develop further. If the supplier uses components it holds the rights to, the contract should state the terms under which you can keep using them.
The accounts look like a small matter. Domain, hosting, cloud, the App Store and Google Play developer accounts, the LINE OA account and ad accounts should all be opened in your company's name and paid with a company card, with the supplier given access to work in them. Accounts in the supplier's name are hard to transfer on the day you want someone else to look after the system. That is vendor lock-in that lives outside the code.
Four more points belong in this check. The warranty: how many months of defect fixes. The care plan after the warranty, with response times written as an SLA. A PDPA clause on how much of your customers' data the supplier can reach and when it is deleted after the project. And the tax paperwork: a VAT-registered supplier can issue a tax invoice, some as an e-Tax Invoice, while an unregistered freelancer can issue only a receipt. You can check a company's registration with the Department of Business Development.
Check 4, fit: team size, language, industry and the nerve to say no
The team should be the right size for the job. Ask how many people will work on yours and how many other projects each of them carries at the same time. On language: if the users are Thai staff, the screens and manuals must be in Thai they can read easily. If executives or the parent company are abroad, system documents and progress reports should come in English too. Ask who on the team works in both languages, and who will answer you day to day.
If they have never worked in a business like yours, watch whether they ask deep enough questions in the first meeting. The last point is the nerve to say no. A good supplier tells you when a feature you asked for should wait, or when a ready-made system is better value than building one. A supplier that agrees to everything in the first meeting often comes back later to charge for the extras.
| Check | What to ask | A good answer | Red flag |
|---|---|---|---|
| Proof | Can we have links to work that is live today? | Sends links or app names for you to try | Only pictures in slides |
| Proof | Who will write the code for this job? | Sets up a meeting with the engineers before you sign and says which parts it builds itself | "Our team", with no names |
| Process | How often will we see real work, and who reviews the code? | A demo every round on a fixed date, and a senior engineer reviews the code | First look at handover |
| Contract | Who owns the source code once we have paid in full? | Your company, written into the contract | "We'll sort that out at the end" |
| Contract | Whose name are the domain and store accounts in? | Your company's, with access for the supplier | The supplier's |
| Contract | What is each payment tied to? | Work accepted at each stage | A large payment before work starts |
| Fit | What in our brief should we not build yet? | Names at least one thing, with a reason | Agrees to everything |
Hypothetical case
A paper packaging factory in Nakhon Pathom (name and details invented) wanted a web app that lets its customers reorder and download tax invoices themselves. Two suppliers quoted similar prices. The first showed its work as pictures in slides, sent a salesperson to every meeting, and offered to register the domain and hosting in its own name "to keep things simple". The second sent links to systems its past clients use so the factory could try them, brought its engineers to the meeting, and offered a prototype to click through before writing code.
The factory manager and the head of accounts scored both suppliers separately with the five-check table. The first scored well on fit but tripped two red flags: accounts in the supplier's name, and a contract that said the source code would be handled "as agreed". It would not change either point, so the factory chose the second.
Scoring the five checks in half an hour
Use the table above as your scoresheet, with one column per supplier.
Five-check scorecard
- Step 1: send the questions ahead. Send every supplier the same questions and ask for answers with proof.
- Step 2: score 0 to 2. 0 means no answer or a vague one, 1 means an answer without proof, and 2 means an answer with proof, such as a link, a name or a draft contract.
- Step 3: keep red flags apart from the score. A supplier that trips anything on the list below waits until it is fixed.
- Step 4: have two people score separately. Then discuss only the items where your scores differ.
- Step 5: break a close score. Choose the supplier whose actual developers reached a shared understanding with you faster.
If the job includes AI, the questions about models, data and an AI agent's permissions are in What to prepare before you hire an AI developer.
Check 5, red flags that should stop you
- Quotes a price straight away without asking about your business
- Asks for a large payment before work starts, with no stages tied to acceptance
- Will not let you meet the people who will write the code
- The contract says nothing about the source code, or says the supplier owns it
- Insists on registering the domain, hosting or store accounts in its own name
- No written scope
- Answers questions about care after handover with "you can reach us anytime" and gives no response time
For the development team · What to check when the code is handed over
The repository sits in the client's organization account from day one, with the full commit history. The README explains how to set the system up on a new machine until it runs, and someone who did not write the code can follow it. There is an .env.example file, and the real secrets live in a secrets manager, apart from the code. Database migration scripts are in the repository. A CI/CD pipeline runs the automated tests. Dev, staging and production are separate. Backups run on a schedule, and a restore has actually been rehearsed. There is a list of third-party service accounts with their owners, and a list of library licenses. For restore drills, read When the system goes down at peak sales.
How we answer this checklist
Before quoting, DNA Maker asks to talk with the people who will use the system: sales, accounts, the warehouse or the shop floor. Then we write the scope as a list you can picture, and say plainly what should wait until a later phase. You can ask us every question in the table above, and we answer with links to our work and a draft contract.
The team working for you is DNA Maker's own, with no subcontracting. You try a prototype before any code is written, see a demo on real data every week, and senior engineers review the code before it goes live. Scope and price are fixed before work starts. We deliver the source code and system documents as scoped. This is how we work for banks, hospitals and large Thai corporate groups. See the details in Production-grade engineering standards and custom software development, or ask Dream on the chat page.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
| Term | What it is | A simple example | What executives should ask the development team |
|---|---|---|---|
| Scope | A list of what the system does and what it does not include | "Reorders now, a points system in phase two" | If we add something mid-project, how is it priced? |
| Prototype | Clickable screens made before any real code | Customers try the order screen before the system is built | When do we get to try the prototype? |
| Source Code Ownership | The agreement on who owns the code and documents after handover | The contract says your company owns them once paid in full | Which parts stay under the supplier's rights? |
| Vendor Lock-in | Being unable to change who looks after the system because the code or accounts are tied to the current supplier | The domain is in the supplier's name, so it cannot move | If we change development teams next year, what can't we take with us? |
| Handover | Passing the code, documents, accounts and know-how to the team that takes over | A new team installs the system from the documents alone | Who has tested that the system installs from the documents? |