We have two engineers and no time. Does this create work for them?

Identify creates almost none, beyond a few hours of access setup and one session each. Build does create work, because your engineers review the pull requests and inherit the code, and a build they have not reviewed is one they will not maintain. We would rather that cost be visible up front than discovered at handover.

Can you work with our existing stack rather than introducing new tools?

That is the default. Nearly every build goes into what is already running. Where a new dependency is genuinely needed, the Identify document names it and prices it, so the decision is yours before anything is installed.

How do you handle model costs at our scale?

Token cost is part of the cost model in Identify, projected against your actual traffic rather than against a demo. It is often the finding that kills a candidate: a feature that would work beautifully and cost more per user than the user pays you. Naming that early is cheaper than discovering it in month three.

What if we raise mid-engagement and the priorities change?

It happens. Identify has a fixed end date and a written output, so the worst case is you have a document and a changed plan. Builds are scoped per project rather than as a retainer, for the same reason.

Do you take equity instead of fees?

No. A firm whose income depends on your valuation is a firm with a reason to tell you your AI idea is good.

Startups

Your investors want to hear about AI. Your users want the product to work. Those are not the same brief.

For pre-launch to Series B teams that want AI inside the product without hiring an AI team to find out whether it belongs there.

Work delivered for

Singapore Government project

$100Mroughly in annual operational value at DHL scale, from the programme AISynq contributed to. A figure that size is never one person’s work.Read the DHL case study

The problem

The pressure arrives from two directions at once. On one side, a board that has read the same three articles everyone else has read and wants to know what your AI story is before the next round. On the other, a roadmap already full of things customers have asked for by name.

So the compromise gets built. A feature that is genuinely AI, genuinely shipped, and genuinely used by nobody, because it answered the board question rather than a customer one. Six months later it is still in the codebase, still costing money in tokens, and quietly excluded from the demo.

The version of this that hurts more is the one where the AI feature is the right idea and the build is wrong. An agent that works in ten manual tests and falls over on the eleventh real user. A retrieval layer that returns confident nonsense on the queries that matter most. Both are recoverable, and both are considerably cheaper to avoid than to fix after launch.

This is for you if

You have a product in market or close to it, and real users whose behaviour you can measure.
You have engineers who can maintain what gets built, because they will own it after we leave.
You are willing to have the conversation where the answer is that the AI feature you already told the board about is not the one worth building.
You can name a number that would move if this worked: activation, retention, support cost, time to first value.

This is not for you if

You are pre-product and looking for someone to build the whole thing. We are not an outsourced engineering team.
The AI feature is a fundraising asset rather than a product decision, and it needs to exist regardless of whether it is used.
You need it live in three weeks because the demo is booked. We will look, but the honest answer is usually to move the demo.
Nobody on the team can give an engineer access to production data in any form. The build stalls there every time.

The method

The method, in your situation

01IdentifyA week inside your product analytics and your support queue, plus sessions with whoever handles customer conversations. The output is the short list of places where a model earns its keep, ranked by how measurable the result would be, and the longer list of ideas that would demo well and change nothing.
02BuildOne feature, into your repository, under your review process, with evaluation attached. For a startup this usually means a held-out set of real user inputs and a measured pass rate, so you can tell your board a number rather than an anecdote. The failure path gets designed with the same care as the happy path, because your users find it faster than your QA does.
03ProveThe metric was agreed before the build and the baseline was taken before the first commit. We read it again once the feature has been live long enough for the numbers to mean something, and the note says plainly whether it moved. A startup that can show its AI feature changed activation by a measured amount is in a different fundraising conversation from one that can show a screenshot.

What you get

What you end up holding

Artefacts rather than activities. Each of these is a thing that exists after we leave.

The opportunity note
12 to 20 pages naming what is worth building and what is not, with the baseline number for each candidate and the cost model behind it. Written so your CTO and your CFO can both argue with it.
The feature, in your repository
Running in your environment, under your review process, in your deployment pipeline. Nothing lives in an AISynq account.
An evaluation set
Real inputs with expected outputs, and a script that runs them. This is the artefact teams underrate most, because it is what lets your engineers change the prompt six months later without guessing.
The result note
Two to four pages you can put in a board update without editing. It says what moved and, where nothing moved, what we got wrong.

Getting started

How engagements start

01A 30-minute call where you describe the product and the pressure, and we say whether Identify would tell you anything you do not already know. About a third of these calls end with us saying no.
02A fixed-fee Identify engagement, two to three weeks, with a fixed end date and a written output. You owe nothing further after it.
03If a build follows, it gets scoped against one named opportunity with a firm number before anyone commits.

One limit worth stating

We are a poor fit for the earliest stage. If you have no users yet, there is no behaviour to read and no baseline to take, which removes both the Identify input and the Prove output. What is left is an opinion about your product, and your investors will give you one of those for free. Come back when there are people using the thing.

FAQ

Questions from people in your position

Next step

If you can name the number that would move and you are not sure which build would move it, that is exactly the conversation.

Book the call

A 30-minute call. About a third of them end in a no.