Starting a Thai system development project with a PoC

When you're kicking off a new system project in Thailand, going straight into full development often stalls the first time the floor sees it. Requirements the Japan HQ locked down don't line up with how the Thai side actually runs, Thai staff can't pick up the workflow, and after go-live you find business gaps that break the whole thing. A familiar shape.

What we do instead is run a PoC first. Build something small, put it on the actual floor for a few days to a few weeks, then re-scope full development based on what you actually saw. It ends up faster, cheaper, and less painful in most cases.

What the PoC is for

A PoC isn't "trying to build something." It's collecting the information needed to decide whether to move to full development. Deciding what you're trying to learn is step one.

What we especially want to check in Thai projects: whether the design actually fits the floor's operation (not "matches HQ's assumption"), whether Thai staff can pick up the workflow with no explanation, how the exception cases we always hit on the floor (smudged forms, dropping Wi-Fi, someone unexpectedly out) affect things, and how it lines up with existing workflows and existing systems. None of this shows up in a requirements document. You only see it once something real is running on the floor.

Scoping the PoC

Instead of cutting scope by feature, cut it by "the smallest unit of work that goes end to end." For a shipping-line QC system, don't build only "the Part No check." Build "one Box type going through scan, verification, recording, and next-day report output." Building it through end to end surfaces the problems that only appear when features connect.

The scale we usually run: 2 to 4 week duration, one form, one line, one site.

Designing the PoC as an experiment

The output of a PoC isn't the code. It's the decision material for whether to move into full development. Set the success criteria first, something like "4 out of 5 Thai staff members can pick up the workflow within a 30-minute first-time explanation." A form that lets you look back and judge later. Set the failure threshold at the same time. "If we hear 'this doesn't work' from the floor more than 3 times in one week, count it as failure."

Run a PoC without settling these and the post-PoC discussion of "OK so are we going to full dev?" turns into an argument without ground.

Moving from PoC to production

Once the PoC works you'll be tempted to reuse the code for production. Our default is that full development is rewritten from scratch, and the PoC is designed with that in mind.

Three reasons. PoC code is written to be thrown away, so authentication, monitoring, and error handling are all cut. Building production quality on top of that is slower than starting from a proper production skeleton. Adding the requirement changes the PoC revealed onto existing PoC code creates technical debt. The knowledge from the PoC (UI decisions, business flow, exception handling) carries over to full development even if the code doesn't. That value is preserved.

"Just ship the PoC code as production" tends to be the beginning of trouble, so decide upfront that it's disposable.

When PoC doesn't fit

PoC isn't universal. Some cases are better served by going straight to full development. Deploying an existing system from another site at the same scale unchanged. Regulated, certified, or audited domains where compliance is required from day one (medical, financial). Small projects where the PoC effort and the first month of full development take about the same amount of work. In these cases the PoC layer stops paying off.

On the other hand, for Japanese-affiliated manufacturing order flows, factory floor digitisation, multi-site SaaS rollouts, and other projects where the fit between requirements and floor reality decides the outcome, running a PoC first ends up faster more often than not.

Related: Factory shipping-line QC scan system / AI-powered OCR for Japanese-affiliated manufacturers in Thailand / Offline-first design for factory-floor systems in Thailand

If you're considering a system development project in Thailand, feel free to get in touch.