What Actually Sets the Price
The short answer first: custom software pricing isn't driven by screen count or feature count the way most people assume. It comes down to three things — scope (what actually needs to be built), complexity (how many integrations, what kind of data it has to handle), and the team doing the work (experience level, team size, in-house versus subcontracted out again).
Two quotes that differ by several times for the same brief don't automatically mean one vendor is overcharging. More often it means the two sides interpreted the scope differently, or priced in a different tier of team. Understanding these three factors first makes every quote you receive much easier to read.
The Different Pricing Models
Software vendors in Thailand typically price work one of three ways. Each has real strengths and weaknesses — none is universally better; it depends on how clearly your scope is defined.
If your requirements are already well defined, fixed-price billing tends to control budget the best, because you know the final number before work begins.
- Fixed-price — scope, timeline, and cost are all agreed before work starts. Suits requirements that are already clear; the budget stays stable because the price is locked in upfront. Changing scope midway means pricing the difference separately every time.
- Hourly — you pay for actual hours worked. Suits work where the scope isn't settled yet or the direction may shift often. Flexible, but without an hours cap the budget can run past what you intended fairly easily.
- Monthly retainer — a flat monthly fee buys you a team working continuously. Suits long-running work with a steady stream of tasks rather than a single project with an end date. Requires someone on your side actively steering the work.
What Makes a Software Budget Balloon
Budgets that run away rarely start with an inflated price. They usually come from avoidable gaps along the way.
- Scope wasn't fully nailed down upfront, so features surface mid-build that were never mentioned when the price was set.
- Requirements change mid-project — features get added or altered without going back to re-price first.
- Hourly billing with no cap, and no one flagging it as the hours quietly climb.
- A legacy system or third-party API turns out more complex than it was estimated to be at the start.
- Testing gets skipped to hit a deadline sooner, and the fixes come back later at a higher cost than they would have upfront.
Common Price Ranges in Thailand (Broad Strokes)
The figures below are broad ranges commonly seen in Thailand's custom software market — not a fixed price list. Every project has its own scope and complexity, so the number that actually applies to you only comes after scoping is done.
- Small system, one clear function, little to no integration with other systems — usually in the low hundred-thousands of baht.
- Mid-size system, multiple modules, integration with external services like LINE or PromptPay — usually runs from the high hundred-thousands into the low millions of baht.
- Large, highly complex system requiring full compliance with standards like PDPA, HIPAA, or PCI-DSS — usually in the millions of baht and up.
How to Control the Budget from Day One
Budget control starts before the contract is signed — not after problems show up.
- Get the scope in writing before development starts, spelling out exactly what's included in the price and what isn't.
- Match the pricing model to where the project actually stands — fixed-price if the scope is clear, hourly with a cap if it isn't yet.
- Break the work into phases with sign-off points along the way, instead of waiting to see results only at the very end.
- Trim scope down to what's genuinely needed before real-world launch, then add features later once you have real usage to learn from.
- Ask directly, before signing, how post-launch support is priced — so the next budget line isn't a cost you didn't see coming.
Questions to Ask Before You Sign
- Does the agreed scope cover every feature you actually need — and what's still unclear?
- Is the quoted price fixed, or billed by the hour?
- How is added or changed scope priced if you want to add or adjust features midway?
- Who is actually doing the development — not just who you're talking to during the sales process — and what's their experience level?
- Does the stated timeline include testing and bug-fixing before delivery, or just the build?
- Is there ongoing support after delivery, and what does it actually cover?
- Once payment is complete, who owns the source code and documentation?
Frequently asked questions
Why do software quotes vary so much between vendors?
Because each vendor interprets scope differently, staffs the work with a different level of team, and prices it under a different model. A quote that's several times higher or lower than another for the same brief isn't unusual. The useful move is to ask each vendor to itemize exactly what's included in their number, then compare on actual scope — not just the total at the bottom of the quote.
Fixed-price or hourly — which is better?
It depends on how clearly your scope is defined. If requirements are already settled, fixed-price controls budget better because you know the final number before work starts. If you're still in an exploratory phase or direction may shift often, hourly is more flexible — but agree on an hours cap upfront so the budget doesn't run without a ceiling.
I have a limited budget — where should I start?
Start by trimming scope down to only the features you genuinely need before a real launch, then put it in front of real users. Add features later based on the feedback you get. This keeps the first budget smaller and tells you faster whether the system actually fits before you invest further.
How is post-launch support usually priced?
Usually as a monthly fee covering urgent bug fixes, security updates, performance monitoring, and minor changes up to a number of hours agreed per month. New features outside the original scope are typically priced separately, following the same approach used when the project first started.