- The price of a website or app is the sum of what you choose: screens, platforms, the systems it connects to, languages, and who looks after it.
- Two quotes for the same job differ because each company reads the brief differently and includes different lines.
- You can cut what you don't need on day one. Don't cut testing, security or your rights to the code.
- Write a one-page brief and send the same page to every company, so the quotes can be compared.
The price is the sum of decisions you make
Ask a builder what a house costs and you get questions back: how many rooms, how many floors, which materials. "How much does a website cost?" and "how much does an app cost?" work the same way. Two projects with the same name can differ enormously in size. What you control is each decision that adds up to the price.
One word runs through this article: scope, the list of what the system must do and what it leaves out. A good quote is a scope with a price on every line.
Ten factors that move the price
Screens and flows. The biggest factor. A food-ordering app has a menu, a cart, payment and order tracking, and behind every screen sit a back office and the failure cases, such as a customer who has paid just as the shop closes. A flow that must be right every time costs more than a screen that only shows information.
Platforms. A website, a web app, iOS, Android or a LINE Mini App (a small app that runs inside LINE, the messaging app most Thai customers use). One codebase for both phone platforms (cross-platform) costs less than two separate apps, except for features tied to the device itself.
Design level. A standard set of screens in your colors and logo costs less than designing every screen from scratch with animation. Spend the design effort on the screens customers use every day.
Systems to connect, or integration: ERP, stock, POS, membership, a payment gateway, LINE Login, couriers and Thailand's e-Tax Invoice. Most of this cost is invisible from the screen (see the note for the development team near the end).
AI features. Chat, OCR that reads Thai documents, or product recommendations add development work, a monthly usage charge and testing with real examples from your own work.
Content and languages. Who writes the copy, takes the photos and prepares the product data? Two-language screens are designed and tested twice, because Thai and English text run to different lengths.
Security and PDPA. A system that holds personal data under Thailand's Personal Data Protection Act (PDPA) needs a consent page, deletion on request, encryption and a penetration test.
Care after launch. Hosting, updates as iOS and Android change, and bug fixes. The day-one price is only part of the TCO, the total cost over the system's life.
Timeline pressure. A deadline shorter than the work needs means more people, a higher price and usually lower quality.
Team type. A freelancer, an agency that subcontracts the development, or a software house with its own design, development and testing team. Prices differ because what is included differs, down to whether there is someone you can still call in two years.
| Factor | What raises it | What lowers it | Question to ask the developer |
|---|---|---|---|
| Screens and flows | Flows that cannot fail, such as payment | Drop screens nobody will use yet | How many screens and flows does this quote count? |
| Platforms | Separate iOS and Android code | Cross-platform, or one platform first | Which platform do most of our customers use? |
| Design level | Every screen designed from scratch, animation | A standard screen set | Which screens are custom and which are standard? |
| Systems to connect | Legacy systems with no API or test environment | Batch file transfers in phase one | What does the app do when the other system is down? |
| AI features | Must be right every time with no human check | AI drafts, a person checks | What is the AI's monthly charge based on? |
| Content and languages | Several languages from day one | Your team prepares content, one language first | Who prepares the copy, photos and product data? |
| Security and PDPA | Financial or health data | Collect only what you need | Are the consent page and data deletion included? |
| Care after launch | No plan, so every fix is a new job | A care plan that says what it covers | What do we pay for in year two? |
| Timeline | A deadline shorter than the work | Launch what is ready first | Does the price change if we move the deadline? |
| Team type | Testing, documents and warranty included | A freelancer for small jobs | Who does the work, and who answers when it breaks? |
Read a quote line by line
The easiest quote to read is often the most dangerous: three lines and one price. What isn't written is what you pay for later. A complete quote usually covers requirements and a prototype, design, development, the back office, each integration, testing and UAT, server setup or app store submission, documents and source code, training, and a care plan.
Read a quote line by line
- Step 1 Separate what you receive from what they do. Underline the lines that are things, such as the app in the store or the documents. For lines that only say "develop" or "maintain", ask what you will get.
- Step 2 Find the missing lines. Compare against the list above. The back office, testing and documents go missing most often. Ask whether each is excluded or sits inside another line.
- Step 3 Find the assumptions. For example, that you prepare the content, or that your current system already has an API. A wrong assumption becomes extra work.
- Step 4 Read the change terms. If you add a screen halfway, how is it priced, who approves it, and what happens to the deadline?
- Step 5 Tie payments to things you can see. A payment tied to a clickable prototype or a system you can try beats one tied to a date.
- Step 6 Send questions back. No more than ten per quote. Whoever answers clearly and quickly is the team you will work with for months.
Why two quotes for the same job differ
When the brief is vague, each company fills the gaps with its own assumptions. To one, "membership" means signing up by email. To another, it means LINE Login with tiers and points. One quote includes the back office, testing and documents; another covers only the app. A team that tests failure cases and writes code others can maintain takes longer, and what the cheaper team saved often returns as technical debt in year two. A fixed price also carries the cost of certainty, while an hourly rate moves the risk to you.
Hypothetical case
A cosmetics company in Nonthaburi (name and details invented) wants a loyalty app linked to the POS in its shops. The owner sends a short brief to two companies. The first quote, from a freelance team, has three lines: an iOS and Android app, membership, notifications. The second, from a software house, has fourteen lines and is much higher. The owner almost picks the first on the spot.
Side by side, the first quote has no back office, so marketing must ask the developer to add every promotion. It has no POS link, so points are typed in by hand, and no PDPA consent page. The owner rewrites the brief as one page and sends it to both. The first quote gains lines and its price rises. The second proposes a first phase on one platform. The gap narrows until one question decides it: who is responsible when the POS link fails?
What you can cut, and what you should not
When the price is over budget, cut what you don't need on day one and keep the quality of what you do need.
Safe to cut: the second platform, languages you don't yet have customers for, animation, back-office features nobody uses yet, integrations a batch file can cover for now, and AI features you don't have enough data to test.
Don't cut: testing and UAT, security and the consent page, backups, a back office for master data, a test environment (staging) separate from the live one, documents, and clear source code ownership in the contract. Cutting these makes the project cheaper today and ties you to the same developer for good, which is called vendor lock-in.
Before you ask for a quote, put these on one page
- Who the users are, how many groups, and what each must do on day one
- The core tasks in order of importance, and what is not needed yet
- The platform most of your customers actually use
- The systems to connect, whether they have an API, and who looks after each
- The data you will hold, and whether any of it is personal or sensitive
- The languages for day one, and who prepares the content
- Who looks after the system after launch: your team or the developer
- The deadline, the reason for it, and how you will measure success
Build in phases and pay for what has been proven
The first phase is the flow that earns money or saves work straight away. Launch it, measure it, then decide the next phase from real numbers. It is the same idea as an MVP, and there is an example in From idea to test product in 7 days. Each phase needs its own scope and price, and what you build first must extend without being rebuilt. Before you sign, ask whether "phase 2" is included in the price or quoted separately.
If your brief isn't settled enough to become a scope, read What to prepare before you hire an AI developer. To check whether the project pays off, read How much is manual work costing your business each month?
For the development team · What sits inside a "connect to system X" line
A "connect to system X" line holds at least six pieces of work. Auth: API key, OAuth or service account, key rotation and least privilege. Error handling: timeouts, retries that don't duplicate a transaction (idempotency), and a queue for items that fail. Data mapping: fields with the same name and different meanings, units, product codes and Thai text encoding. Environment: many legacy systems in Thailand have no sandbox. Rate limits: batch when the other side caps calls. Reconciliation: a daily report that the two systems agree. Estimate from these six; counting API endpoints alone always comes in low.
How we make the price clear before work starts
What sets the price lives in your people's heads. Sales knows how customers order, accounting knows what the documents must look like, and IT knows how far the old systems can connect. DNA Maker starts by listening to them, writes it down as screens, flows and the systems to connect, then fixes the scope and price before any work starts.
Next we build a clickable prototype for your team to try, and the build begins only after you approve it. The team is entirely our own, with no subcontracting; you see a demo every week and receive the source code as scoped. For large builds we propose a first phase that goes live on its own. See what our documents look like on Sample proposals. For an estimate on your brief, tell Dream about it and get an answer in minutes, or see our AI web development and AI app development services. We have delivered more than 500 projects, including work for banks, hospitals and large Thai groups.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
| Term | What it is | A simple example | What executives should ask the development team |
|---|---|---|---|
| Scope | The list of what the system must do, and what it leaves out | "Sign up with LINE, but no member tiers yet" | Which of today's requests sit outside the scope? |
| Prototype | Clickable screens built before the code | The sales team tries ordering and finds a missing confirmation screen | Will we try a prototype before the build begins? |
| Integration | Connecting a new system to an existing one so data flows between them | The app pulls stock from the POS every five minutes | When the other system is down, what does the user see? |
| Source Code Ownership | The agreement on who owns the code after handover | The company holds the full code and documents and can hire another team | After the last payment, is the code ours, and where is it kept? |
| Vendor Lock-In | Being unable to change developers because you lack the code, documents or access | The domain and developer accounts are in the contractor's name | If we ended the contract tomorrow, could we carry on alone? |