Part three
After the build
The three exits, what hosting covers, what you get if you take it in-house, the glossary and the questions procurement asks.
§ 12 Choosing your route
Choosing your route
At the end of the pilot you pick one of two: we host it, or you take it in-house. You are deciding with a working system in front of you, which is the point of the whole arrangement.
Fig. 5 — Two routes, decided with the thing in front of you
- Hosted by us: Monthly fee, we run it.
- Taken in-house: Code and data handed over.
We host it
S$500 a monthWe run the infrastructure, apply updates, keep backups, and stay the accountable party when something breaks. You keep using it and stop thinking about it. Cancellable, with your data exported on the way out.
You take it in-house
No ongoing feeRepository, deployment, infrastructure configuration, documentation and data, handed over on full payment. Your team or another vendor runs it from there.
Note
The election itself, and the fact that nothing continues automatically: Engagement Terms § 05 — Hosting election.
§ 13 If we host it
If we host it
What the monthly fee covers
- Infrastructure, deployment and monitoring, with backups taken and tested.
- Dependency and security updates, applied without you asking.
- A first response to a reported problem within two business days.
- Small adjustments as the work changes: a field, a label, a report column.
- Reporting a problem
- Email us with a screenshot, what you did and when it happened. Say whether the work is blocked. Blocked means we start now.
- Asking for a change
- Describe the outcome you want rather than the screen you imagine. Small changes are part of the monthly fee. Anything that amounts to a new workflow gets quoted before we start, never after.
- Leaving
- Tell us. You get the repository, the configuration and a data export, and we stay available while you move. No exit fee and no retention conversation.
Response targets, priorities and service credits: Engagement Terms § 06 — Hosted service and support.
§ 14 If you take it in-house
If you take it in-house
Procurement teams are right to worry about dependence, and with modern systems the trap is rarely source code. It is the deployment setup, the data format, and the undocumented knowledge sitting in one supplier's head. On full payment you get all three, plus your data in an exportable format. Move it in-house or to another vendor whenever you like.
§ 15 Either way: tell someone
Either way: tell someone
We do not advertise and we do not have a sales team. Most of our work arrives because somebody described us to a colleague. If the pilot worked, that is the thing we would ask for.
Who we are useful to
- Teams with one workflow that eats a day a week
- Managers who have been quoted six figures for something bounded
- People who tried an off-the-shelf tool and now maintain a spreadsheet beside it
- Anyone who has been told to wait for the next budget cycle
What a useful introduction contains
- An introduction email with one sentence on what we built for you and how long it took.
- The number that changed, if you are allowed to share it.
- The honest caveat as well. If a part of it was painful, say that too. It saves everyone time.
Note
§ 16 Fast lane, governed lane
Fast lane, governed lane
Fast lane
Where we fitInternal tools, workflow experiments, reporting interfaces, process digitisation, reversible improvements. Small blast radius, quick feedback, real value within weeks.
Governed lane
Same loop, slowerPersonal data at scale, financial transactions, critical public-facing services, complex enterprise integration. We still build in increments, but assurance, review and accreditation set the pace. Sometimes a large systems integrator is the right answer, and we will say so.
§ 17 For Singapore public-sector readers
For Singapore public-sector readers
If pilot-then-scale sounds like it would never clear procurement: a bounded build often sits inside the Small Value Purchase band, and hosting is a separate requirement decided later rather than part of the same purchase. The companion guide sets out the tiers, what counts as splitting, and what evidence of severability looks like on a file.
§ 18 Glossary
Glossary
Plain-language definitions for the words that get used loosely in software meetings. The AI entry carries the pros, the cons, and the test for when the extra complexity earns its place.
AI in a system
A language model doing one named job inside a workflow, not a chatbot bolted onto the side.
It means a step in your process hands its input to a model and uses what comes back. Reading an email and suggesting a category. Drafting a reply for someone to edit. Pulling four fields out of a scanned form.
The rest of the software stays ordinary: a database, permissions, a screen, an audit trail. The model is one component with a defined input, a defined output, and somewhere the result gets checked.
Pros
- Handles free text and messy input without you listing every case first
- Drafts, so a person edits rather than starting from blank
- Absorbs new phrasing without a code change
Cons
- Wrong sometimes, and confidently so — there is no error message
- Same input can give a different answer tomorrow, which makes testing harder
- Needs a review step, and that step costs somebody time
- Priced per use, so heavy use scales the bill
When the extra complexity is warranted
When the input is genuinely unstructured, volume is high enough that a person is the bottleneck, a human sits close enough to catch errors, and the value still stands after the review time is subtracted. If the rules can be written down, write them down instead.
Language model
Software that predicts likely text from the text you give it. Fluent, useful, and never a source of truth.
It produces plausible continuations of text. Plausible and correct overlap most of the time, which is exactly what makes the misses hard to spot.
Treat its output as a draft from a fast, well-read colleague who never says they are unsure.
Human in the loop
A named person approves the output before it has any effect.
The model proposes, the person releases. It removes most of the risk of a wrong answer and keeps a human accountable for the decision.
The trade is time. If reviewing takes as long as doing the task, the model is not earning its place.
Retrieval
Searching your own documents first, then answering from what was found.
Instead of asking a model what it knows, you find the relevant passages in your files and ask it to answer using those, with the sources shown.
This is often the real request behind 'we want AI'. Finding the prior case usually beats generating a new opinion about it.
Hallucination
A confident answer that is simply invented.
A fabricated case number, a policy clause that does not exist, a total that does not add up. It reads exactly like the correct answers.
You reduce it with retrieval, narrow tasks and validation, and you catch the rest with a review step. You do not eliminate it.
Evaluation set
A fixed batch of real examples with agreed correct answers, re-run after every change.
Thirty to a hundred cases your team has already judged. Every time the prompt, the model or the workflow changes, the batch runs again and you compare.
Without one, 'it seems better' is the only quality measure you have.
Baseline
What the work costs today, in a number, before anything is built.
Median minutes per case, cases per day, error rate, backlog size. A week of tally marks is enough.
It is the only way to tell afterwards whether the software helped, and it takes an hour to collect.
Bounded problem
One workflow, one team, a clear start and a clear end.
If describing it needs a diagram with four departments on it, it is not bounded yet. Take a piece of it that one owner can decide about.
Audit trail
A durable record of who did what, when, and what the system did in response.
For a workflow with a model in it, that includes what the model was asked, what it returned, and who accepted it.
This is what makes an AI step defensible at review rather than a black box.
Handover
Repository, deployment, data and documentation transferred so someone else can run it.
Not a zip file and good luck. Enough that a competent stranger, or your future in-house hire, can deploy a change on their own.
§ 19 Questions procurement asks
Questions procurement asks
How long does this take compared with a tender?
The old route spends most of its calendar before anyone touches software. Committee, specification, tender, evaluation, approval: commonly six to twelve months, and the build starts after all of that. We start with a 45-minute conversation and aim to have a working version deployed with your real data inside three weeks. From there it is use-and-change until the thing fits, and a live application at about the three-month mark. The difference is not typing speed. We simply do not spend months describing something nobody has used.
Do we have to run a tender or an RFP for this?
That depends on your own procurement policy and value thresholds, and we will not pretend to rule on it for you. What is worth knowing is that the engagement is small and bounded, which often places the build inside the Small Value Purchase band, and that the build and any later hosting are two separate requirements rather than one. If a quotation or a tender is required anyway, a working pilot makes a better basis for one than a guessed specification.
What is the pilot, and what if it does not work?
The pilot is phases 01 to 03. We agree what better looks like as a number, build the smallest working version, then change it against real use. If the number does not move, you say so and we stop. You keep the repository, the deployment configuration, the documentation and your data. There is no version of this where you walk away with only an invoice.
What does the pilot cost, and what am I committing to?
Phases 01 to 03 are covered by the S$5,999 setup fee per application. The hosted service is S$500 a month and starts only if you elect it after testing. The other route is taking the whole thing in-house. There is no multi-year licence, no seat count and no escalating support contract.
How much of my team's time does this take?
One named owner who can make decisions without convening a committee, and roughly twenty minutes of reaction a week from the people who do the work. We also need an honest description of how the job really happens, including the workarounds, plus real data or a realistic stand-in. That is the whole ask. Silence is the one thing that reliably breaks the fit.
Who owns the code, the data and the deployment?
You do, on full payment: the repository, the deployment, the infrastructure configuration, the documentation, and your data in an exportable format. Lock-in with modern systems is rarely about source code. It is the deployment setup, the data format and the undocumented knowledge sitting in one supplier's head, so we hand over all three. If you move to another vendor or in-house, we help.
Can we start small and scale later?
That is the intended shape. One bounded workflow first, proven in production with real users, then the next one. Additional applications are priced per instance rather than as one large programme, so scaling stays a decision you make repeatedly with evidence.
What if the work is high-risk or regulated?
Then it belongs in the governed lane: personal data at scale, financial transactions, critical public-facing services, complex enterprise integration. We still build in increments, but assurance, review and accreditation set the pace. Sometimes a large systems integrator is the right answer for that work, and we will say so rather than take the engagement.
§ 20 Request a call
Request a call
Forty-five minutes, no slide deck. We work out whether your problem is bounded enough to pilot, what evidence you would need to justify it internally, and roughly what it would cost. If you do not need us, we will say that.