Prototyping and proof-of-concept
You own every line of the prototype from day one
Before anything is built we agree three things in writing and date them: the question this answers, what is deliberately absent, and what happens to the artifact when the answer arrives.
Send the one thing you need to know before you commit the real money.
Tell us the question you need answered
A reply within one business day, with a technical person on the call. No deck, no discovery fee.
The same worry, pointing two ways
If you are the one signing, you are afraid the code gets deleted and re-bought.
well it works, why rewrite it? you can just fix bugs if they come up
In my experience it's very rare that the prototype actually gets thrown away and rewritten 'the right way'. And if and when it does happen, it happens years after the prototype has been running in production and there's a big scramble to rewrite it
The executives would be angry because they saw it 'work' with their own eyes and thought the deployment team was just complicating things.
What you keep, in order of worth
1
The decided question
A written yes, no, or not this way, judged against pass and fail criteria you agreed before anything was built. The answer cannot be argued backwards from the demo.
- Why 2 waits for 1The evidence is worth having because there is a written question for it to answer.
2
The evidence behind it
Recordings of the sessions, taken with consent from everyone in it, the numbers that came out, and our notes on what surprised us.
- Why 3 waits for 2What was ruled out is a shorter list than what was watched, and the watching is what ruled it out.
3
The options ruled out
The approaches we tried and stopped, and why. Without this, somebody funds the same dead end again next quarter and nobody remembers it was already tested.
- Why 4 waits for 3The code sits under all three because it is the part you can build again.
4
The code itself
Yours from day one, in your repositories, deployed into your accounts. It is real, it runs, and it is also the cheapest thing you leave with.
The code sits at the bottom of this list on purpose. Ranking it last states what you are paying for rather than excusing weak code.
The IEEE Computer Society's SWEBOK Guide, version 4.0a, the software engineering body of knowledge, puts it plainly. A prototype typically does not become the final software product without extensive rework or refactoring. It is a consensus guide rather than a rule anyone is audited against, and it does not say what should happen at that boundary. Neither does any other standard we could find, so we write ours down and put a date on it. The evidence you keep is what you put in front of whoever was not in the room.
Show data table
| Item | Percent of self-admitted technical debt still present when the study closed |
|---|---|
| Camel | 9.4% |
| Log4j | 12.6% |
| Gerrit | 23.3% |
| Tomcat | 23.4% |
| Apache Hadoop | 59.5% |
Five projects disagree by about six times on whether code its authors marked as debt ever leaves.
The mechanism underneath those bars matters more than the bars. When that debt did get removed, only 8 percent of removals were recorded in a commit message, the note saved with a change. Between a fifth and a half of the time, the code left by accident. It went out with a class somebody deleted for another reason. Almost nobody schedules the cleanup, and afterwards there is no record either way. A software engineer on Hacker News wrote: “The Pragmatic Programmer says to throw away prototypes, but in practice it always seems easier to click the merge button than to rewrite working code.” That is not a character flaw, and meaning it more sincerely does not fix it. Writing the decision down fixes it, with a date on it, before anyone has working code to look at.
What we commit to in writing
You pay once for a prototype, then again for the real product.
What we commit to
From day one every line of code is your IP. It lives in your repositories and it deploys into your accounts. There is no second purchase of a thing you have owned since the first day.
You find out what the demo hid after the handover.
What we commit to
The boundary document names what is deliberately absent, and you see that list before work starts. A team that inherited another team demo said publicly what nobody had told them was missing: security hardening, input validation, error handling.
Nobody ever writes down what happens to the artifact.
What we commit to
The disposal decision is written and dated before the first line is written. Kept, rebuilt, or deleted, on a named trigger. Agreed by both of us while nobody is yet attached to working code.
Scope moves and the number moves quietly with it.
What we commit to
Anything that changes scope goes through a change note that is written and dated, with the effect on the number stated at the time. The number does not move without one.
You cannot reach a technical person until after you commit.
What we commit to
A reply to a new inquiry within one business day, with a technical person on the call. Not a salesperson taking notes to relay, and no discovery fee to find out whether we are the right call.
Whoever inherits this gets no documentation with it.
What we commit to
Every project starts with documentation and offboarding. Architecture, deployment, CI/CD, the release pipeline, the requirements and specification documents, and the change notes. It starts with them rather than ending with them, because documentation written at the end is written under pressure.
Two of those name what will not be in what you get, rather than a feature. One of them is checkable before you spend anything. Send us the question you want answered. See whether the reply arrives inside one business day, with a technical person on it.
Test that commitment before you spend anything
How a prototype project runs
01
Agree the question
We write down the one thing this work exists to decide. We write the pass and fail criteria beside it.
What you get
The written question, with its pass and fail criteria, agreed before anything is built.
02
Draw the boundary
We name what is in, what is deliberately absent, who owns the code, and what happens to it when the answer arrives.
What you get
The boundary document, dated and signed by both of us before any work starts.
03
Build the flow
We build the smallest thing that can answer the question, in your repository, deployed into your account.
What you get
The running thing, and the repository it lives in, both yours from day one.
04
Watch real people
Someone outside the room uses it, and we watch what they do rather than ask what they think.
What you get
The session recordings, taken with consent from everyone in the session, plus notes on where people stopped.
05
Record changes
If scope changes, it changes on paper first, with the effect on the number stated at the time.
What you get
A change note for every change, with its effect on the number stated at the time.
06
Answer and handover
We give the written answer against the criteria from the first stage. Then we hand over properly rather than going quiet.
What you get
The written go or no-go against the criteria, plus the documentation and offboarding pack.
You can see the tools and platforms we build on before you send us anything.
What happened to ideas believed in enough to ship
Controlled experiments on Microsoft's Experimentation Platform: ideas a team believed in enough to build and ship, then A and B tested against the live product.
About a third made no measurable difference
About a third improved the number
These are Microsoft's own round approximations, on its own accounting scheme. No sample size is published, and the three shares are stated as thirds rather than counted. Ron Kohavi, Online Experimentation at Microsoft, Microsoft ThinkWeek paper, 2009, sections 4 and 5.1. Restated unchanged in Kohavi et al., KDD 2013, and Fabijan et al., SEAA 2017. Read what that actually measures. Those are changes A and B tested against a product that was already live, with real customers on it. They are not new concepts checked with users before anyone funded a build. What transfers to your situation is narrower and more useful. It is an observed rate, on one company's own accounting, for how often experienced people are wrong. These were ideas they were sure enough about to ship. The same team reports the rate improving with maturity. It runs at about a third across the company. Inside Bing, which they also ran, it is 10 to 20 percent. That is one company measuring itself, so it is worth what it is and no more. Spending a small amount to find out which third you are in is not a delay before the build.
Show data table
| Stage | Tester-hours to investigate and fix one defect introduced in requirements |
|---|---|
| Requirements | 2 |
| Coding and unit test | 4 |
| Integration | 6 |
| Beta | 8 |
| Post-release | 10 |
Across the five stages that were measured, the rise is a straight line and it stops at five times.
You have probably seen the 100x cost-of-change chart. It has no study under it. The 1 to 6 to 15 to 100 series traces back to 1981 internal IBM course notes. Nobody measured that curve, so we will not draw it. There is a second version, the 1 to 5 to 10 to 15 to 30 series, usually credited to NIST. It is in that report, in Table 5-1, and the report itself heads that table Example Only, in those words. In 2017 Menzies, Nichols, Shull and Layman went looking for the effect in 171 projects. They used measured time logs from the SEI TSP repository. They found no statistically significant difference across phases. We would sell more with the big number. It is not ours to use.
Prototype, proof of concept, discovery or MVP
The proof neededThe doubt
It has to be touched, and the doubt is technical
- A prototype. One flow, built properly enough to be used by someone outside the room, aimed at a single question. This is the work described here.
A written answer settles it, and the doubt is technical
- Discovery. Sometimes what you need is whether it can be built, roughly what it costs and what it depends on. A document answers that faster and cheaper than code. That is a discovery engagement to decide what to build.
It has to be touched, and the doubt is whether anyone will use it
- An MVP. Real users, real money and a real support load, surviving contact for months rather than for an afternoon. That is moving into MVP development once the interaction is proven.
A written answer settles it, and the doubt is whether anyone will use it
- Neither, and you should keep your money. Sometimes the risk is commercial rather than something people have to touch. Nothing you build answers that faster than talking to the people who would pay.
One corner is what we do here, two send you to a different piece of work, and one sends you away from building anything at all. If you already have a prototype, none of the four is your situation: that is the full software engineering engagement that follows.
The three shapes, and what moves the number
One question
Scoped to one written question
Scope and criteria agreed before work starts
What it includes
- The written question with its criteria, a boundary document, the work that tests it, and the recorded answer.
- Nothing is deployed for anyone outside the room. The work here is the test, and the record of what it decided.
What makes it larger A second and a third question, each needing its own criteria and its own test.
One flow, tested
Scoped to one flow and sessions
Scope and criteria agreed before work starts
What it includes
- Everything above, plus a flow built well enough for someone who had no hand in building it.
- We put it in front of them, record the sessions and write up the results.
What makes it larger Recruiting the people who test it, which costs nothing if you have customers or staff to use it.
Continuing into the build
Scoped when the answer arrives
A separate engagement, quoted on its own
What it includes
- A separate engagement, with its own terms, quoted and agreed on its own.
- The boundary makes continuing a decision rather than a default, made with the record and the write-up already in hand.
What makes it larger Working against a system already running in production, which you should tell us in the first email.
Two more things move the amount, whichever shape you are in. How real it has to be for the person who has to be convinced. A board meeting and a regulated pilot are not the same bar. And whether a third-party integration sits inside the boundary or outside it. We are not going to print a range we cannot stand behind for your situation. The published cost bands and the calculator for a custom software build sit with the discovery work. They are planning ranges rather than a quote, and they size a build rather than a prototype. If the amount is your question rather than the scope, start there.
Questions we get before a prototype starts
One of these answers argues against buying a prototype at all.
Will we have to build the whole thing again afterwards?
Plan on it. SWEBOK v4.0a, the consensus guide from the IEEE Computer Society and not a mandate, states that a prototype typically does not become the final software product without extensive rework or refactoring. What survives is the decided question, the evidence recorded behind it, the options you ruled out, and the code, which was yours from day one and which you never buy a second time.
Who owns the code, and when?
You do, from day one. Every line is your IP. It lives in your repositories and it deploys into your accounts. There is no second purchase of something you have owned since the first day.
How do we know what the prototype leaves out?
A boundary document names what is deliberately absent. It is dated and agreed by both sides before any code, so the list of absences reaches you before the work starts rather than after the handover.
What happens to the prototype once we have the answer?
The disposal decision is written and dated before the first line is written. Kept, rebuilt, or deleted, on a named trigger. Both sides agree it while nobody is yet attached to working code.
How much does a prototype cost?
We publish no prototype price, because we have nothing substantiated to publish.
- What a shape is scoped to, and what makes it larger, is agreed and dated before work starts, and any scope change goes through a dated change note, so the number never moves quietly.
- The cost bands and the calculator on the discovery page are planning ranges for a custom software build, not a quote and not prototype pricing.
How quickly will someone reply if we send the question?
Within one business day, with a technical person on the call, not a salesperson taking notes to relay. You can test that on the first business day.
Either we say how we would answer it, what would be left out, and what you own. Or we tell you that a prototype is not what your situation calls for and point you at what is.
Send us the question you need answered
You get one of two answers, and both of them are worth having.
Write down the one thing you need to know before you commit the real money. It does not have to be tidy, and it does not have to be technical. A sentence is enough.
Atyantik TechnologiesA technical person on the call, not a salesperson taking notes to relay.
- A reply within one business day, with a technical person on the call.
- From day one every line of code is your IP, in your repositories, deployed into your accounts.
- If this is not the right work for you, we will say so and name what is.