How to Build a Proof of Concept for a Software App, Step by Step

Most proofs of concept don't fail because the team couldn't build them. They fail because nobody said what they were supposed to prove.

AWS Prescriptive Guidance describes the usual pattern in one sentence: "Too often, PoCs are treated as technical demos that are designed to impress rather than as rigorous experiments that are designed to promote learning." A demo is built to be liked. An experiment is built so it can fail.

This post is the process I'd follow to build a proof of concept (PoC) for a software app, in seven steps. It works whether the risky part is a new integration, a machine learning model, or a piece of architecture you've never tried.

A note up front: I work at Entalogics, where we build proofs of concept and prototypes for startups. I'll say where our own process fits, and where it doesn't.

What a proof of concept is (and isn't)

A proof of concept answers one question: can this specific risky thing be built and made to work in our environment? It isn't a product, it isn't a demo for investors, and it isn't a first release.

If you want the full split between a proof of concept, a prototype and a minimum viable product (MVP), I wrote that up in a separate post. The short version: a proof of concept tests whether it can be built, a prototype tests whether people understand it, and an MVP tests whether people will pay for it. This post is only about the first one.

Step 1: Name the riskiest assumption

Don't start by listing features. Start by listing what could make the whole project impossible, then pick the one that scares you most.

Good candidates:

• The model isn't accurate enough on your real data.
• The third-party API can't handle your load or rate limits.
• The integration with the customer's system doesn't work the way the docs say.
• The architecture can't hit the latency you promised .

This is risk-first thinking, and it's old. Barry Boehm's 1988 paper on the spiral model described a "risk-driven approach to the software process rather than a primarily document-driven or code-driven process." The idea hasn't changed: spend your first effort where the biggest unknown is.

Write the assumption as a sentence that can be wrong. "We can extract invoice totals from scanned PDFs with at least 90% accuracy" is a hypothesis. "Explore invoice extraction" is not.

Step 2: Write the success criteria and the exit threshold before you build

This is the step teams skip, and it's the one that makes the rest honest.

Before any code, write down:

The pass condition. A number or a clear yes/no.
The fail condition. The result at which you stop.
The constraints that count. Quality, speed and cost, not just "does it work."

AWS says a PoC "requires translating a high-level business objective to specific, measurable success criteria," and its guidance on exit criteria is worth following: set clear thresholds for quality, latency and cost, and if results don't meet them, pivot or end the PoC so poor performance doesn't lead to wasted effort or sunk costs.

The reason to write this down first is simple. After you've spent a week on something, almost any result starts to look like a success. A threshold you wrote beforehand can't be bent to match what happened.

Step 3: Time-box it

A proof of concept without a deadline turns into a project.

Extreme Programming has a name for this kind of small, bounded experiment: the spike. The XP rules say to create spike solutions "to figure out answers to tough technical or design problems," and to build the spike "to only addresses the problem under examination and ignore all other concerns." (The grammar slip is in the original page, which is by Don Wells.) The same page suggests putting a pair of developers on a threatening problem for "a week or two."

Be careful with that last number. It's XP's rule of thumb for one spike, not a measured benchmark for how long a proof of concept takes. I haven't found a credible published benchmark for PoC duration or cost, so I'd be suspicious of anyone who quotes one. Pick the time-box from your own question: how long are you willing to spend finding out?

Step 4: Build the thinnest slice that touches the risk

Now build, and keep it narrow.

AWS's guidance puts it plainly: for a PoC, start "with the simplest method that can validate the core business value," and validate "only the core components before you invest in full end-to-end integration." In practice that means:

No login screen unless login is the risk.
No polished UI unless the interface is the risk.
Hardcode what doesn't matter. Build what does.
If the risky part is one API call, the whole PoC can be that call plus a way to check the result.

One distinction trips people up here. Some thin-slice techniques, like a walking skeleton or tracer bullets, are meant to be kept and grown into the real system. A proof of concept usually isn't. If you plan to keep the code, you're building something else, and you should say so.

Step 5: Use realistic data, not real customer data

Toy data tells you nothing. If your PoC passes on five clean examples and the real world is messy, you've learned the wrong thing.

AWS makes the point that you need high-quality test data to check outputs against known-good answers. But it also sets a default for privacy: the default approach should be to use synthetic or fully anonymized data. If real data with personal information is necessary, explicit approval from security and legal must come first. In AWS's words, ignoring this step "is one of the most common pitfalls."

So aim for data that's realistic in shape and difficulty (the same ugly formats, the same edge cases) without being real customer records unless someone has signed off.

The same care applies to credentials. GitGuardian's State of Secrets Sprawl 2026 report counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% in a year. (GitGuardian sells secret-detection tools, so weigh the source.) Prototype code is exactly where keys get pasted in "just for now." Use throwaway demo credentials and keep real keys out of the repo. If AI tools are writing part of your PoC, we've covered the security problems that usually follow: invented packages, hardcoded secrets and databases left open.

Step 6: Measure against the threshold and decide

When the time-box ends, run the test you wrote in Step 2. Don't change the threshold now.

AWS describes the end of a PoC as a decision gate: "This is not a moment for intuition—it is a structured evaluation that determines whether to proceed with further investment, pivot the approach, or halt the project." That gives you three honest outcomes:

• Go. The risky thing works within your thresholds, and there's a clear path to a real implementation.
• Pivot. It almost works, or it works a different way than you expected, and you change the approach.
• Stop. It doesn't clear the bar. That's a good result. You spent a week instead of a quarter finding out.

AWS also notes a "go" decision should be backed by evidence, not just enthusiasm. If the only thing supporting a yes is that everyone wants a yes, that's your answer.

Step 7: Write down what you learned, then decide what happens to the code

Whatever the outcome, write a one-page summary: the question, the threshold, the result, and what surprised you. AWS puts it this way: no PoC is perfect, and a core outcome is a list of key learnings. What assumptions were wrong? What new challenges did you find?

Then deal with the code on purpose. My default is that proof of concept code doesn't go to production. Martin Fowler's "Sacrificial Architecture" makes a related point about building something knowing you'll replace it, so that you "don't invest the full effort on a feature that you find isn't worth full deployment." (He's writing about production systems over a couple of years, not PoCs, so take the mindset, not the details.)

