# Two-week proof of concept: what to test | ThorOps

Most proofs of concept fail in a quiet way. Two weeks pass, there is a demo, everyone nods, and nobody is sure what was learned. The team keeps building because stopping feels like failure.


A good proof of concept is not a small version of the product. It is an experiment that answers one expensive question before you commit real budget.


## Start with the question, not the feature list


Before any code, write down the one thing that would make you stop the project if the answer were “no”. Usually it is one of these:



- Can it be done? The integration, the data, the performance or the device you depend on actually behaves the way you assume.

- Will people use it? The workflow fits how your team or customers really work, not how a slide says they work.

- Is it worth it? The cost to build and run it is in the range the business case needs.



If you cannot name the question, you are not ready for a proof of concept. You are ready for a discovery session.


## Build the riskiest part first, and only that


Two weeks is enough to answer one hard question well. It is not enough to also build login, settings, admin screens and a polished design. Skip everything that is already a solved problem. Fake it, hard-code it or leave it out.


Spend the time on the part nobody has done before in your context: the legacy system you must read from, the offline sync on a job site, the Arabic search that has to handle different spellings.


## Decide in advance what “yes” looks like


Write the success criteria on day one, with numbers where you can:



- The report generates in under five seconds for a year of data.

- Five people from the real team complete the main task without help.

- The monthly cloud cost for the expected load stays under a set budget.



At the end, the demo is measured against that list, not against how impressive it looks.


## What you should have after two weeks



- A working demo of the risky part, running on real or realistic data.

- A clear answer to the question you started with.

- A short plan for what comes next: build it, change direction, or stop.



Stopping after two weeks is a good outcome. It can save you from a much more expensive mistake.


That is the whole point. You spend a little to avoid spending a lot on the wrong thing.