Proof of concept
For a part of your system that doesn't exist yet, or exists and can't keep up with the load.
If you haven't picked a direction, I build an initial version of the two or three options worth trying and run them under a load like yours.
If you have, I build the hardest piece first.
Either way you get the numbers, a written recommendation with the reasoning behind it, and working code your team can read before they write the production version. Typically runs for three to four weeks.
For when
Nobody on your team has built anything like it before.
Why build it first
On paper the options usually look about the same. The differences show up under heavy load, and when a server dies or a process restarts with a day of data behind it. By then, the team has often built on one of them already.
An example: One client kept all their data in a single Postgres database, which became a bottleneck. The data split naturally into thousands of sessions that never read each other’s data, so each session could have a database of its own: SQLite on the server’s local NVMe disk, with Litestream streaming every change to S3, so that losing the server didn’t lose the session. The existing streaming tools weren’t good enough for this, so there were two more options: writing straight to S3, or keeping each session’s messages in Kafka and replaying them after a restart. I built an initial version of all three, simulated thousands of sessions writing at once, and measured how each one behaved under that load and after a restart.
How it works
- A written proposal: the question the prototype has to answer, the deliverable, the date and the fixed fee.
- A working session with your team: the current system, and what the new part has to do. That means how fast it must be, how much data you can afford to lose, and what it may cost to run.
- The options, narrowed to the two or three worth building. If you've already chosen the direction, we skip this step.
- I build and measure, with a check-in halfway to show you the first numbers.
- The written recommendation, and a session to walk through it and take questions.
- Questions for two months after delivery.
What you get
- The recommendation first, short enough to read on its own
- The measurements, with the load I simulated and how to rerun them
- The prototype and its test harness, in your repository
- The decisions I made, and the approaches I'd avoid
- What the numbers settle, and what they leave open
Your other options
Your team builds a spike itself
It stays close to the code. It also costs weeks on technology the team doesn't know yet, and the team tends to test the option it already favours.
Choose from documentation and published benchmarks
It's free, but somebody else's benchmark doesn't necessarily match your load.
Build it for real and find out in production
There's no extra step. The cost arrives later, after other teams have built on it.
Questions
Who owns the code?
You do. It lives in your repository.
Will you write the production version?
No. Your team does, since they're the ones who need to maintain it. The prototype is there to show them how.
What if none of the options works for us?
Then you know before building on one, and the write-up says why.
How many hours is that?
I don't scope this in hours. It's a fixed fee for a defined deliverable, so the price doesn't depend on how long it takes me. That's deliberate: if it turns out to be more work than I expect, that's my problem, not yours.
What does it take from my team?
The working session, a sample of your data or something shaped like it, and a few answers along the way.
Will you sign our NDA?
Sure, signing a mutual NDA is part of the package.
What I learned
Want to talk it through?
