When someone at a factory in Thailand says “let’s turn this paper form into an app,” the first obstacle is never the technology. It is deciding where to draw the boundary. Do we build it ourselves with no-code, or do we hand it to an outside partner? In practice it is not a binary choice at all. Useful business app development starts by splitting the app into layers and deciding who owns each layer and for how long. This article breaks a factory app into four layers, then walks through how to read a quote, what changes in Thailand, the failure patterns that repeat, and a 90-day path to getting the first app live.
What Business App Development Really Is | Four Layers of a Factory App
From the outside, a factory business app looks like one thing, a screen you tap on a tablet. Inside, it is four layers stacked on top of each other, and those layers have almost nothing in common. If you skip this distinction and simply say “we are building an app,” the in-house versus outsourced debate never converges, because each side is talking about a different layer.
Input UI Layer | The Screen Operators Touch
This is what the operator actually touches. Daily reports, inspections, defect logging, goods in and out, pre-shift equipment checks. It is tied directly to hand movements and to the physical layout of the line. This is the layer that changes most often and lives the shortest. Line rebalancing, product changeovers, and audit responses can force quarterly changes. The upside is the mirror image of that: it is also the layer you can afford to rebuild, even if the first version is rough.
Business Rules Layer | Judgments and Branching
“Notify the supervisor above this value.” “Route this defect code back for reinspection.” “Assign lot numbers using this rule.” These judgments outlive the screens, and getting them wrong corrupts the quality record itself. Someone has to be able to trace, months later, who wrote a rule and why the threshold is what it is.
Data Foundation Layer | Storage and Reuse
Masters (product, process, equipment, operator), history tables, permissions, backups, retention periods. Decide these once and you live with them for years. This is the most expensive layer to fix after the fact, and building it casually means every new app you add duplicates the same master data in another place.
Core Integration Layer | The Link to ERP and Production Control
The handoff to accounting, inventory, purchasing, and order management. Integration failures surface as numbers that do not match, which means they surface in front of finance and head office, so the blast radius reaches outside the plant. Specifications, test evidence, and a documented recovery procedure all have to be delivered here, not just working software. For how the core systems themselves get built and priced, see our guide to business system development cost and process.
Four Layers Make the Decision Simple
Once you separate the layers, the decision rule collapses into a single principle. The higher the layer, the better it suits in-house and no-code work. The lower the layer, the more it needs outsourced development and documentation. Input screens are faster and more usable when built by people close to the floor. The data foundation and the core integration have to survive a change of designer. That asymmetry is the foundation for every judgment that follows.
| Layer | Change frequency | Expected lifespan | Best build method | Required deliverables |
|---|---|---|---|---|
| Input UI | High | Months to 1 year | In-house and no-code | Screen inventory and operating steps |
| Business rules | Medium | 1 to 3 years | In-house plus external review | Rule definitions and change history |
| Data foundation | Low | 3 to 7 years | Outsourced development | ER diagram, master definitions, permission matrix |
| Core integration | Low | 3 to 7 years | Outsourced development | Interface spec, test spec, recovery procedure |
In-House, No-Code, Outsourced | Where the Boundaries Fall

