What a Fixed-Price Proof of Concept Includes

"Proof of concept" gets used loosely. Sometimes it means a slide deck. Sometimes it means a throwaway demo that falls apart when anyone touches it. Done well, it is something more useful: a working piece of your actual project, built to answer the question that worries you most. This post explains what a fixed-price proof of concept should include, and what to ask any vendor who offers one.

What a proof of concept is for

A proof of concept exists to reduce risk before you commit to the whole project. Every software project has a part that is either the hardest, the most uncertain, or the most important. It might be a tricky integration, a workflow your team depends on, or the screen your customers will use most. The proof of concept builds that part for real, so you can use it and decide with evidence instead of promises.

That is why we offer it as the front door to our work. Our proof of concept is fixed price: we agree on what it has to do, and we price that.

What it should include

A clear statement of the question

Before anything is built, the vendor should write down what the proof of concept must show. For example: "A staff member can enter a job from a phone and the office sees it immediately." If nobody can state the question in a sentence or two, the work will drift.

Working software, not a mockup

Designs and clickable prototypes have their place, but a proof of concept should run. You should be able to log in, do the thing, and see the result. Real behavior exposes problems that pictures hide.

Real conditions where it matters

If the risky part is an integration with your existing system, the proof of concept should connect to that system, or a realistic stand-in. If it is a workflow, it should be tried by someone who actually does that job. A demo that works only on perfect data tells you little.

An honest list of what is left

A good proof of concept ends with a plain account of what it did not cover, what the full project would involve, and what remains uncertain. This is where you learn whether to proceed, change direction, or stop. Stopping is a legitimate outcome. Learning that an idea does not work, cheaply, is a result.

A path forward

You should leave with options. That might be a fixed-price build, a dedicated team for ongoing work, or a Managed App if one fits. We describe how each works on the pricing and engagement page.

What a fixed price means

Fixed price means the scope and the cost are agreed before work starts, and the cost does not grow because the work took longer than someone guessed. It only works when the scope is clear, which is one more reason the written question matters. If the scope changes, the price and the scope are renegotiated openly rather than drifting upward in the background.

We are deliberately not quoting numbers for a typical proof of concept here, because the right size depends on what you are trying to prove. A conversation about your project is the way to get a real figure.

What to ask any vendor

• What exact question will this answer for us?
• Will we be able to use the working software ourselves?
• What is in the fixed price, and what would change it?
• Who owns what is built, and what carries forward if we continue?
• What will you tell us at the end if the idea is not working?

On ownership, ask before you sign. If you build with us, the client owns it. Managed Apps work differently, with Fluxweave owning the software and you owning your data, customer relationships, and brand. The pricing page sets out the difference.

What a proof of concept is not

It is not a finished product, and it should not be sold as one. It does not cover every edge case, every screen, or every integration. It is also not a free sample or a sales demo. It is real engineering work on a limited slice, which is why it has a price.

It also should not lock you in. The point is to give you information. If you decide to continue, the work can carry forward into the full project. If you decide to stop, you have spent a bounded amount to learn what you needed to know.

Who should be involved

Bring the person who owns the problem, and ideally someone who does the work day to day. The proof of concept is only as useful as the judgment applied to it, and the people who will live with the result are the best judges. Set aside time to try it and give honest feedback. A proof of concept nobody uses teaches nothing.

Signs you are ready for one

You do not need a finished spec. You need a problem that is real, a person who can speak for the business, and one part of the work that you cannot judge from a document. If that describes you, a proof of concept is a sensible first step. If you are earlier than that, our free guide covers your options and what they cost.