Technical spike: testing the main project risk in a few days

A client posted a task with a budget that differed from our estimate by more than an order of magnitude. The work was automating bookkeeping routine, six blocks of it, from moving sums between spreadsheets to checking tax calculations before filing. That gap was a deal risk in itself. Every conversation ran into it before we could explain the scope, and it all sounded as though we simply wanted more money. Arguing with that is pointless. We stopped trying.

What solved it was not a discount and not persuasion. We split one frightening decision into two small ones.

What a spike is, and why it is not a prototype

A spike is a small paid step that tests the main technical risk of a project. What it tests is access. Functionality comes later. 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, the result can be exported back. That is all. Nothing else. No interface, no design, no edge cases, because none of that proves anything at this stage while adding noticeably to time and price.

A prototype answers how the product will look. A spike answers a different question: will this work at all? In projects built around somebody else’s accounting system the second question is almost always the expensive one.

Why clients say yes to a small step

A large budget asks a person to make a decision that frightens them. They have to trust an estimate from a vendor they do not know yet. A spike replaces that with something small, and the gap in money stops looking like a trick. The smaller number is the price of the check. The larger one is the full project, and only if the check passes.

There is a second benefit people rarely mention out loud. During those few days the client watches how we work: what questions we ask, how fast we reply, what the write up looks like. Learning that on a small step is cheaper than learning it in month three of a large project.

What the spike closes on the vendor side

The questions it removes in a few days look boring and cost a fortune later. Will the accounting system expose an API, or will data arrive as manual exports? What shape is that data in, and does the product structure match what the manager sees? Does the client have somebody who can physically issue credentials? Is there a legal restriction on moving this data at all? Any of those answers can double the scope, and discovering them after a fixed price contract is signed hurts both sides.

So before a spike we do not name a fixed price with a deadline. Clients like that less than a confident «about a month». Fair enough. That is exactly the point: a confident number given before access is tested rests on luck.

How it is written up on one page

What is included, how many days, the completion criterion, the price. The criterion matters most and has to be verifiable: «an export file for one month in this format has been produced» works, «we have figured out the integration» does not. A feeling of clarity can neither be accepted nor disputed, and arguing about that kind of result damages a relationship faster than a missed deadline. The price sits at the lower bound. Always. A spike is a cheap door into the project (if it costs as much as half the first stage, the door closes). Agree separately on what happens next: the result belongs to the client, and the full estimate is refined from it. Then the step reads as standalone work, and not as a deposit you will never see again.

When a spike is pointless

If 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. If the client has no access to the system everything depends on, a spike cannot help either. Access first. Testing second. Silence in response to that request is normal, by the way. On that bookkeeping project the client went quiet for five days after saying they would review our proposal, and it was not a refusal, they were simply comparing several offers.

The same move inside a project

Spikes are not only a sales instrument. Inside development they are a way to stop arguing about something two days of work can settle. In an education platform the key question was whether a minor’s legal guardian can sign a document through the state electronic signature service and how that works legally. The interface came second. Until the signature is proven, every discussion about screens risks being a discussion about a flow that cannot exist.

What I do not know about this

We have no statistics showing that spikes improve conversion into a contract. The bookkeeping project never reached development, and what would have happened without that step I cannot say.

I know something else.

It removes the argument about price before that argument gets a chance to damage the relationship. If you have a task where neither side can answer a technical question with confidence, write to us and we will propose such a step instead of a blind estimate. And if you have tried a similar format and it failed, tell us where exactly it broke: that experience is almost absent from public writing.