- Before you hire anyone to build an e-commerce site, fill in the 12-part checklist and send the same copy to every developer. You'll see what each quote includes and what it leaves out.
- The work that takes most of your team's time is in the back office: confirming payments, shipping labels, and stock that has to match Shopee and Lazada.
- Customers should enter card details on the payment provider's page, and orders should switch to paid on their own when the money arrives, with nobody checking transfer slips.
- Points and coupons can wait for phase two. PDPA consent, payment confirmation and someone to look after the shop after launch have to be there from day one.
The storefront customers see, and the back office your team uses every day
An e-commerce website has two sides. The storefront is the product pages, the cart and the checkout. The back office is the screens that admins, packers and the accounting team open every morning. When they talk to developers, most people look at storefront designs, even though the heavy work is in the back office.
Follow one order through. After the customer pays, the system has to know the money has arrived, deduct stock, send the item to the packers, print a shipping label, send the tracking number and post the sale for accounting. Any step the system doesn't do, someone in the shop does by hand. That holds up on an ordinary day. On a campaign day, mistakes start.
If you're not yet sure whether the shop should have its own website, read your own online store or Shopee and Lazada first. If you've decided, the sections that follow are what you need to write down so the developer understands the shop the way you do.
Products, cart and payment
A good product page answers the questions customers would otherwise message you about: size, how to use it, how many days delivery takes, and whether it can be returned. Products in several sizes or scents can be chosen on one page, each variant has its own stock, and customers see the shipping fee while still in the cart, so no new number appears when they press confirm.
A shop in Thailand should accept at least cards and PromptPay, Thailand's national QR payment system, then add mobile banking or installments to suit its customers. Ask the developer two questions. Do card details pass through the shop's server? The answer you want is no. And do orders switch to paid on their own? A shop that still has customers transfer money and send a slip in chat needs an admin matching payments all day, and mistakes come easily when two orders have similar amounts.
For the development team · Payments and order status
Use the provider's hosted payment page or tokenization so card data never passes through the shop's server, which shrinks the shop's PCI DSS scope considerably. Mark an order paid only from a webhook whose signature you have verified, never from the redirect page, and use an idempotency key to guard against duplicate webhooks. Write the order state machine down clearly: pending payment, paid, packing, shipped, cancelled and refunded, plus which state can move to which. PromptPay QR codes should expire and release the reserved stock, and payments should be reconciled daily against the provider's records.
Shipping and stock across channels
The website should send orders to the courier the shop already uses, print shipping labels from the back office and send tracking numbers to customers itself, so nobody has to paste numbers into chat one order at a time. The shipping rules need deciding before anyone starts building: by weight or by item count, free shipping above a certain order value or not, cash on delivery or not.
If the shop also sells on marketplaces, stock is the section to discuss in the most detail. Every channel deducts from the same number, and someone has to decide which channel gets the last few units during a campaign. An online store whose stock matches Shopee and Lazada works only once product codes match across every channel, and that matching work can start right away.
Back office, members and PDPA
Write down what each person needs to do in the back office. Admins edit orders, packers see today's packing list, accounting pulls sales and fees, and the owner sees every channel's sales on one screen. Each person sees only the parts they use.
A membership system starts with signing up by phone number or LINE, viewing order history and remembering addresses. Points, coupons and member prices can come later, but agree from day one who sets the discount ceiling. Coupons that stack without limit can leave the shop selling below cost without anyone meaning to.
PDPA, Thailand's personal data protection law, has to be covered from day one. The site collects names, phone numbers, addresses and purchase history, so it needs a privacy policy, a marketing opt-in that is separate from the order and not pre-ticked, a way for customers to see or delete their data, and consent before any analytics or advertising cookies are used. Have your legal advisor review the wording of the policy. The developer's job is to make the system do what the policy says.
Speed, SEO and measurement
Customers who tap a link from LINE or Facebook open the site on their phones. A slow product page sends people back before they see the price. At handover, have the developer open a real product page on a mid-range phone in front of you.
SEO for a shop starts with product pages. Every product has its own page, page titles use the words customers actually search with, and products that are temporarily out of stock keep their pages so they stay in search results. If you're moving from an old site, you need a list that pairs every old URL with its new address.
Measurement shows where customers drop off: viewing a product without adding it to the cart, or adding it to the cart without paying. Google Analytics has to be installed from launch day, because these numbers can't be collected after the fact.
For the development team · SEO and analytics for product pages
Render product pages on the server (SSR) or pre-build them, so the name, price and stock status are in the HTML. Add Product and Offer structured data that matches the page. Variant pages that differ only by size or color point their canonical to the main page. Use the OutOfStock status for items that are temporarily sold out, and 301-redirect discontinued items to the closest page. In GA4, send the standard events view_item, add_to_cart, begin_checkout and purchase. Fire purchase once, after payment is confirmed, with a transaction_id to prevent double counting, and turn on analytics and advertising tags only after the customer consents.
Who looks after the shop after launch
Work keeps coming after launch day. Marketplaces update their APIs, couriers change their label formats, and customers hit problems at 9 p.m. on a campaign night. Before you sign, ask who takes the call when the site goes down, how many hours they have to respond, and which problems have to be fixed immediately.
This agreement is called an SLA. Write down whether it covers holidays and campaign days, and which work is included in the monthly support fee. Ask for a staging site, a copy of the shop for trying out changes before they reach the live store, and make sure the domain, code and database are in your company's name. How to read each developer's answers is covered in how to choose a software house in Thailand.
The 12-part checklist to send to developers
This table works with any developer. You answer the first column yourself, the developer answers the second, and the last column says whether the item must be ready at launch or can wait for phase two.
| Section | You answer first | Ask the developer | Day one or later |
|---|---|---|---|
| 1. Product catalog | How many products, how many sizes or scents, who updates them | Can products be imported from a file and prices edited in bulk? | Day one |
| 2. Cart and checkout | Can people order without signing up? Do you need to issue tax invoices? | When do customers see the shipping fee? How many fields before they can pay? | Day one |
| 3. Payment | Which methods you accept, who approves refunds | Does card data pass through the shop's server? Are payments confirmed automatically? | Day one |
| 4. Shipping | Which courier, how shipping is charged, cash on delivery or not | Can the system print labels and send tracking numbers itself? | Day one |
| 5. Stock across channels | Which channels you sell on, whether product codes match yet | Does it connect through official APIs? What happens when the connection breaks? | Day one, if you sell on marketplaces |
| 6. Back office and user roles | Who does what | What does each role see? Is there a log of who changed what? | Day one |
| 7. Members and points | What benefits you want to give regulars | How do points expire? Can coupons stack? | Later |
| 8. PDPA, consent and privacy | What data you collect and why, who reviews the wording | Does the system record consent and handle deletion requests? | Day one |
| 9. Speed and SEO | Is there an old site to migrate? | How fast are product pages on a phone? How will old URLs be moved? | Day one |
| 10. Measurement | Which numbers you want to see every week | Do the sales in Analytics match the back office? | Day one |
| 11. Other systems | Which accounting software or CRM you use | Is data sent automatically or as a file? | Later |
| 12. Support after launch | Who in the shop reports problems | What response time does the SLA promise? Who holds the domain and code? | Day one |
How to use the checklist with developers
- Fill in the first column completely. Where you can't answer yet, write "don't know yet" rather than guess.
- Send the same file to everyone. Attach sample orders with customer names, phone numbers and addresses removed.
- Ask for an answer per section. Included in the scope, available as an extra, or not offered.
- Lay the answers side by side in one table. A section one developer includes and another doesn't is often where the price difference comes from.
- Ask the developers still in the running to walk through one order on the system they would build for you, from the customer paying to accounting closing the books. Whoever can tell the whole story without opening a slide deck understands your shop.
Hypothetical case
A scented candle and reed diffuser brand in Bangkok (name and details invented) has sold on Shopee and Lazada for two years and decides to open a website. The owner and two admins fill in the checklist together one afternoon. The hardest box is shipping, because candles in glass jars break easily and the shop has always priced shipping case by case. Once the rules are settled, the owner sends the same file to three developers.
The answers differ sharply. The first includes loyalty points at launch but still has customers transfer money and send a slip. The second confirms PromptPay payments automatically but says nothing about PDPA. The owner moves points to phase two and puts automatic payment confirmation at the top of the list, because during last year's gift season the admins lost half of every day matching slips. The job goes to the developer who could trace a single candle order all the way to closing the books.
From checklist to a shop your team can run every day
The first column of the checklist is your job, because the people in your shop know the shipping rules, discounts and returns better than anyone. DNA Maker reads those answers with the owner, the admins and the accountant, then follows one real order with them all the way to closing the books. From there we write up the order workflow, the rules for coupons and shipping, and the screens for each role, for your team to check before any code is written.
Our team in Bangkok then builds the store through our e-commerce development service, one section at a time in the order we agree. The store on your domain takes cards, PromptPay, mobile banking and installments, and card data never passes through the shop's server. Orders go to the courier with tracking numbers, stock matches Shopee, Lazada and TikTok Shop, and sales flow into your accounting system without rekeying. Every section is built by DNA Maker's own team, with no subcontracting. If you need a different kind of site, see our website development page, or send us your filled-in checklist and we'll answer it section by section, the same way you'd ask any other developer to.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
| Term | What it is | A simple example | What executives should ask the development team |
|---|---|---|---|
| Payment Gateway | A provider that collects card or PromptPay payments on the shop's behalf and reports the result back | The customer enters card details on the provider's page, and the shop receives only the result that the payment went through | Do our customers' card details pass through our server? |
| Webhook | A message another system sends the moment something happens | The payment provider sends a message saying this order has been paid | If a webhook never arrives, which status does the order get stuck in, and who finds out? |
| Event Tracking | Recording customers' key actions on the site to see where they drop off | Counting people who add to cart but don't pay | Does the purchase total in Analytics match the real sales in the back office? |
| Consent | Permission the customer has given clearly, with a record of when and for what | A newsletter checkbox that is separate from the order button | If a customer withdraws consent, when does the system stop sending messages? |
| SLA | A service level agreement that states how quickly the support team must respond and fix problems | The site goes down on a campaign night, and the support team responds within the agreed time | Does the response time include holidays and campaign days? |