Technical spike: testing the main project risk in a few days
The situation that produced this practice looked like this. A bookkeeping outsourcing company wanted to automate routine work and posted the task with a budget that differed from our project estimate by more than an order of magnitude. That gap was itself a deal risk: every conversation ran into it before we could explain the scope.
The answer turned out not to be a discount and not persuasion, but splitting one scary decision into two smaller ones.
What a spike is
A spike is a small paid step that tests the main technical risk of the project. Not a feature, access.
The sentence we put into the proposal reads roughly like this: we can connect to the client’s system, data can be read from it, a document can be produced from that data, and the result can be exported back. Nothing else. No interface, no design, no edge cases.
One developer, a few days, working against the client’s real system rather than made up data.
Why clients accept it
A large budget asks a person to make a decision they are not ready to make: to trust an estimate from a vendor they do not know yet. A spike replaces that decision with a small one.
The gap in money then becomes a story that makes sense: the small number is the price of the check, the large number is the full project if the check passes.
There is a second benefit that is easy to miss. During a spike you get to see how the vendor works: what questions they ask, how fast they reply, what their write up looks like. That is far cheaper than learning the same thing in month three.
Why vendors need it
We do not name a fixed price with a deadline before the spike. It sounds less confident than «a month», and that is precisely why it works: before access is tested, the biggest unknown is untouched.
Typical questions a spike closes in days: does the accounting system expose an API or will data come as manual exports, what shape is the data in, does the client have somebody who can actually issue credentials, and is there a legal restriction on moving this data at all.
Any one of those answers can double the project scope. Learning them after signing a fixed price contract is expensive.
How it is written up
A one page proposal: what is included, how many days, the completion criterion, the price.
The completion criterion matters most. It has to be verifiable: «an export file for one month in this format has been produced», not «we have figured out the integration». A feeling of clarity can neither be accepted nor disputed.
Agree separately on what happens next: the result belongs to the client, and the full estimate is refined based on it. Then the step reads as standalone work rather than a deposit.
When a spike is pointless
When the task is routine and both sides know every external system involved, there is nothing to test and the extra stage only stretches the timeline.
When the client has no access to the system everything depends on, a spike cannot start. We once spent two weeks waiting for credentials our contact was never able to issue, and since then that is our first question.
The same idea inside a project
Spikes are not only a sales instrument. Inside a project they are a way to stop arguing about something that can be checked.
We used one to settle how documents would be signed through a government electronic signature service in an education platform. The key question was not the interface but whether a minor’s legal guardian can sign at all and what that looks like legally. Until that is answered, every discussion about screens risks being a discussion about a flow that cannot exist.
The general rule: if a project contains a question neither side can answer with confidence, it is worth a few days of work now and half the budget later.
FAQ
How is a spike different from a prototype
A prototype shows how the product will look and behave for users. A spike answers whether access to the system the product depends on is possible at all. One answers «how», the other answers «will this work».
How much should a spike cost
It is priced at the lower bound, because it is a cheap door into the project rather than a revenue line. A few days of one developer, at a price a cautious client can approve without a long procurement cycle.
What if the spike shows the task cannot be done
That is the best possible outcome for the money. You learned the constraint before committing the full budget, and you either reframe the task or drop it. A negative result is still a result.
Does a spike have to be paid
A free check tends to be done with whatever time is left over and commits neither side. A small payment creates a deadline, an owner and a completion criterion.