The most common mistake is starting from the model. "Should we use GPT, Claude, or Gemini?" is the wrong first question, because all three can do most tasks competently. The right first question is narrower: what specific task are we trying to make faster, cheaper, or more consistent?

Write that down in one sentence. Then ask three follow-ups:

• How often does this task happen? Ten times a day and ten times a year need completely different solutions.
• What does a wrong answer cost? A drafting assistant that is occasionally clumsy is fine. A system that misreads a customer's invoice is not.
• Who reviews the output? A human in the loop changes what accuracy you actually need.

Only once you have those answers does the technology choice become obvious — or, often, unnecessary. A surprising number of "AI projects" turn out to be solved by better search, a template, or a script.

Almost everything on the market falls into one of four categories. They differ less in intelligence than in who owns the infrastructure and who carries the running cost.

1. Cloud AI APIs

You send text to a provider's endpoint and get a response back. Pricing is per token — roughly per word. You pay for what you use, with no hardware and no maintenance.

Good for: variable workloads, quick experiments, tasks where the output is reviewed before use.

Watch out for: per-token costs that scale with success. A pilot handling a hundred requests a month can become a four-figure annual bill once it's embedded in a workflow.

2. Self-Hosted Open-Source Models

You run the model on your own hardware — a workstation with a consumer GPU, or a used server — using tools like Ollama or vLLM. Open-weight models such as Llama, Qwen and Mistral are capable enough for summarisation, drafting, classification and internal Q&A.

Good for: steady high-volume workloads, sensitive data that cannot leave your premises, and any use case where predictable cost matters more than peak capability.

Watch out for: the capital cost, and the fact that you now own an uptime problem. Power, cooling and Singapore's ambient temperature all matter.

3. Off-the-Shelf AI Tools

Packaged products with AI inside — assistants embedded in office software, transcription services, meeting summarisers, helpdesk bots. You buy a licence per user and use it as-is.

Good for: generic productivity gains, and organisations without technical staff to run anything.

Watch out for: per-seat pricing that adds up fast, and limited control over where your data goes.

4. Custom Built Solutions

A system assembled around your own workflows — retrieval over your documents, function calls into your internal systems, guardrails specific to your industry.

Good for: processes that are genuinely unique to you, and where accuracy is worth investing in.

Watch out for: the ongoing cost of ownership. Custom systems need maintenance; if nobody owns that, they rot.

Once you know your problem, score each option against six criteria.

Data Sensitivity and PDPA

Under Singapore's PDPA, you are accountable for personal data even when a third party processes it. That means knowing where prompts and outputs are stored, how long they are retained, and whether they may be used for training.

If the data includes customer records, identity numbers, financial details or health information, the calculation often favours self-hosting — not because cloud providers are careless, but because keeping data on-premises removes an entire category of obligation.

Cost Structure

Three very different shapes of cost:

• Per token — scales with usage, near zero to start
• Per seat — scales with headcount, predictable
• Capital plus running cost — a one-off purchase, then electricity, cooling and maintenance

The right choice depends on volume. Low and irregular usage almost always favours an API. Steady, high volume favours owned hardware, where the marginal cost of the next request is essentially zero.

Latency and Availability

An API call travels to another region and back. For a chatbot that is invisible. For anything on a factory floor or in a customer service queue, it is not.

Self-hosted models answer in milliseconds and never rate-limit you — but they go down when your hardware does, and there is no support desk to call.

Accuracy and Model Capability

Frontier cloud models remain ahead on hard reasoning, long documents and multilingual nuance. Open-weight models have closed the gap sharply for everyday work: classification, extraction, summarising, drafting.

A useful rule: if a competent intern could do the task with a good reference document, an open-weight model can probably do it too.

Integration Effort

A tool that plugs into what you already use beats a better tool that needs a custom connector. Count the integration work honestly — it is usually the largest hidden cost.

Maintenance Ownership

Every solution needs someone to notice when it breaks. Name that person before you buy, not after. This is where many pilots quietly die.

Here is the comparison in plain numbers, using indicative Singapore market pricing.

Upfront cost | None | S$800–S$4,000 for a capable GPU box |

Monthly cost | Per token, scales with use | Electricity, cooling, maintenance |

Marginal cost of growth | Rises with volume | Close to zero |

Data leaves premises | Yes | No |

Peak capability | Highest | Good, and improving |

Setup effort | Minutes | Days |

Maintenance | Vendor's problem | Yours |

For occasional use, the API wins outright — there is no sensible case for buying hardware to run a few hundred prompts a month.

For steady volume, the picture changes. A team processing tens of millions of tokens monthly will often find that a single well-chosen GPU workstation pays for itself within a year, and then costs almost nothing per request thereafter.

The honest conclusion: most organisations should start on an API, measure real usage for a quarter, and only then decide whether owning hardware makes sense. Buying a GPU box to test an idea is how spare hardware ends up idle in a corner.

Before committing to either path, measure. Both options can be called from the same Python code, which makes comparison easy.

Calling a Cloud AI API

Most providers expose an OpenAI-compatible endpoint, so this pattern works across them with only the URL and key changing:

import json
import urllib.request

API_URL = "https://api.deepseek.com/v1/chat/completions"
API_KEY = "your-api-key-here"


def ask_cloud(prompt: str, model: str = "deepseek-chat") -> str:
    """Send a single prompt to a cloud AI API and return the reply text."""
    payload = json.dumps({
        "model": model,
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.3,
    }).encode()

    request = urllib.request.Request(
        API_URL,
        data=payload,
        headers={
            "Content-Type": "application/json",
            "Authorization": f"Bearer {API_KEY}",
        },
    )

    with urllib.request.urlopen(request, timeout=60) as response:
        result = json.load(response)

    return result["choices"][0]["message"]["content"]


