Glossary
Glossary
AI Agent, RAG, ERP, digital transformation — terms we get asked about most often. Each entry gives a one-sentence definition plus the common misconception worth knowing before you decide.
AI Agent
An AI agent is an AI system that can plan steps, call tools, and carry out tasks on its own, rather than just answering single-turn questions like a chatbot.
Picture a 50-person trading company whose support inbox gets a hundred-plus price and shipping-status emails a day: just sorting, cross-checking against the order system, and drafting replies eats up most of a staffer's morning, and things still slip through by month-end. An AI agent can read each email, look up order status, and draft a reply for a human to approve — exactly the kind of 'rule-bound but still language-heavy' work agents are built for, which is why support, document classification, and internal knowledge lookup are the usual starting points. But once an inquiry involves price negotiation or reading a long-time client's relationship and exceptions, an agent alone can't replace that judgment call. On cost, Taiwan's 2026 market roughly splits into three tiers: a single-scenario PoC runs about NT$150k-500k, a department-level rollout about NT$800k-3M, and an enterprise-wide deployment can exceed NT$3.5M, with the gap driven mainly by how many systems it touches and how strict the security review is. The common misconception is assuming an agent can handle any task; one-off, highly creative, or exception-heavy work usually isn't a good fit, so map the use case before buying the technology, or you end up with a system nobody actually uses.
API Integration
API integration lets different systems automatically exchange data through application programming interfaces — for example, connecting payment gateways, logistics providers, LLMs, or existing enterprise systems.
API integration is one of the most consistently underestimated line items in custom software development, especially when connecting to existing systems — it sounds like 'just wiring up an interface,' but the actual details run far deeper than that. Take legacy-system renewal: if a company mainly lacks external connectivity and the core system is otherwise stable, API-wrapper integration — leaving the legacy core untouched and adding an interface layer on top — costs about NT$500k-1.5M and takes 6-12 weeks for a mid-sized case; a full rewrite of a system the same size, by contrast, can run NT$1.5M-5M and stretch to 4-9 months, several times the cost and time. A common misconception is underestimating testing and debugging cost: when a legacy system lacks documentation or has unstable APIs, debugging can eat up a third or more of the whole project timeline, making it the part of a quote most often lowballed and the most common cause of delays. Picture a food factory connecting its e-commerce order feed: the feature work often takes just two weeks, while confirming data-format consistency and handling the platform's occasional API hiccups and version updates ends up taking over a month. If the legacy system can't even export basic data, API integration may have nowhere to hook in — that's the point to evaluate replacing the system rather than forcing an integration that's bound to stall.
Custom Software
Custom software is a system designed and built from the ground up for a company's specific needs, turning requirements, workflows, and data into a scalable, maintainable digital asset.
The real difference between custom and off-the-shelf software isn't price — it's whether the software bends to fit existing business processes. Packaged software asks a company to adapt its workflow to the system's logic; custom software flips that, shaping the system around how the company already works, no forced compromises needed. Typical SMB custom projects in Taiwan run NT$300k-2M, covering everything from a simple internal tool to a mid-sized customer-facing platform, with an MVP usually launching in 6-12 weeks to validate whether the core functionality actually fits. Picture a fleet-management company that can't find an off-the-shelf system matching local regulations and its billing logic — custom development costs more upfront but saves, year after year, the cost of reworking processes every time a packaged vendor pushes an update. A common misconception is assuming custom is always far pricier than packaged software — in reality it depends on feature scope and integration complexity, and a simple internal tool can be quite affordable, while forcing an ill-fitting package to save money often generates more hidden cost in manual workarounds. If requirements are highly standardized and a mature off-the-shelf option already exists, buying it outright is usually the better call — custom isn't the default answer.
Digital Transformation
Digital transformation is the process of converting paper-based, spreadsheet-driven, or legacy-system workflows into traceable, auditable, data-driven digital systems.
Traditional-industry digital transformation works best on staged 3-6-12-month milestones rather than one big push: the first 3 months tackle the single most painful, quickest-to-prove workflow, such as replacing paper material-requisition slips with phone-based scan logging; once that's validated, expand within 6 months to similar workflows, such as covering both inbound and outbound logging; by 12 months, move into cross-department data linkage, such as connecting production records to financial reconciliation. The real challenge is usually not the technology itself but aging systems, fragmented data, and resistance from floor-level operators — picking a first-stage workflow that touches too many departments and too many habits at once tends to stall in the awkward phase where everyone agreed in the meeting but nobody actually started using it. A common misconception is attempting a full transformation all at once, digitizing every paper process simultaneously, which leaves floor staff juggling old and new systems in parallel and actually slows daily work while morale takes a hit. If a company is small enough that one person already has full visibility into a simple process, forcing a staged system rollout can cost more in administrative overhead than just keeping things as they are — a well-built spreadsheet template with a fixed checklist may already be enough.
ERP (Enterprise Resource Planning)
ERP is management software that integrates a company's core processes — orders, inventory, finance, production — into a single system, replacing work that's otherwise scattered across multiple tools.
Picture a 30-person trading company still running purchases, sales, and client reconciliation on Excel: as order volume grows, version chaos, slow reconciliation, and numbers that don't match across departments start piling up — the classic signal that it's time to evaluate an ERP. Taiwanese SMEs adopting ERP roughly have three paths: a packaged solution using the vendor's existing modules, configured rather than built, costs about NT$300k-800k and takes 2-4 months, suited to companies whose processes already resemble industry standard; a custom path that substantially reshapes process logic on top of a package stretches to about 4-8 months; and if it also needs to connect e-commerce platforms, POS, or existing finance systems, that's system-integration territory, potentially running NT$1.5M-6M+ and 6-12 months. A common misconception is assuming ERP adoption means replacing every system — the more common and more prudent approach is integrating the one or two most painful data gaps first, running the ERP alongside existing systems, validating, then expanding scope. If a company has fewer than 10 people and processes simple enough for a single spreadsheet, ERP's ROI is usually low — that budget is often better spent on a more urgent problem, like order intake or inventory staffing, and better matched to the company's actual scale.
Fine-Tuning
Fine-tuning retrains a model's parameters on a large set of examples so it consistently responds in a specific tone or performs more accurately on a narrow task.
Plenty of companies hear 'custom model' and jump straight to fine-tuning, assuming it's the only way to get something truly tailored — but it's actually an advanced option, not a starting point, and jumping in too early often burns budget without a matching payoff. Fine-tuning suits a use case that has already stabilized with enough consistently labeled data, for example a document-classification task that has run smoothly for six months and accumulated thousands of human-verified answers, with a clear sense of what actually needs adjusting. A common misconception is expecting fine-tuning to make up for too little data — in practice, an AI agent typically needs 1-3 months after launch before its efficiency or cost gains become clear, and the data gathered in that window usually isn't enough to support a meaningful fine-tune yet, so jumping in early just wastes budget and delays launch. When data is thin or the use case is still shifting, fine-tuning's ROI is usually low; using RAG first to wire up the knowledge base and accumulate real feedback while the system runs is typically the more practical, cheaper starting point — fine-tuning is worth evaluating once things settle, not treated as a default line item from day one.
IoT (Internet of Things)
IoT connects physical equipment through sensors and networks to collect and transmit operational data in real time, forming the foundation of smart factories and intelligent manufacturing.
Picture a food factory where utilization has always been eyeballed by a veteran operator walking the floor — IoT sensors can start on the one or two machines that cause the most trouble, streaming operating data back in real time so a manager sees, for the first time, an actual number for how long a machine really sits idle each day and where the bottleneck is, instead of a verbal estimate. Common applications include utilization monitoring, real-time production analytics, and predictive maintenance, and the usual advice is to pilot on a single line first, confirming data can be collected and interpreted reliably, rather than rolling out plant-wide and risking wasted spend. On payback, smart-manufacturing projects run longer — about 1-3 years — versus a pure process-digitization project (order management, inventory counts, typically 6-18 months), because IoT adoption adds hardware procurement, line integration, and time to accumulate usable data on top of system build-out. A common misconception is buying sensors before deciding what to monitor — the right order is identifying the key metrics worth tracking first, then choosing sensors and sampling frequency. If equipment is old enough to lack even basic communication interfaces, evaluating equipment replacement first, rather than bolting sensors onto machines that can't support them, avoids collecting data that ultimately can't be used.
LLM (Large Language Model)
An LLM is an AI model trained on large volumes of text that can understand and generate natural language, serving as the core engine behind AI agents and chatbots.
The first misconception many companies run into is assuming the LLM itself already knows their internal information — in reality it only holds the general knowledge from training, much like a new hire who knows the industry but not the company's internal workflows, and needs something like RAG to answer company-specific questions. That basic distinction has to be clear before evaluation even starts, or the gap gets mistaken for a system malfunction. Leading LLMs include GPT, Claude, and Gemini, and the factor most often overlooked in selection is price: within the same vendor's lineup, the gap between economy and flagship models can run over a hundredfold — OpenAI's economy tier costs about $2.4 per 10,000 conversations versus about $350 for the flagship — so picking the wrong tier can mean an annual cost gap of over NT$1M, often more worth attention up front than any performance bump. Economy models are usually plenty for support-email triage or FAQ answering; flagship tiers only earn their keep on complex reasoning, contract review, or cross-paragraph logic — 'more expensive' isn't automatically 'safer,' and matching the tier to actual task difficulty, not budget, avoids padding the monthly bill for no real benefit.
MVP (Minimum Viable Product)
An MVP is the smallest working version of a product that includes only its core functionality, built to validate whether the direction is right at the lowest possible cost.
Custom software timelines typically run in three stages: an MVP launches in about 6-12 weeks with only the core functionality needed to validate direction; it then expands, based on feedback, into a department-ready full feature set over roughly 3-6 months; only after that comes long-term maintenance and iteration — each stage carries a different budget and effort profile. A professional team delivers the MVP stage in two-week cycles, so the client can keep confirming direction and catching gaps early, instead of working heads-down for three months and only seeing the result at the very end, when it's too late and far costlier to change scope. Picture a fleet-management startup: rather than building dispatch, billing, and reconciliation all at once, it's more practical to build 'dispatch' — the single most painful workflow — as the MVP first, confirm that drivers and dispatchers actually want to use it, then add billing and reconciliation module by module. A common misconception is treating an MVP as a 'stripped-down final product' — its purpose is validating a hypothesis, not shipping half the features; if requirements are already locked and the scope is large enough, planning the full system directly can be more efficient than detouring through an MVP just to follow a methodology.
PoC (Proof of Concept)
A PoC is a small-scale effort to validate, at minimal cost, whether a technical approach or use case is actually viable — it's not yet complete enough for production use.
AI agent adoption typically runs in two stages: a PoC takes about 2-4 weeks to produce a working version, meant to validate whether the use case is viable and the data is good enough to support retrieval or answering; once that's confirmed, it moves into full production deployment — integration, monitoring, compliance — which usually takes another 6-12 weeks before it's truly live. Picture a food factory evaluating a quality-anomaly reporting bot: the PoC stage only needs historical anomaly records to test whether the model classifies correctly and gauges severity, without touching live production data, which keeps cost and risk low; only once accuracy clears an acceptable bar is it worth investing in full integration. A common misconception is pushing a PoC straight into production — a PoC usually hasn't handled exceptions, access control, or formal monitoring yet, and putting it into production unsupervised means a wrong call goes unchecked, making it riskier than not using AI at all, essentially handing untested work straight to the front line. If a use case is complex enough that even a PoC can't show clear direction within a month, that usually means the problem itself isn't well defined yet — spending an extra week clarifying scope is often more useful than another two weeks of coding.
Prompt Engineering
Prompt engineering is the practice of designing and refining the instructions given to an AI model so its output better matches what you actually need.
Many assume a prompt only needs writing once, but how users actually phrase things drifts over time — a support bot might go live and only then reveal that customers say 'when will it get here' instead of 'delivery time,' or use a product's nickname instead of its model number, and gaps like that only get closed through post-launch tuning, not a single upfront draft. Prompt engineering work is concentrated in the optimization phase after an AI agent goes live: adjusting tone, narrowing what it's allowed to answer, and preventing it from making commitments it isn't authorized to make. Combined with RAG knowledge-base work, this typically runs 35-45% of a project's budget — an ongoing maintenance cost, not a one-time fee. A common misconception is treating prompt engineering as a one-off copywriting task handed to whoever's available and unfamiliar with the system's actual behavior; without someone tracking real user questions and iterating the prompts, answer quality quietly degrades over time instead of improving on its own — the common, hard-to-diagnose reason satisfaction and complaints both climb three months after launch, usually traced back to prompts nobody ever touched again.
RAG (Retrieval-Augmented Generation)
RAG is a technique where an AI model retrieves relevant information from your own documents before generating an answer, rather than relying only on what it learned during training.
Many assume that getting AI to understand company data means training a proprietary model first, often months of data collection and labeling — in most cases it's enough to have internal documents, FAQs, and manuals, and let RAG retrieve from them before answering. No training from scratch is needed, and updating knowledge is as simple as swapping a document, which keeps maintenance far cheaper. Picture a food factory rolling out a support bot: feed it the SOPs, common complaint procedures, and return policies, and the agent can retrieve and answer on the spot, without waiting on a data science team to write code — updating the source documents quarterly is often enough to keep answers current. On cost, RAG-related development and knowledge-base setup typically account for 35-45% of an AI agent project's budget, the single largest cost line and the part most worth scrutinizing at acceptance. A common confusion is treating RAG and fine-tuning as interchangeable: RAG solves 'the model doesn't know your data,' while a problem like 'the model's tone or judgment logic needs adjusting' belongs to fine-tuning or prompt engineering instead — different layers of the problem that shouldn't be expected to substitute for each other.
SaaS (Software as a Service)
SaaS is software delivered over the cloud on a subscription basis, letting users access full functionality without installing or maintaining their own servers.
The difference between SaaS and custom development is often oversimplified as 'subscriptions are cheaper,' but comparing five-year total cost of ownership (TCO) usually shows the gap is under 5% — at a mid-sized deployment scale, SaaS runs about NT$3.7M versus about NT$3.69M for custom, so the real difference isn't total price but data control and long-term flexibility. SaaS fits scenarios like analytics platforms or online-education systems that need fast launch and multi-tenant architecture, with third-party API/SaaS subscription fees typically running NT$16k-160k a month, climbing year over year with usage and headcount rather than being a one-time payment. Picture an early-stage online-course company: using SaaS to quickly wire up enrollment and payments is a reasonable, practical starting point, but as the user base grows and platform limits start to cap growth, the steadily rising subscription cost becomes a real issue. A common misconception is that SaaS is always cheaper than custom — subscription costs compound over time, and functional flexibility is capped by the platform itself. If requirements are highly standardized and the company has no engineering capacity to run its own system, SaaS remains the faster, lower-risk choice — starting there and switching later, once you actually hit a real bottleneck, is fine too.
Smart Factory
A smart factory uses IoT sensors, real-time data analytics, and automation to give production processes real-time monitoring and decision-support capability.
Smart-factory capability typically builds up in three layers rather than arriving all at once: the first is equipment monitoring, knowing utilization and why machines stop; the second is real-time production analytics, putting multiple machines' data on one dashboard to compare and spot bottlenecks; the third is quality prediction and predictive maintenance, using historical data to anticipate failures and schedule upkeep ahead of time. Picture a mid-sized parts manufacturer that has sensors installed but the data just sits on a hard drive nobody looks at — that's only half of layer one done. Without a dashboard and someone responsible for reviewing it regularly, no volume of collected data turns into a decision, which is the most common misconception: assuming sensors alone make a factory 'smart.' On payback, smart-manufacturing projects typically need 1-3 years to show clear returns, longer than pure process digitization (6-18 months), which calls for more patience and staged planning. If a factory's order volume is small and its production mix changes before data even stabilizes, the analytical value of going smart is limited — straightening out scheduling and staff handoff rules first is likely the better return.
System Integration
System integration connects multiple existing systems within a company (such as ERP, MES, CRM, and finance) to close data gaps and let information flow correctly between them.
The key difference between system integration and 'adopting a new system' is that the goal usually isn't replacing everything with a single monolithic package — it's making sure information is entered once and flows correctly between existing ERP, MES, CRM, and finance systems, cutting down on duplicate data entry and reconciliation errors. Picture a larger company operating across multiple sites with 150+ users: a system-integration project at that scale can run NT$1.5M-6M+ and take 6-12 months, well above a simple packaged-software rollout, because the focus isn't building new features but the long-term consistency and stability of the data connections themselves. A common misconception is trying to integrate everything at once — the steadier approach integrates the one or two highest-impact data gaps first, say automating reconciliation between the order and finance systems, validates the results, then expands scope, rather than wiring up five or six systems simultaneously and multiplying the failure risk. If a company is small, runs only one or two systems, and those systems already support basic export/import, a formal integration project may not be necessary — periodic manual export-and-compare may cover the current scale just fine, with integration budget saved for when the company actually expands to multiple sites and systems.
Technical Debt
Technical debt is the extra cost of maintainability that accumulates when shortcuts are taken to speed up development in the short term — it has to be 'repaid' with extra time and effort later.
Technical debt isn't just a vague way of saying 'the code is messy' — it has a measurable cost: per McKinsey's CIO survey, companies redirect an average of 10-20% of their new-product tech budget to technical-debt-related issues, CIOs estimate debt at 20-40% of total tech asset value, and 60% of CIOs say debt has risen noticeably over the past three years. Common sources include missing tests, rushed architecture decisions, and incomplete documentation — especially likely in projects delivered by a single freelancer and passed through several different engineers afterward. There's a simple rule of thumb for whether to patch or rebuild: once a given area's technical debt exceeds 50% of its tech-asset value, rebuilding's payoff starts to outweigh continued patching — most situations haven't hit that threshold yet, so patching usually beats a full rewrite. Picture a trading company running an eight-year-old system: rather than spending heavily on a full rewrite, it's more efficient to first map which modules are actually slowing new feature work and pay down debt there specifically. A common misconception is that technical debt only affects engineering morale — in reality it directly slows future feature development and amplifies risk during scaling or a team handoff, a real cost that shows up in quotes and launch timelines, not just code review comments.