There are three broad ways to build. The starting point is not which one is better, but the understanding that the right answer changes depending on which layer you point it at.
Where No-Code and Low-Code Win
No-code and low-code are overwhelmingly fast in the input UI layer and in light business rules. The value of fixing something the same day a supervisor says “we need this field too” can outweigh any methodology argument. The market keeps expanding as well. Research published by ITR (Information Technology Research) on February 5, 2026 put the low-code and no-code development market in Japan at 99.4 billion yen in fiscal 2024, with fiscal 2025 expected to grow 14.9% year on year and a CAGR of 12.9% forecast for fiscal 2024 through 2029. Those figures are based on a survey of 22 vendors in Japan. Global market sizing has a far wider spread, with different research firms publishing materially different values for the same forecast year, so basing an investment decision on any single firm’s number is risky.
No-code also has a structural weakness. The logic gets buried inside screen configuration and never surfaces as documentation. That is not a problem while the person who built it can still explain it. It becomes one the moment a Japanese expatriate rotates home or a Thai IT staff member changes jobs, because the explanation leaves with them.
Where Outsourced Development Is Required
The boundary is crossed as soon as the app touches any of the following.
- It affects numbers that leave the plant, such as accounting, inventory, or costing
- It serves as a quality or traceability record shown in internal or customer audits
- Multiple apps share the same master data
- It pulls data directly from equipment, PLCs, or measuring instruments
- Production stops, or shipment decisions become impossible, when it goes down
If any of these apply, you should be buying specifications, test results, and a recovery procedure, not just something that runs. If none of them apply, building it in-house and putting it in front of operators first is usually faster and cheaper.
Package Software Implementation Support as a Third Option
There is a middle path that is neither self-built nor custom-developed, which is deploying an existing package and adapting your operation to it. Packages are strong wherever the work is already standardized, such as accounting, attendance, and inventory. In those areas the job of package software implementation support is not “building features” but “moving your process toward the shape the package assumes.” Apply the same package to work where there is no reason to be the same as anyone else, such as your own inspection procedures or a process control scheme unique to your plant, and customization can end up costing more than custom development would have.
Comparing the Three
The durations below are the rough figures we work to on our own projects, not industry standards. They swing widely with scope and with the number of systems you integrate.
| Criterion | In-house no-code | Outsourced development | Package implementation support |
|---|---|---|---|
| Time to first version | Days to weeks | 2 to 6 months | 1 to 4 months |
| Speed of change | Same day to a few days | Needs a quote and a schedule | Fast within configuration limits |
| Ease of handover | Weak | Strong, depending on documents | Strong |
| Fit to unique processes | High | High | Low |
| How cost appears | Buried in headcount | Highly visible | Ongoing licenses |
| Suited layers | Input UI and light rules | Data foundation and core integration | Standardized operations end to end |
The Boundary in One Sentence
The practical test is who has to apologize when it breaks. Anything that can be absorbed within the shop floor, where the person responsible can fix it themselves, belongs in-house. Anything that requires an explanation to head office or a customer belongs outside. That line matches your actual accountability structure, which is why it holds up when something goes wrong.
The Cost of Business App Development | Break the Quote Into Five Layers
Looking at cost as “what does the app cost” guarantees you will miss. The cost of a factory business app splits into five layers, and each one grows for a different reason. The figures below illustrate the ranges we quote in real projects, not standard market rates. Change the requirements and the order of magnitude changes with them.
Initial Development | Set by Integration Count, Not Screen Count
What drives initial cost up is not how many screens you have, but how many connections you make to the outside. A self-contained input app usually stays relatively light, whereas a two-way link to an ERP or an existing production control system makes testing and witnessed acceptance effort jump. Assume that every additional system you connect adds a full set of testing, migration, and failure-recovery procedures, not just development effort.
To calibrate a person-month rate, Thai IT salary levels are a useful reference. JobsDB Thailand listing data as of June 2026 shows average monthly salaries for software developers of THB 37,500 in other areas of Bangkok and THB 50,000 in Samut Prakan and Samut Sakhon, along with THB 42,000 for software engineers, THB 46,500 for software test engineers, and THB 93,000 for program managers. These are averages taken from job postings rather than a statistical survey, so they diverge from actual market rates, but the pattern that areas closer to the industrial estates carry higher labor costs matches what you see in real quotes. Read a person-month rate as this salary level plus overhead, management cost, and the burden of the warranty period, and judging whether a quote is reasonable becomes much easier.
Modification Budget | It Bites Hardest in Year One
Shop floor apps generate the most change requests in the first three months after go-live. Handling each one as a separate additional quote means internal approvals never keep up, and the app quietly stops being used. Setting aside roughly 20 to 40 percent of the initial development cost as a first-year modification allowance from the start usually produces a lower total in the end.
Operations and Maintenance | Monitoring, Incidents, Accounts
This covers more than server or cloud fees. It includes adding and removing operator accounts, password resets, verifying backups, and keeping up with OS and application updates. Factory headcount turns over constantly, so if you have not decided upfront who owns account administration, the time of your one or two IT staff quietly evaporates.
Device Cost | Shared or Personal Matters More Than Quantity
Tablet and handheld costs are driven by how they are used, not by how many you buy. With personally assigned devices, damage is handled per person. Shared devices require an operating design that covers charging, storage, cleaning, and spare units for failures. Industrial devices with ingress protection and drop resistance usually carry a much higher unit price than consumer models, but multiply that by how many break per year on the floor and the comparison can flip. Decide this on your actual breakage record, not on a spec sheet.
Network and Infrastructure | The Most Overlooked Line Item
The back of the warehouse, the gaps between metal racking, the outdoor yard, the area around plating tanks. Every factory has places Wi-Fi does not reach. The cost of adding access points, running power, and securing cable routes varies enormously with building structure, and it is not unusual for it to exceed the cost of the application itself. Any quote produced without an on-site signal survey will be revised upward later.
The Five Layers at a Glance
| Cost layer | Main contents | What sets the amount | Easy to overlook |
|---|---|---|---|
| Initial development | Design, build, test | Number of integrations, form complexity | Testing and witnessed acceptance effort |
| Modifications | Post go-live changes | How often the floor changes | Without a budget line, it stalls |
| Operations and maintenance | Monitoring, incidents, accounts | Number of sites and users | Actual hours from IT staff |
| Devices | Tablets and handhelds | Shared or personal, environmental rating | Spares and charging operations |
| Network and infrastructure | Access points, cabling, power | Building structure, RF environment | Quotes without a survey get revised up |
Five Assumptions Specific to Factories in Thailand
Take an article written for factories in Japan and apply it directly, and some parts will always miss. At Japanese-affiliated plants in Thailand, these five points have to be built into the design assumptions.
Multilingual UI | Thai and Burmese on the Same Line
Your operators are not all Thai. Plants where workers from Myanmar, Cambodia, and Laos share the same line are entirely normal. What matters here is less translation coverage than designing text out of the screen. If a screen can be understood through color, icons, photographs, and numbers, you no longer have to retranslate every screen each time a language is added. A practical split is two languages, Japanese and Thai, for supervisor screens, and language-independent design for operator screens.
There is a second issue. Thai text tends to run longer than Japanese for the same meaning, so button labels wrap and break the layout. Making display verification in the longest language an acceptance condition from the beginning cuts down on rework after launch.
Devices and Ingress Protection | Shared-Use Authentication and Rugged Selection
Floor tablets are shared by default and usually live on a shelf. If you try to capture exactly who entered what by forcing an individual ID and password every time, you will get one of two outcomes — either everyone uses a shared account, or the password ends up on a sticky note. Authentication that does not stop the operator’s hands, such as a badge barcode, NFC, or selecting the responsible person once at the start of a process, produces more trustworthy records in practice.
Device selection is constrained by the Thai factory environment itself. High humidity in the rainy season, buildings without air conditioning, cutting oil and plating mist, dust from powder handling. Put a bare consumer tablet into that and it becomes a consumable with a life measured in months, through unresponsive touch panels or corroded connectors. That is why rugged devices with an ingress protection rating, or a combination of a purpose-built case and screen protector, are worth evaluating. The deciding factor is not the rating on the datasheet but how many units actually break per year in that specific process. Where there is no breakage record, the rugged device is over-investment. Where there is one, the price difference is recovered immediately.
One more factor is routinely overlooked, and that is operation with gloves on. Some devices will not register capacitive touch through work gloves, and once operators start removing gloves to use the app, data entry gets postponed. Bring the gloves actually used on the floor and touch a real unit before you finalize the model.
In-Plant Wireless | Make Offline Behavior a Design Requirement
There is always a hole in in-plant Wi-Fi somewhere. An app that never decided what happens when the connection drops loses credibility the instant an operator’s half-finished entry disappears, and it is never used again. You need to assume from the start that entries are held locally and synchronized when connectivity returns, or at minimum define behavior that warns and blocks input while disconnected. If you are also considering digitizing paper forms, our electronic forms implementation guide covers the migration path away from paper.
Hiring and Retaining IT Staff | Design for a Team of One or Two
IT departments at Japanese-affiliated plants in Thailand are typically one or two people, and that one person already carries the network, PCs, the ERP, the multifunction printers, and now the new app. Layer a “we will build everything ourselves” policy on top of that and their time gets consumed by app maintenance while core IT operations stall. Worse, everything becomes a black box the day they change employers. Even if you do pursue in-house development, the condition is being able to recover when one person leaves, meaning you have decided where accounts, source or app definition exports, and design notes are kept.
Salaries reinforce the point. Levels in Samut Prakan and Samut Sakhon, where industrial estates cluster, run higher than in areas outside central Bangkok, and hiring is not easy. Whether you hire and build in-house or place the work outside, do not plan on the assumption that you can hire.
BOI Incentives | Conditions When Software Development Qualifies
In Thailand, development of software, platforms for digital services, and digital content is positioned as a BOI-promoted activity. Announcement Sor. 4/2564, issued September 16, 2021 and effective September 17, 2021, consolidated the former 5.7 software, 5.8 e-commerce, and 5.9 digital services categories into category 5.10. As an A2-equivalent incentive, corporate income tax exemption runs up to 8 years, with a cap based on actual qualifying expenditure. The principal conditions are new hiring of Thai IT personnel with combined annual salaries of at least 1.5 million baht, and carrying out the development process within Thailand under BOI approval.
That said, category numbers and conditions have been revised since, so always check the latest announcement when you are preparing an application. The practical significance here is that pursuing the incentive changes your options for where development happens. Building cheaply offshore and hiring people to build in Thailand are not comparable on the same terms once BOI is part of the picture.
Five Patterns of Business Apps That Fail

