How we work
Most people writing to us have been through a data project that ran long, cost more than the number on the deck, and ended in a notebook. This page is the process we use so that does not happen again, written so you can hold us to it. Work ranges from a few days to a few months.
The engagement, start to finish
Scoping call
Thirty to forty-five minutes, remote. You describe what is slow, missing or risky. We ask about the systems, the people who use them, and what "done" would look like on a Monday morning. If we are not the right fit, we say so on the call and suggest who might be.
Written fixed quote
Within a few working days you get one document: the scope, what is in, what is explicitly out, the weekly plan, what we need from you, and one number for the whole thing. The number does not move unless the scope does, and a scope change is a new written line, agreed before the work. Nothing starts until you have said yes in writing.
Build in weekly increments
Every week ends with a demo of something running in your environment, not a slide about it. You see the real data, the real report, the real agent, and you can redirect while redirecting is cheap.
Handover
Documentation, a runbook, a walkthrough with your team, and the keys. Your team runs the system; we watch them do it once. Nothing we built depends on us being around to run it.
A month of support after launch
Thirty days of fixes, questions and small adjustments at no extra line, because the first month is when the real edge cases show up.
What the handover contains
The code and the config
In your repository, under your account, with the deployment steps written down and tested by someone other than the person who wrote them.
An architecture note
One page that says what the pieces are, why each one is there, and what would have to change if the data doubled or a source was swapped.
The runbook
For every alert we set up: what it means, what to check first, what to do, and who to call. Written for the person on call at 3 am, not for us.
The rules and their counts
Every data quality rule, what it rejects, and how many rows it rejected in the last run, so the first week after handover has a baseline.
The evals, for anything with a model in it
The written set of cases an assistant or agent was tested against, the results, and the script that runs them again after any change.
A walkthrough
A recorded session with your team going through all of the above, and the questions they asked, answered in writing afterwards.
What we need from you
- One person who can decide
- Someone who can make decisions about scope and answer questions within a day or two. Not full time; available.
- Access, early and read-only
- Access to the systems involved, early, read-only wherever possible, through accounts in your name that you can revoke. The first week of many projects is spent waiting for this.
- The real data, early
- A realistic sample of the data. Not a clean extract; the real thing, with its problems. Synthetic data hides the problems the engagement exists to solve.
- Thirty minutes a week
- For the demo. This is where most of the steering happens, and it is the cheapest half hour in the project.
- What went wrong before
- Honesty about it. It changes what we build first.
Three shapes an engagement takes
Days
A focused fix
One slow report, one failing pipeline, one agent that needs evals and an approval step before it can go live. Scoped on the call, quoted the same week, demonstrated once, handed over with a short note.
Weeks
A system
A data platform for one domain, a semantic model and the reports on it, an agent with its safety and monitoring, or a workflow that replaces a weekly manual job. Weekly demos, a runbook, a month of support.
Months
The whole product
The platform, the reports, the agents and the web app people log into, built in that order, each part handed over as it is finished so the first useful thing is running within weeks, not at the end.
We will tell you which shape your question is on the scoping call. Most are the second one.
Questions people ask before they write
Who owns the code?
You do, from the first commit. It lives in your repository under your account. We keep nothing that you cannot delete.
Where does our data go?
It stays in your cloud accounts. We work inside your Azure, Databricks, Supabase or Vercel, through accounts you create and can revoke. We do not copy data to our own machines unless you ask us to for a specific task, and then we say exactly what and delete it when the task is done.
Where do the prompts go, for AI work?
To the model provider you choose, under your API keys and their retention terms. The handover note records which provider, which region and which retention setting, so the answer is written down rather than remembered.
Do you use AI tools to build?
Yes, for code, tests and documentation, with review of every line and no client data in any tool outside your tenant. The deliverable is judged the same way either way: does it run, is it tested, can your team change it.
Will you sign an NDA?
Yes, before the scoping call if you prefer. Send yours or ask for ours.
Do you work with our existing team?
Yes, and we prefer it. The handover is shorter when the people who will run the system have been in the weekly demos. If you have no data team, we build so that a generalist engineer can run it with the runbook.
How do you price?
A written number after the scoping call, fixed for the scope. No day rates, no estimates that grow. If the scope changes, the change is written down with its own number and agreed before we do it. Work ranges from a few days to a few months, and the shape is clear after the first call.
What time zones do you work in?
We are in Bengaluru, on India Standard Time. For US clients that gives overlap with your mornings on the East Coast and, when needed, your evenings. For clients in India, the whole working day. Demos and calls are scheduled in your time zone. The contact page has the hours.
What if the scope changes halfway through?
It usually does, a little. Small changes are absorbed in the weekly plan. Anything that moves the number is written as a change line with its own cost and its effect on the timeline, and you decide. Nothing is silently added.
Can you take over a system someone else built?
Yes. We start with a short read-only review: what runs, what breaks, what it costs, what is undocumented. You get a written list of what we found before any quote, so you can decide whether to fix, rebuild or leave it alone.
What happens after launch?
Thirty days of support are part of every engagement. After that, you own a documented system and can run it yourself, or we agree a small retained arrangement in writing. It is never assumed, and we do not build dependence on us into the system.
What do you not do?
We do not run offshore teams on your behalf, resell licences, or build a prototype and leave. We do not take work where the data cannot be made trustworthy or the model cannot be made safe within the scope, and we say so on the call.
How do we know the system is actually working after you leave?
Because monitoring is part of the build, not a follow-on. Every system is handed over with alerts that reach a person, a dashboard you can open, and a runbook that was tested by breaking something on purpose.
The scoping call starts with an email.
Three lines are enough: what is slow, missing or risky; what you have now; when you need it.