AI tools make this more tempting, because the first version appears so fast. The Thoughtworks Technology Radar put "complacency with AI-generated code" on Hold in its April 2025 edition and wrote that while fast, minimal-review generation can be appropriate for things like prototypes or other throw-away code, they "strongly caution against using it for production code." The fix is mostly habit:

Keep the PoC in its own repo, not a branch of the product.
Put "Proof of concept. Not production code." on the first line of the README.
Keep the learnings and the design decisions. Rebuild the code deliberately.
If your proof of concept is an AI feature

A lot of proofs of concept now are AI features, and the failure stats get quoted loosely, so here are the two I'd trust, with what they actually say.

Gartner predicted in a press release dated July 29, 2024 that "at least 30% of generative AI (GenAI) projects will be abandoned after proof of concept by the end of 2025," citing poor data quality, inadequate risk controls, escalating costs or unclear business value. That's a forecast, not a measurement.

S&P Global Market Intelligence measured something: in its October 2025 research, the share of companies abandoning most of their AI initiatives before production rose from 17% to 42%, and the average organization scrapped 46% of its proof-of-concept projects before production. It's survey-based and covers AI initiatives in general, not only generative AI.

Neither number says AI PoCs are doomed. They say the gap between a working demo and a shipped system is wide, and the reasons they list (bad data, weak risk controls, costs, unclear value) are things Steps 1, 2 and 5 are designed to surface early.

For an AI feature, Step 2 has a concrete form: build a labeled test set with answers you trust, pick a pass threshold before you run it, and track cost per request as well as accuracy. AWS's guidance for generative AI proofs of concept calls for exactly this kind of validated reference data and clear thresholds for quality, latency and cost.

Where our own process fits

Our proof of concept development service runs in four stages: a scope call, an AI-augmented build, polish and deploy, and a handoff. It's a fixed-price package, from $999, up to 5 screens, delivered in 72 hours. That timeline is our own offer, not an industry norm.

It maps onto the steps above like this: the scope call is where Steps 1 and 2 happen (what are we proving, and what counts as success), the build is Steps 3 and 4, and the handoff covers Steps 6 and 7.

One honest caveat, using the definitions from my earlier post: what we deliver in 72 hours is a clickable prototype for founders who need to show investors something real. It answers "will people understand this?", not "can the hard technical part be built?" If your riskiest assumption is technical, like model accuracy or an integration, you need the pass/fail test from Steps 2 and 6, and a clickable build won't answer it. Pick the process that matches the risk.

A one-page checklist

Before you start, you should be able to fill in all of these:

• The assumption: what might make this impossible?
• The hypothesis: one sentence that can be proven wrong.
• The pass line and the fail line: numbers, written down.
• The time-box: a date, not "when it's done."
• The data: realistic, and approved to use.
• The decision: go, pivot or stop, and who makes it.
• The code plan: what happens to the repo afterward.

If you can't fill one in, you aren't ready to build. You're ready to talk about it for another hour.

The takeaway

A proof of concept is a small experiment with a clear question and an honest ending. The build is the easy part. The hard parts are naming the risk, writing the threshold before you see the result, and accepting a "stop" when that's what the data says.

Do that, and even a failed proof of concept is a win: you found out cheaply.