Plants where rollout goes badly tend to fail in the same shapes.
Only the Person Who Built It Can Change It
The most common pattern by far. Someone on the floor builds it with no-code, the business rules get embedded in screen configuration, and nothing is ever documented externally. The moment that person rotates home, transfers, or resigns, nobody can change a condition. This is exactly why shadow IT and black-box risk come up repeatedly in general discussions of in-house development. Make “does the operation still run if the builder takes a week off” part of your go-live criteria.
Adding Every Field Management Wants Without Asking the Floor
Turn every metric the management team wants to see into an input field and the time per entry multiplies. From what we have observed on the floor, operators respond by batching entries later in the day, and the data loses both timeliness and accuracy. The principle is to limit input fields to what that operator definitely knows at that exact moment, and to calculate everything else from those values.
Putting Paper on a Screen Unchanged
Recreate an existing paper form on a tablet and everything packed into one A4 sheet becomes a tall vertical form where the scrolling never ends. Paper has high at-a-glance density and screens do not. You need to decompose the work and redistribute it across screens, not digitize the sheet.
Rolling Out to Every Plant and Line at Once
Skip the pilot and go company-wide, and RF dead spots, device shortages, training delays, and exception handling all erupt simultaneously, making root cause analysis impossible. The conclusion becomes “the app is bad,” and the next investment stops. Running one line and one process first, then expanding, actually shortens total elapsed time.
The DX Team Turns Into an Internal Vendor
The team formed to enable in-house development gets flooded with development requests from every department and becomes an internal contract development shop. Because requests are free, they cannot be prioritized, the queue grows, and eventually departments start buying tools on their own. An in-house team lasts longer when it is scoped as the group that keeps building possible, not the group that builds, providing standard templates, shared masters, and reviews.
Ten Items to Settle Before You Request a Quote
Fill in this table before you go out for quotes and the proposals come back in a form you can actually compare. Any quote produced while these cells are still blank will be revised upward later.
| Item to decide | What to write down | What happens if you skip it | Who decides |
|---|---|---|---|
| Scope of target work | Which task in which process, plus what is out of scope | Scope creeps and the schedule slips | Plant manager and process owner |
| Users and headcount | Operators, line leaders, supervisors, and counts | Licenses and device counts cannot be estimated | Production control |
| Devices and usage model | Model, shared or personal, number of spares | Devices arrive that the floor cannot use | Production control and IT |
| Authentication method | Individual ID, badge, selection at process start | Shared accounts render the record meaningless | IT and quality |
| Languages | Required languages specified per screen | Full retranslation of every screen after launch | HR and production control |
| Offline behavior | Hold and sync, or block input | Data loss destroys trust on the floor | IT |
| Integrations and direction | System name, fields, frequency, one-way or two-way | Test effort is unknown and the price rises | IT and finance |
| Retention and permissions | Years retained, who can view, deletion rules | Cannot produce records in an audit, or data leaks | Quality and administration |
| How changes are handled | Annual modification allowance and request channel | Updates stop three months after go-live | Administration |
| Handover conditions | Documents, accounts, export methods delivered | One resignation turns everything into a black box | IT and plant manager |
How to Use This Table
You do not have to settle everything precisely. What matters is recognizing that the blank cells are the source of future cost increases and disputes, and stating explicitly in your request for quotation that those items are undecided. Between a quote that names its unknowns and one that hides them, the second is always more expensive in the end.
A 90-Day Path to Your First App

