Every engagement runs the same way: a paid two-week kickoff, then a build, then a handoff you own. This page covers what that looks like week to week and what makes a project expensive, because knowing that in advance is more useful than a rate card.
Interviews with the people who actually do the work, a look at the real data behind it, and a written recommendation: what to build first, what to skip, what it costs to run, and what could go wrong. It is paid because it is the work, not a sales call. If the recommendation is that you should not build anything, that is a valid outcome and you still have the document.
The smallest useful version first, in your repository and your cloud, with a working demo at the end of each week. Nothing is saved up for a reveal. If something turns out harder than scoped, you hear it in that week, not at the end.
Documentation, runbooks, and training with the people who will operate it. This is a phase with time allocated to it, not a task that gets cut when the timeline slips. Software nobody else can run is not finished.
Three shapes cover most work. The kickoff decides which one you are in.
One workflow, one integration, or one connector. Typically one to three weeks of build after kickoff. A custom Fivetran connector against a well-documented API sits here.
An agent with tool access and a review queue, or a pipeline feeding modeled dashboards. Usually four to eight weeks, because evaluation and handoff are real work rather than a rounding error.
Several connected systems, or a build that has to land alongside an existing migration. Months rather than weeks, and worth splitting into separately useful pieces so value does not arrive only at the end.
None of this is unusual and all of it is worth knowing before you commit. If several of these apply to your project, it will cost more, and any consultancy telling you otherwise has not looked closely.
Each additional system is its own auth, its own rate limits, its own undocumented behaviour, and its own failure mode. Going from two systems to four more than doubles the work.
The single biggest driver. Duplicate customer records, inconsistent identifiers, and fields used for three different purposes all have to be resolved before anything downstream works. This is usually discovered during kickoff, which is what kickoff is for.
HIPAA, SOC 2, PCI, or contractual data residency change where things can run, what can be logged, what can be retained, and how much of the audit trail is mandatory rather than nice to have.
Cost rises with the number of people who must agree on a definition. Four teams needing to agree what an active customer means is a scheduling problem before it is an engineering one.
A SOAP interface with large payloads and undocumented rate limits takes considerably longer than a clean REST API. We read the docs and make real calls before quoting, precisely because of this.
If three people describe the workflow three ways, that has to be resolved before it can be automated. Building on top of a disputed process just produces disagreement faster.
A single person who can make decisions and grant access removes most of the waiting.
If the process is the same every time, most of the discovery work disappears.
A warehouse, a cloud account, or an Airflow instance already running means no time spent standing one up.
One workflow shipped and measured beats five started. It is also the cheapest way to find out whether the approach fits your business.
Because it produces the thing you need most: a written recommendation based on your real data and your real workflow. Free discovery is a sales activity, and it is optimised for closing rather than for accuracy. Paying for it means the honest answer is available, including the answer that you should not build anything.
Both, depending on how well-defined the work is. After a kickoff, a focused build is usually fixed-scope because the unknowns have been removed, which is most of what a kickoff is for. Open-ended or exploratory work is better on a time basis, because a fixed price for genuine unknowns just means padding.
A sprint fits a defined outcome with an end: a connector, an integration, a first agent. A retainer fits when systems are live and need ongoing change, when a seasonal API shifts behaviour, or when you want senior capacity available without hiring. Most engagements start as a sprint, and some become a retainer afterwards.
You hear about it in the week it becomes apparent, with options: cut scope, extend, or stop. What does not happen is silence followed by an invoice. Weekly working demos exist so that surprises surface while there is still time to decide.
A specific workflow somebody can describe end to end, data that exists somewhere even if it is messy, one person who can make decisions, and a business reason that is not simply that AI is on the roadmap. Those projects tend to go well.
Projects where nobody can describe the current process, where the data has not been collected yet, where the goal is a demo for a board meeting, or where the real problem is organisational rather than technical. Also anything requiring a rewrite of a system nobody wants to touch as a precondition. We would rather say that in week one.
Describe the workflow, the systems involved, and what breaks today.
