You don't need a written brief, and you don't need the data ready. Describe the one thing you most want automated — who does it today, what the daily volume is, which systems the data sits in — and one meeting is usually enough for a feasibility call, a rough size for the work, and a clear first step.
Fill this in and we'll put a solutions architect and a delivery engineer on a 60-minute call with you. We draw the data flow and the permission boundary together, and afterwards you get written notes: whether it is feasible, which use case to start with, a rough size for the work, and what we would need from your side.
If you would rather skip the form, just write to us. Pre-sales, technical support and commercial matters all share one address, and we route it internally to whoever should answer.
Solution discussions, architecture review bookings, incidents and upgrades on systems already live, channel partnerships and tender enquiries — all to this address.
DETAILS
Bring context, save a round trip
For pre-sales, include the use case and a list of the systems involved and we can match you to the right architect faster. For incidents, send the environment, the timestamp and a request ID we can trace; customers under contract are answered at their SLA tier.
HOURS
Weekdays 9:00–18:00 SGT
Outside those hours, put “Urgent” in the subject line — it raises an alert with the on-call engineer. Customers on the Flagship tier are covered 7×24.
Not every company arrives having already worked it out. These three entry points match three different states, and each one is a first read given within one or two meetings — no fee, and no need for you to produce a proposal first. A full use-case review that involves interviewing several departments and writing a formal report is paid consulting; see Services.
For when the use case is settled and the open question is how to build it. We go through the data flow, the permission boundary, model selection and acceptance criteria in one sitting, and you leave with notes you can take into an internal approval.
For when you have five or six candidates and no way to decide which goes first. We score them on value, data availability and how hard acceptance will be, starting by cutting the ones you should not build.
For when you already have an agent or a knowledge base but cannot connect it to your business systems. We look at the interfaces, the permission model and the state of the data, then say how much rework it takes and where the risk sits.
Day-to-day engineering and delivery run remotely; we put people on site for the stages that need it. Email us before visiting and we will confirm the floor and building access.
SINGAPORE
Singapore
Registered office and place of business. Platform engineering, model engineering, security and compliance, and the delivery team all sit here; on cross-timezone projects we set the meeting window by the customer's clock.
Delivery runs on your working hours: one fixed demo a week, meeting notes and the board updated the same day, code walkthroughs and reviews kept in the shared repository — so progress is visible without waiting for the next call.
Within four working hours. Enquiries sent in the evening or over the weekend are usually picked up the next working morning. The reply comes with two or three meeting slots, so there is no back and forth about times.
If your description covers the use case and the systems involved, that first reply normally comes from the architect who would own the work, rather than being passed along.
We can sign one first. We accept your template or can supply ours; it usually takes a working day or two and does not hold up scheduling.
For the review stage we only need redacted samples and interface documentation — we do not ask for access to production data. Real data comes in at the pilot stage, and the scope of data handling is agreed separately at that point.
We would recommend it. The standard rhythm is a 4–6 week pilot: build one or two use cases to a working version while building an eval set from your real business samples, and only carry on once it clears the acceptance line agreed up front.
The pilot scope and the acceptance criteria go into writing straight after the review meeting. If it does not pass, it stops there — which keeps budget away from assumptions nobody has tested.
Yes, in phases. We send engineers on site for data integration, security review and canary release; routine development and integration testing stay remote, which keeps the cost predictable.
The team is in Singapore, so on-site work abroad is scheduled around travel and visas and normally needs two to three weeks of notice. Longer full-time placement is possible too, priced per person-month, with staffing and replacement terms written into the contract.
We break the estimate into four parts: how many use cases and how complex they are, how many systems have to be connected, the deployment shape (public cloud, private cloud or a domestically-controlled environment), and the service level after launch. Any one of those moves the workload a long way, which is why we do not quote a flat price.
After the review meeting we give banded ranges, plus a fixed price for the first phase — usually the pilot. Later phases are priced once the pilot passes acceptance, and you can stop at the end of any phase.
The use case that finally ships is often not the one raised in the first meeting. That is fine — describe where things stand and we will work out together what is actually worth doing. This step costs nothing and commits you to nothing.