For the first app, resist adding features and make hitting the date the objective. What the floor judges first is not how many features it has, but whether what you said would appear actually appears.
Days 1 to 30 | Narrow to One Process and Measure the Signal
Target one line and one process, with ten users or fewer. The single most important activity in this period is not requirements interviewing, it is on-site measurement. Collect signal strength in the target area, where the device will sit, and how free the operator’s hands are. Take physical copies of the existing paper forms with real entries on them, and document the exception handling, meaning who writes what by hand and under what circumstances. Finish filling in the ten-item table above within this window.
Days 31 to 60 | Harden the Input UI on the Floor
In this period you take working screens onto the floor and have people use them. A meeting room review cannot reproduce gloves, lighting, noise, or where the operator stands. Running a cycle of 15 minutes on the actual line, once a week usually brings screen feedback to convergence within a few rounds. Keep the data foundation and business rules layers minimal at this stage, and do not touch core integration at all.
Days 61 to 90 | Run Production on One Process Alongside Paper
Do not abolish paper immediately. Run paper and the app in parallel for two to four weeks. Check whether the record counts match, whether entry takes less time than paper did, and whether line leaders can use the output for their tallies. If you reach a state where you can make the decision to stop using paper, that first app is a success. If not, close out the causes without widening the scope.
What Comes After Day 90
Only from the second app onward do you take on shared data foundations and core integration. Carve the masters used by the first app out as shared masters, and have the second app reference them. Follow that sequence and the number of things you administer does not grow as the number of apps does. Try to design a company-wide shared foundation from the first app and you will never ship within 90 days. For how to evaluate a development partner, our guide to choosing a system development company in Thailand is a useful reference.
The Path in Summary
| Period | Main activity | Completion test |
|---|---|---|
| Days 1 to 30 | Fix the target process, measure RF and the floor, settle the ten items | Zero undecided items, or they are stated explicitly |
| Days 31 to 60 | Iterate the input UI on the line | Screen change requests converge |
| Days 61 to 90 | Production use on one process, parallel with paper | You can decide to stop using paper |
| Day 91 onward | Carve out shared masters, add core integration | The second app references the first app’s masters |
Frequently Asked Questions
How much does business app development cost?
There is no answer to “what does one app cost.” The amount is set by the number of integrations with external systems, the number of users, and the state of your devices and network, not by screen count. Comparing initial development cost alone tells you little, so look at all five layers including the modification allowance, operations, devices, and network. As a reference point, JobsDB Thailand listing data as of June 2026 shows average monthly salaries for software developers in a range of roughly THB 37,500 to 50,000, trending higher closer to the industrial estates. These are averages from job postings rather than a statistical survey, so they diverge from actual market rates. Read a person-month rate as that level plus overhead and warranty burden, and judging a quote gets much easier.
Can we develop a smartphone business app in-house?
For the input UI layer, absolutely. With a no-code platform, apps such as inspections, daily reports, and simple defect logging are well within reach of staff on the floor. There are three conditions. Someone other than the builder must be able to change it, the IT function must know where data is stored and how it is backed up, and it must not connect directly to core systems. Drop any of those three and a convenient app becomes an untouchable asset a few months later. When smartphones are involved, note that information management design changes substantially depending on whether the devices are personal or company-issued.
What is the difference between package implementation support and custom development?
Package implementation support is the work of moving your process toward the shape the package assumes. Custom development is the work of building to fit your process. Standardized operations such as accounting, attendance, and inventory favor packages, where the value of implementation support lies in configuration, data migration, and building operating rules. For work where there is no need to match anyone else, such as your own inspection procedures or a unique process control scheme, package customization can exceed the cost of custom development. Asking yourself whether this process could be changed to work the way other companies do usually makes the choice obvious.
Who should we ask for manufacturing application development?
Choose on whether they will go onto the floor, not on technical depth. The evidence to look for is experience standing on a production line and observing the work, the ability to run shop floor interviews in Thai, whether they survey the RF and device environment before quoting, and whether the deliverables include specifications, test results, and a handover procedure. Whether a system integrator is genuinely strong in manufacturing shows up in whether they propose a site survey, not in the wording of the proposal.
What should we base tablet selection on for a factory business system?
Screen size, environmental durability, and the charging and storage model. Gloved operation demands capacitive sensitivity, oil and dust demand an ingress protection rating, and drops demand shock resistance. For shared devices, decide the location of the charging station, the handover at shift change, and the spare unit policy in advance, or the tablets will disappear from the floor. The price advantage of consumer devices can disappear once you multiply by annual breakage, so decide on your actual damage record.
Does a system integrator need manufacturing experience?
If you are handing them the data foundation and core integration layers, yes. When you have to explain concepts like process, lot, defect code, and traceability from first principles, you end up validating the design entirely on your own side. If you only need short-term help on the input UI layer, willingness to go onto the floor and speed of response matter more than manufacturing background. Here too, which layer you are delegating determines what you need.
Summary
A factory business app is not a build-or-buy decision. Split it into the input UI, business rules, data foundation, and core integration layers. Let people close to the floor iterate quickly on the upper layers, and place the lower layers outside, documentation and handover included. Simply accepting that asymmetry at the outset resolves most of the in-house versus outsourced argument.
Read cost across five layers, not initial development alone, adding modifications, operations, devices, and network. At factories in Thailand, multiple languages, shared devices, wireless dead spots, an IT function of one or two people, and BOI conditions all become design assumptions. And ship the first app in 90 days with the scope held to one process, then judge it on whether you can decide to stop using paper. Follow that order and the cost of every app after the first drops visibly.
Which layers you keep in-house, and where you hand the work outside, depends on your plant’s staffing and device environment. At TOMAS TECH we are happy to talk at the stage before requirements are fixed, when the question is still which parts you should be doing yourselves at all. Bring photographs from the floor or copies of your existing forms and we can help simply by mapping out which layer to address first. Get in touch through our contact form.
References
- ITR (Information Technology Research) | Press release on the size and forecast of the low-code and no-code development market in Japan, published February 5, 2026 (https://www.itr.co.jp/topics/pr-20260205-1)
- Tilleke & Gibbins | Thailand’s BOI Revamps Promoted Digital Activities (https://www.tilleke.com/insights/thailands-boi-revamps-promoted-digital-activities/12/)
- JobsDB Thailand | Software Developer Salary, listing data as of June 2026 (https://th.jobsdb.com/career-advice/role/software-developer/salary)
- Hitachi Solutions | RPA column on the risks of in-house system development (https://www.hitachi-solutions.co.jp/rpa/column/rpa_vol42.html)
- Daikin Industries ITEC | Manufacturing blog on in-house system development (https://www.itec.daikin.co.jp/manufacture/blog/naisei/)
- Monstar Lab | DX glossary on in-house development (https://monstar-lab.com/dx/about/inhouse-production/)
- GII (Global Information) | Research report listing for the low-code application development platform market (https://www.gii.co.jp/report/ires2011670-low-code-application-development-platform-market.html)