Question categories
6 questions
Working with us
- How does an engagement usually start?
- With a short conversation to understand the problem, followed in most cases by a fixed-fee discovery sprint of one to two weeks. Discovery produces a defined problem statement, a recommended approach and a costed plan, and you keep those outputs whether or not we go on to build anything. Starting small is deliberate: it lets both sides find out whether the working relationship fits before a significant commitment.
- What size of organisation do you work with?
- From small businesses without an internal IT function through to enterprises and public sector bodies with established architecture and security governance. The work differs considerably: a small business usually needs one process solved simply and affordably, while a large organisation more often needs a specialist team that can deliver inside existing constraints and produce the artefacts their governance requires.
- Can you work alongside our existing suppliers?
- Yes, and it is a common arrangement. What matters is that interface and ownership boundaries are documented rather than assumed, so it is clear who is accountable for what when something goes wrong. We will raise it explicitly at the start if those boundaries look ambiguous.
- Do you take over systems built by someone else?
- Yes, after a handover assessment. We review the code, tests, documentation, infrastructure and dependency currency, and report honestly on what condition the system is in and what it would cost to support. Occasionally that assessment concludes that supporting the current system is a poor investment, and we say so.
- How do you handle changes to scope?
- Changes are priced and approved in writing before they are built. We do not absorb scope changes quietly and then report a slipped date, because that removes your ability to decide whether the change is worth its cost. The change log forms part of the project record.
- Who owns the code and the intellectual property?
- You do. Source code, infrastructure definitions and documentation live in your repository from the first commit, and there is no vendor-held artefact you would need to request from us. Handover documentation is kept current throughout, so moving the work to your team or another supplier is possible at any point.
6 questions
Agentic AI
- How is an AI agent different from a chatbot?
- A chatbot answers a question with text. An agent pursues a goal across several steps: it plans an approach, retrieves what it needs from your systems, takes the actions it has been permitted to take, checks its own work, and stops for a human decision at defined points. The commercially significant difference is that an agent can complete work, where a chatbot can only describe it.
- How do you stop an AI system from making things up?
- Three mechanisms together. Answers are grounded in retrieved source material rather than model training data, and cite the document they came from so a person can verify. The system is built to refuse when the evidence does not support an answer, and that refusal behaviour is explicitly tested. And a maintained evaluation set measures accuracy and citation correctness on every change, so a regression is visible rather than discovered by a user.
- What decisions does a person still make?
- Every action with financial, legal, contractual or personal consequence requires a named human approval before it executes. Which actions qualify is agreed with you during design and enforced in the orchestration layer rather than left to the model. Defined sensitive categories always escalate to a person regardless of how confident the system is.
- Will our data be used to train an AI model?
- No. Client data is not used to train external models. Where a model provider's retention and processing terms bear on your obligations, we establish that during design and record it as an architecture decision, including whether a self-hosted model is required.
- What is prompt injection, and how do you handle it?
- Prompt injection is an attempt to smuggle instructions into content an AI system reads — a document, an email, a web page — hoping the system will obey them. We treat all ingested content as untrusted input, keep content separate from instructions, and scope tool permissions so that even a successful injection is bounded by what the agent was ever allowed to do.
- How do we know whether an AI project is worth doing?
- By assessing volume, repeatability, how verifiable the output is, and what an error would cost. Good early candidates are high-volume, repetitive, and produce output a person can check quickly. Where a material uncertainty remains, a bounded proof of concept with a pass threshold agreed in advance answers it before a larger commitment — and if the threshold is not met, we say so and stop.
6 questions
Trust and evidence
- You are a new company. Why should we trust you?
- Not on track record, because we do not have a long one and will not imply otherwise. What we offer instead is a published delivery method covering all nine phases and what you receive from each, solution patterns written out in full — the challenge, the approach, the technologies and the controls — and a first commitment small enough that finding out is inexpensive. If a supplier's experience is the deciding factor for your procurement, we would rather tell you that early than waste your time.
- Why are there no client logos or testimonials on this site?
- Because we have none to publish yet. When we do, they will appear with the client's written agreement and describe the engagement accurately, including what did not go to plan. Fabricated or borrowed credibility is the easiest thing on a website to check, and the most damaging thing to be caught doing.
- Are the solutions on this site real client projects?
- No, and each one is labelled to make that unambiguous. Every entry is an illustrative solution pattern: a design we would build, described in full — the challenge, the approach, the technologies and the controls — with expected outcomes stated as design intent rather than measured results. None of them describes work commissioned by, or delivered to, a client.
- Do you hold security or quality certifications?
- Not currently. We describe how we work towards recognised control objectives — threat modelling, least privilege, managed secrets, automated pipeline scanning, tested backups — and we do not claim a certification we do not hold. If certification is a procurement requirement, we will tell you before you invest time in a submission.
- What happens if a project goes wrong?
- You hear about it early, while there are still options. Progress is reported as working software you can use rather than as percentage complete, which makes problems visible sooner. Each increment leaves a working system with a tested rollback, so a failure is contained rather than accumulating towards a single cutover event.
- Can you meet public sector accessibility requirements?
- Accessibility is treated as an acceptance criterion. We target WCAG 2.2 AA, run automated accessibility testing against every page in the pipeline, back it with keyboard and screen-reader review, and produce a conformance review with remediation notes as a deliverable. This website is built to the same standard.
6 questions
Commercial and delivery
- How do you price work?
- Discovery and proof of concept are fixed fee, so your first commitment is bounded and predictable. Build work is usually fixed-scope against agreed acceptance criteria with milestone billing, or dedicated monthly capacity where scope evolves faster than it can be specified. Support is a recurring fee against agreed response targets. Estimates state their assumptions, so a changed number always has a stated cause — and indicative ranges for every engagement model are published on our services page.
- What does a typical project cost?
- Indicative ranges are published on our services page rather than withheld. A fixed-fee discovery sprint is S$8,000 to S$18,000; a proof of concept S$25,000 to S$60,000; and most first production builds fall between S$80,000 and S$250,000, with support from S$2,500 a month. Those are ranges, not quotations — the firm number comes out of discovery, and discovery's own price is agreed before it starts.
- How long does delivery take?
- Discovery is typically one to two weeks and a proof of concept three to six. Build duration depends on scope, but work is structured so something usable is deployed within the first few iterations rather than at the end. If a proposed timeline looks unrealistic to us, we will say so before it is agreed rather than after it slips.
- Do you offer ongoing support after launch?
- Yes, and we prefer to. Support covers monitoring, patching, dependency currency, backup verification, capacity review and incident handling under response targets agreed in writing. AI components stay under continuing evaluation, because model behaviour and input patterns both drift over time.
- What if we want to bring the work in-house later?
- That is a supported outcome, not a problem. Everything is in your repository throughout, handover documentation is kept current, and we will run a structured transition including a knowledge-transfer period. A client who cannot leave is a client who is not being served well.
- Which technologies do you work with?
- Primarily TypeScript, React and Next.js on the front end, Node.js and Python services, PostgreSQL, and the major cloud platforms, with Claude and comparable models for AI capability. Where your organisation has a standardised technology set, we work within it or make a documented case for an exception rather than quietly introducing something new.
Question not answered here?
Ask it directly. If the answer would be useful to other people we will add it to this page — including if the honest answer is unflattering.
We reply to every enquiry within one business day.