print(ask_cloud("Summarise this customer complaint in one sentence."))

Running a Model Locally

With Ollama installed, the same task runs on your own hardware — no API key, no data leaving the building:

import json
import urllib.request

OLLAMA_URL = "http://localhost:11434/api/chat"


def ask_local(prompt: str, model: str = "qwen2.5:7b") -> str:
    """Send a prompt to a locally hosted model via Ollama."""
    payload = json.dumps({
        "model": model,
        "messages": [{"role": "user", "content": prompt}],
        "stream": False,
    }).encode()

    request = urllib.request.Request(
        OLLAMA_URL,
        data=payload,
        headers={"Content-Type": "application/json"},
    )

    with urllib.request.urlopen(request, timeout=300) as response:
        result = json.load(response)

    return result["message"]["content"]


print(ask_local("Summarise this customer complaint in one sentence."))

The two functions are deliberately interchangeable. Point your application at one or the other and you can benchmark quality, speed and cost on your own actual work — which is the only benchmark that matters.

Estimating Your Monthly API Bill

Token pricing is quoted per million tokens, which makes comparisons hard. This helper converts your real volumes into a monthly figure:

def monthly_cost(
    tokens_in: int,
    tokens_out: int,
    cost_in_per_million: float,
    cost_out_per_million: float,
) -> float:
    """Estimate monthly API spend from input and output token volumes."""
    input_cost = (tokens_in / 1_000_000) * cost_in_per_million
    output_cost = (tokens_out / 1_000_000) * cost_out_per_million
    return round(input_cost + output_cost, 2)


# Example: 20 million input tokens and 5 million output tokens per month
print(monthly_cost(20_000_000, 5_000_000, 0.28, 0.42))

Run it with your own numbers before you commit. If the result is small, use the API and stop worrying. If it is large, you have just built the business case for owning hardware.

A five-person accounting firm. The goal is to draft routine client emails and summarise meeting notes. Volume is low — perhaps a few hundred prompts a month — and every output is read before it is sent. The answer here is a cloud API and no hardware at all. Even a generous token budget lands in the tens of dollars monthly, and there is nothing to maintain. Buying a GPU workstation for this workload would be a mistake: the machine would sit idle while the firm carried the depreciation.

A forty-person logistics company. The goal is extracting details from thousands of delivery documents a month and routing exceptions to staff. Volume is high, the documents contain customer names and addresses, and the process runs continuously through the working day. Cloud APIs would work, but the monthly bill scales with volume — and every prompt would carry personal data off-site, adding PDPA obligations. This is the profile where a self-hosted open-weight model on owned hardware becomes the cheaper and simpler option: predictable capital cost, no per-request charge, and the data never leaves the building.

The lesson is not that one option is better. It is that volume and data sensitivity decide the answer, and they decide it long before model capability does.

• Starting with the model. The tool follows the problem, never the reverse.
• Ignoring the cost of review. If every output needs checking, the saving is smaller than the demo suggested.
• Assuming accuracy is uniform. Models are strong on some tasks and unreliable on others. Test on your data.
• Buying hardware to experiment. Prove the use case on an API first, then buy.
• Forgetting maintenance. Someone must own updates, monitoring and breakage.
• Treating data privacy as a legal afterthought. Work it out before the first prompt, not after.
• Skipping measurement. "It feels faster" is not evidence. Time the task before and after.

A few local factors genuinely change the decision:

• PDPA obligations apply to personal data regardless of whether processing happens locally or overseas. Self-hosting simplifies the story; it does not remove the duty.
• Latency to regional datacentres is excellent from Singapore, so cloud APIs feel fast here in a way they may not in more remote markets.
• Power and cooling costs are high. Singapore's warm, humid climate means mechanical cooling year-round. If you self-host, budget realistically for running costs — and remember that heat degrades hardware faster here than in a temperate datacentre.
• Grant support may be available for technology adoption and workforce training, which can materially change the payback period. Worth checking before you rule out either path.

A disciplined month beats six months of dithering.

Week 1 — Define. Write the single sentence describing the task. Identify who currently does it, how long it takes, and who would review AI output.

Week 2 — Try the API. Build the smallest possible version using a cloud model. Measure time saved and quality on twenty real examples.

Week 3 — Try local. Install Ollama or similar on existing hardware and run the same twenty examples. Compare quality, speed and cost side by side.

Week 4 — Decide and document. Choose the path that wins on your own numbers. Write down what you chose, why, and who owns it. Then put a review date in the calendar for ninety days' time.

That single review date prevents the most expensive failure mode of all: a system nobody is watching, quietly producing work nobody trusts.

Choosing the right AI solution is not a technology decision. It is a decision about your workflow, your risk appetite and your capacity to maintain what you build.

Start narrow. Pick one task, measure it honestly, and try both a cloud API and a local model on your own data. You will learn more in a fortnight of testing than in months of comparison shopping — and you will end up with a solution that fits your business rather than the one that happened to have the best marketing.

If you would like to build these skills properly — understanding where AI fits, evaluating options, and implementing them without overcommitting — CBS runs practical, hands-on training for working professionals and teams.

Published by CBS (Centre for Behavioural Science) — Singapore's provider of practical corporate training. Learn hands-on with experts and build skills you can use from day one.

CBS — Centre for Behavioural Science

+65 6278 9785 · +65 9767 9686

enquiry@cbs.com.sg

111 North Bridge Road #23-04, Singapore 179098