- Hiring an app developer takes seven steps. Your decisions weigh most in the first three, before anyone writes a line of code.
- While the app is built, ask to see it on a real phone every week, and accept it on your own devices with your own work.
- Register the store accounts in your company's name early, and collect the code, documents and every password before the final payment.
- If you can't say what a step decided, don't approve the next one.
The app development process, seen from the side that hires
Hiring an app developer is a lot like extending a shop. The builders lay the bricks; you say who uses which space, approve the plan before the foundations go in, and visit the site every week. Each step below covers what you decide, what you prepare, what you should get to see, and where projects tend to go wrong. Some developers name the steps differently. The work inside is the same.
Step 1: define the problem and the users
The first step has no screens yet, only questions: what problem the app solves, for whom, and how you'll know it's solved. The answers are yours. The developer helps you sharpen the questions.
You choose one problem, one main group of users and one number to track, such as the share of bookings made through the app after three months. Then line up three to five real people for the developer to talk to. A good developer comes back with a one-page summary of how each person's work will pass through the app. If you get a two-page feature list instead, be careful: projects that start from features tend to have scope that keeps growing. If you're not yet sure anyone wants the app, try the method in From idea to test product in 7 days first.
Step 2: set the scope and get the quote
The scope lists what the first version does and what it doesn't. Anything left unwritten becomes an argument halfway through.
You pick the smallest set of features that still solves the problem, the MVP, and decide whether to build for iOS and Android together or one of them first. You list the systems the app must connect to, such as LINE Login (sign-in with LINE, the chat app most Thai customers use) or payments by PromptPay, Thailand's national QR payment system, and name the one person who can approve the scope. A good quote attaches the scope, fixes the price before work starts, gives delivery as a date, says what happens when you ask for more midway, and states who owns the source code. Projects often go wrong when a low price comes from reading the scope more narrowly than you did. What to prepare before those conversations is in What to prepare before you hire an AI developer.
Step 3: a prototype you can tap through
A prototype is every screen of the app, clickable on a phone, with no real system behind it yet. Moving a button now takes an hour. Moving it in step 5 takes days.
You approve the prototype as the design to build, after two or three frontline staff have run one real task through it, such as signing up and placing a first order. A good developer hands you the phone, lets you tap, and notes every place you hesitate. Projects go wrong when the prototype is approved because it looks good, and testing later shows the screens come in a different order from the real work. The gap between something you can tap and a system customers can rely on is covered in From vibe-coded prototype to production system.
Step 4: build in sprints, with a demo every week
This is the longest step. What stops a team from disappearing for two months and coming back with something you've never seen is short rounds of work, called sprints, and a look at the real thing every week.
You decide that the riskiest parts come first, such as the link to your existing membership system, and when new requests arrive you choose what they replace in the agreed scope. What you give is one hour a week from someone who can make decisions. Every week you should see the app on a real phone doing more than it did. The warning signs are two demos in a row that slip, and small requests piling up until the delivery date moves without anyone signing off.
Step 5: test and accept
The development team tests all along. This is the round where you and your staff test it yourselves, on your own phones, with your own work.
You agree the acceptance criteria before testing starts: what must pass, and which kinds of defect can wait until after launch. Agreed after a problem turns up, they become a negotiation. Then gather the phones your customers really use, older models included. A good developer sends you functional, speed and security test results first, along with a place to report problems and track their status. Projects go wrong when only the smooth path is tested, and dropped signals, double payments or a user switching phones are skipped. If the app holds customer data, read on in Cybersecurity for vibe-coded apps.
Step 6: submit to the stores and launch
Apps reach the App Store and Google Play through developer accounts. Those accounts should be in your company's name, because that's the name customers see under the app.
You pick the launch date, and whether to open to everyone or to a small group first. The preparation should start back in step 2: organization developer accounts on both stores, which take documents and several days; a privacy policy that matches the data the app actually collects and meets Thailand's Personal Data Protection Act (PDPA); and a test account for the store reviewers. A good developer has a pre-submission checklist. Projects go wrong when someone finds out on submission day that the account doesn't exist yet, or that the reviewer can't log in. If your customers already use LINE, a LINE Mini App opens inside LINE without going through either store.
Step 7: care and the next version
Launch day is the first day you learn which of your step 1 assumptions were right. From here the work is keeping the app running and choosing what the next version does.
You decide who in the company owns the app, and whether to continue a monthly care plan or hand it to an internal team. At handover you should receive the source code, system documents and access to every account, as scoped, along with analytics that track your step 1 number from day one. Phone operating systems get a major release every year, and an app nobody looks after starts to break. Projects go wrong when the final payment goes out before all the passwords come in, leaving you dependent on the original developer for everything, which is called vendor lock-in.
| Step | You decide | You get to see | Where it goes wrong |
|---|---|---|---|
| 1 Problem and users | The problem, the users, the number to track | A one-page summary | Leading with a feature list |
| 2 Scope and quote | What's in, what's out, which systems connect | A quote with the scope attached | Scope read narrowly |
| 3 Prototype | Approving the design | Clickable screens on a phone | Approved because it looks good |
| 4 Sprints | Order of work, what new requests replace | The real app every week | Slipping demos, piling requests |
| 5 Testing | Acceptance criteria | Test results, a problem tracker | Only the smooth path tested |
| 6 Stores | First group, launch date | A pre-submission checklist | Accounts not ready on the day |
| 7 Care | App owner, care plan | Code, documents, accounts, numbers | Paying before everything is in |
Hypothetical case
A veterinary hospital with four branches in Nonthaburi (name and details invented) wants an app where pet owners book appointments and get vaccine reminders. In step 1 the developer talks to the receptionists and finds the real queue lives in each branch's notebook, so a queue screen for staff has to come first. The owner moves a loyalty points scheme to version two and applies for the developer accounts in the company's name straight away. When staff try the prototype, they find that many customers have more than one pet.
The week-three demo shows that reminders count from the last injection without checking the vaccine type, and it is fixed that week. In testing, a vet uses the fourth branch's old phone and the queue screen loads too slowly to use. The app opens at one branch for two weeks first. The most common request in the first month is paying a deposit by PromptPay, and it becomes the first job of version two.
Three questions to repeat at every step
You can steer the project without reading code. Ask the same three questions at the end of every step, and move on when all three have answers.
Three questions per step
- 1. What have we decided, and where is it written down? The answer should be one document both sides hold.
- 2. Is what we see today running on real data or sample data? The closer to launch, the more real data there should be.
- 3. If we stopped today, what would we get back? A good answer is something another team could pick up.
Rule: if any question has no answer, ask for another meeting before approving the next payment.
What to prepare before you talk to a developer
These seven things let the first meeting be spent on your problem.
- A one-paragraph brief: what problem, for whom, how you'll measure it
- Three to five customers and staff willing to be interviewed
- The existing systems to connect, with the name of whoever looks after each
- Sample real data with customer names removed
- The one person who approves scope and design
- Company registration documents for developer accounts on both stores
- A privacy policy, or the name of whoever will write it
For the development team · Store accounts, app signing and review times
Apple Developer Program enrollment as an organization requires a legal entity, a D-U-N-S Number, and an enroller with the authority to bind the company. Google Play personal accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in for 14 continuous days before publishing, so use an organization account in the client's name from the start. Apple says App Review typically handles at least 50% of submissions in under 24 hours and 90% in under 48 hours; Google says reviews for certain accounts can take up to 7 days or longer in exceptional cases. Keep the signing certificate and upload key where the client can reach them, test through TestFlight and internal testing, and make the privacy policy and the Data safety form match the SDKs actually in the build.
How we walk these seven steps with you
The rules behind a booking or an order live with the staff who handle them every day. So DNA Maker starts step 1 by sitting with them, then writes it up as a process map and the numbers you'll measure. Scope and price are fixed before work starts, you try a clickable prototype before approving it, and if a LINE Mini App suits the brief better, we say so at that point.
DNA Maker's own team builds the whole app, with no subcontracting. We work in AI-accelerated sprints with a demo on a real phone every week, senior engineers review the code, and we test against the agreed scope, submit to the stores, train your team, deliver the source code as scoped and look after the app monthly. This is how we work for banks, hospitals and large Thai corporate groups. To see how big your brief is, describe it to Dream on the chat page and get an estimate in minutes, or visit AI App Development.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
| Term | What it is | A simple example | What executives should ask the development team |
|---|---|---|---|
| Scope | What this version does and doesn't do | Booking is in scope, loyalty points are not | If we add one screen midway, how do price and delivery change? |
| Prototype | Clickable screens with no system behind them | Staff try booking and find they need to pick several pets | How many real users try it before we approve? |
| Sprint | A short round of work that ends in a demo | Sprint three delivers the queue screen | Is this week's demo running on real data? |
| Acceptance Criteria | The pass mark agreed before testing | The booking screen opens on an old phone within three seconds | Where are the criteria written, and who signs them? |
| Source Code Ownership | The agreement on who owns the code and documents after handover | Another team can take over the code | After the final payment, which code, documents and accounts do we hold? |