A client came to us with a vague but compelling idea – a new management interface for their online community. No clear requirements, no design specs, just a sense that their old website wasn’t cutting it anymore. By end of day, we’d built a working prototype on Payload CMS, deployed it to a live URL, and the client had something real to react to. The whole thing took one working day.
That’s not a lucky sprint. It’s a repeatable workflow. And in Switzerland, where senior development hours are expensive and stakeholder expectations are high, the economics of validating fast before committing budget are hard to argue with.
The real question isn’t whether your idea is good. It’s whether it works in your environment – and you can find out in a day.
What a proof of concept (PoC) actually is
A proof of concept (PoC) is a minimal, functional build that has one job: answer a single, specific question about technical feasibility. Can this actually work in our environment, with our data, connected to our systems?
The Payload CMS project is a good example. The PoC question wasn’t “will this look great?” It was: “Can we spin up a functional content management interface based on their existing structure, fast enough to show the client something real today?” That’s it.
At what., a successful one-day PoC means the core workflow runs end-to-end, the client can interact with it, and everyone walks away with a clear go/no-go signal. The bar isn’t perfect code or production-grade security. It’s enough signal to know whether the idea deserves more investment.
Why AI makes one day realistic now
Two years ago, a same-day prototype for something like a custom CMS interface would have been unrealistic. You’d spend the morning just discussing requirements, the afternoon fighting boilerplate, and the next three days writing tests and fixing obvious bugs.
AI changes this in a few specific ways. The biggest time save isn’t where most people expect. It’s not the code generation itself – it’s the ability to use an existing website or design system as a direct input. We fed the client’s old site into Claude, used it to scaffold the architecture in Payload CMS, and iterated from there. No starting from a blank file. No guessing at content structure.
The second unlock is that AI lets you skip writing proper tests in the prototype phase without completely flying blind. You’re iterating fast, checking core workflows manually, using AI tools to catch regressions as you go. That’s not how you’d build production software, but for a PoC it’s exactly right.
Worth flagging: many “AI problems” clients bring us turn out to be integration problems once we dig in. A one-day PoC surfaces that distinction quickly. If the prototype breaks because two systems can’t talk to each other, that’s a tools integration issue, not an AI issue – and knowing that on day one saves weeks of misdirected effort.
Also relevant: if your underlying workflows are broken, even a successful PoC won’t fix them. Read our take on fixing workflows before touching AI.
The one-day PoC playbook
Here’s how a typical day actually runs.
Morning: discovery and scoping (1–2 hours)
The most important step, and the one most teams want to skip. Before anything gets built, we sit down with the client and identify the single question the PoC needs to answer. We also establish what we’re explicitly not building today: authentication flows, error handling, mobile responsiveness, admin permissions. Anything that isn’t the core loop gets parked.
Inputs matter a lot here. The best-case scenario is an existing website, a design system, or even a well-structured brand guide. That gives AI something concrete to work from rather than generating into a vacuum.
Midday: build and deploy (3–4 hours)
Once scope is defined, we break the prototype into the smallest possible tasks. This is critical – not because it’s tidy, but because AI tools produce significantly better results when they’re working on focused, well-bounded problems rather than vague large prompts. Each task gets implemented, checked, and iterated before moving to the next.
Our go-to stack for this kind of work: Claude Code for implementation and Claude for architecture decisions. For deployment, we spin up a simple Digital Ocean droplet – nothing fancy, just enough to make it live and shareable. The client gets a real URL, not a local demo that only works on our laptop.
Late afternoon: iterate and hand over (1–2 hours)
We walk through the core workflows with the client, fix the obvious issues that surface, and document what’s in and out of scope. The handover isn’t just a URL – it’s a clear picture of what the PoC proved, what it didn’t, and what a next sprint would look like.
The biggest mistake clients make before a PoC is treating it like a product brief. A PoC needs one question, not ten features – the narrower the scope, the more useful the result.
What makes a good one-day PoC candidate
Not every idea fits this format. The ones that work well share a few traits:
- Narrow scope with clear inputs and outputs
- At least some existing material to work from (old site, design system, sample data)
- Core functionality that’s largely standard – content management, form handling, basic data display
- No hard dependency on complex third-party integrations on day one
Poor candidates are anything requiring deep legacy system integration, compliance validation, or multi-system data flows before the basic concept can even be tested. Those need a proper scoping sprint first, not a one-day build.
| Good PoC candidates | Poor PoC candidates |
|---|---|
| Internal knowledge Q&A tool | Complex legacy ERP integrations |
| Customer support chat demo | Multi-jurisdiction compliance validation |
| Invoice data extraction | Multi-system data flows on day one |
| AI-generated report summaries | Anything requiring prior data migration |
Validate fast, invest smart
The companies burning money on AI transformation aren’t usually picking the wrong ideas. They’re committing full build budgets before validating the core assumption. A one-day AI PoC exists to short-circuit that mistake.
Spending a week on an unvalidated assumption is expensive. An afternoon isn’t.
The alternative — running a full AI-assisted development cycle before testing whether the thing actually works in your environment — is one of the most consistent patterns we see in failed AI projects. We’ve written more about that in 5 mistakes you’re probably making in your AI transformation.
If you’re sitting on an idea and aren’t sure it’s worth building, that’s exactly the conversation to have. Our AI automation team works with businesses to scope, build, and validate fast – so you invest in what works, not what sounds good in a deck.
