Skip to main content

กำลังโหลด...

Southern Whale

Case Study: Designing a Map-Based Marketplace Web App in Chonburi, from a Subscription-Bound AI Prototype to an Owner-Controlled System

Local Marketplace / Web AppChonburiweb-app + system-design

Local marketplace startup in Chonburi (name withheld)

Kreangsak S.
Kreangsak S. · Southern Whale team
Desktop monitor and phone showing a marketplace map with store pins and price tags, on a desk beside a whiteboard system diagram

4User groups with mapped workflowsBuyers, individual sellers, stores and admins

18Page routes from the original systemMapped from the prototype, with original URLs kept

3Notification channelsOn-site, email and LINE

GoalNext goal (not yet a result)Launch in Chonburi, then measure stores and seller contacts

Who this case is for

If you have a marketplace or directory idea, or a web app built with AI that is starting to hit its limits, this case shows how we design this kind of system.

The client is a local marketplace startup in Chonburi that prefers not to be named, so this case focuses on our thinking and process.

There are no usage figures yet because the marketplace has not launched. What we describe here is the system design and testing.


The business model: a neighborhood market on a map

Buyers open a map, see nearby stores and products, contact the seller directly and arrange pickup themselves.

  • No payment system: buyers and sellers agree on the price themselves
  • No commission or delivery service: the platform can start without carrying payment and logistics operations
  • One area first: the map starts in Chonburi so buyers see sellers who are actually nearby, and the area rules can expand later

The challenge is trust. Since the platform does not hold anyone’s money, content screening and reporting matter a great deal.


Mapping the existing system first

The owner had used an AI tool and did not know what sat behind the site. We went through every page and function, then summarized them in plain language for review.

The document asked about decisions only the owner could make:

  • Should every listing be approved first, or go live and be checked later?
  • How long should a listing last, and how many photos should it allow?
  • Is on-site chat needed, or are LINE and phone enough?
  • Is Google login needed?

Answering these up front reduces rework and keeps the scope clear for both sides.


Workflows for each user group

User Steps
Buyer Open the map → search or filter → view a product or store → contact the seller → arrange pickup
Individual seller Sign up → post a listing and pin a meeting point → await approval → appear on the map → mark as sold or renew
Store Sign up → apply to open a store → await approval → get a store page and pin → add products and take pickup bookings
Admin Review stores and listings → approve or reject with a reason → handle reports → hide a listing or suspend a user

Each listing has a clear lifecycle. It lasts 30 days, an email reminder goes out 3 days before expiry, and the seller can renew it, which keeps sold items from cluttering the map.


What we planned for

  • Seller privacy: individual sellers show an approximate meeting point rather than a home address
  • Content control: every store and listing needs approval, and admins cannot approve their own content
  • Ownership: users can only edit or delete their own stores and listings
  • Spam protection: forms have filtering and rate limits, and coordinates are checked again by the system rather than trusted from the browser
  • Owner-editable rules: listing lifetime, photo limits, stores per account and the map’s starting point can be changed in the admin area without code changes

The technical details are tailored to each business, so we do not cover them in this case.


Choosing technology from the business plan

We did not start by asking which technology is best. We asked where the business is heading.

  • Launch quickly to test the market: choose a path that goes live fast and is easy to manage
  • Plan for a mobile app or many simultaneous users: choose a structure built for that from the start, even if it takes longer

We presented both paths with their limitations so the owner could decide based on their own business plan.


Testing before handover

We tested real user journeys on a staging site, then removed the test data.

  1. Submit a listing with a photo → pending → admin approval → appears on the map and its product page opens
  2. Chat → store menu → pickup booking → cancellation rules → notifications

Where things stand

The client has agreed to the project. The next step is to launch in Chonburi and measure stores and seller contacts. We will update this case when real data is available.


Checklist before building a marketplace

  • Who pays whom, and does the system really need to hold money?
  • Who reviews content, and how are reports handled?
  • How do sold items leave the system?
  • What location data should stay private?
  • If you stop using your current tool, can you move your data out?

FAQ

Can a site built with AI be moved out? Yes. We start by mapping its pages and functions, even if the owner does not know what system runs behind it.

Can a marketplace work without on-site payment? Yes, if buyers and sellers are in the same area and can meet, but screening and reporting need to be designed well.

What other businesses can use this kind of system? Store directories, secondhand markets, community services, or any business whose customers need to find a nearby location.


Want a system like this?

If you have an idea or an AI-built prototype, send it to us. Message our freelance team on LINE OA.

About the author

Kreangsak S.

Kreangsak S.

Southern Whale team · SEO & WordPress Specialist · Web Developer

Over 10 years building websites and doing SEO, focused on WordPress and e-commerce sites with SEO built in from day one, now using AI to ship faster.

LinkedIn ↗Fastwork ↗Chat on LINE ↗

Have a similar project?

Free consultation · we scope the work before quoting