Run a Two-Week Proof of Concept

A proof of concept (POC) answers one question: will this platform work for our project, our content and our people? Two weeks is enough to answer it if you scope tightly, use real content and involve real editors. This guide gives you a plan, the roles to involve, and a way to score the result.

What a POC should and shouldn't prove

Prove the risky parts. Pick the requirements you are least sure about: an unusual content model, a complex page, a localization pattern, an integration, a governance rule. A POC that only builds what every CMS can do teaches you little.

Use real content and real editors. Sample content hides modeling problems, and developers testing editor tasks hide usability problems.

Don't build production. A POC is a working site, not a production site. It can skip hardening, full test coverage and monitoring. From Proof of Concept to Production lists what a POC usually skips, which is also a useful list of what not to judge it on.

Before day one

• Write down three to five use cases that represent the project, including at least one of your riskiest requirements.
• Agree the success criteria and how you'll score them (see Scoring below). Agree them before anyone sees a demo.
• Gather real content: a representative sample of pages, content types, images and, if relevant, locales.
• Get an instance. Sign up and start a free trial, as described in Quick Start: The Basics, or, if your organization is already a customer, ask your Customer Success Manager to add an instance.
• Pick the front end and the host. Use the framework you expect to use in production. Agility recommends Next.js or .NET for new projects.
• Book the editors' time for week two. This is the step most often skipped.

Who to involve

Role	What they do in the POC
Sponsor	Owns the decision and the success criteria. Attends the readout.
Lead developer	Builds the front end and integrations, and judges the developer experience.
Content architect	Designs the content model and checks that it fits your real content. Often the lead developer on small teams.
Editors (two or three)	Do real editing tasks in week two and score the editor experience. Include someone from each team that will publish.
IT or security reviewer	Reviews sign-in, permissions, data handling and documentation in parallel.
Agility contact (if you have one)	Answers questions and unblocks setup.

The plan

Week one: build

Days	Work	Done when
1	Turn the use cases into a feature map. Create the instance, API keys and sitemap. Connect your tools.	Everyone can sign in, and the front-end project runs locally against the instance.
1 to 2	Model the content: content models, component models and page models for your use cases.	The model holds your real content without workarounds.
2 to 3	Import or enter real content. Build the components and pages.	Your use-case pages render with real content.
4	Wire preview, Web Studio and a publish webhook that revalidates the site. Deploy to a real host.	An editor can preview a change and see it live after publishing. See Setting Up Preview and Webhooks.
5	Build the riskiest integration, or a thin slice of it. Fix what broke.	The integration works end to end on at least one real case.

Week two: test

Days	Work	Done when
6 to 7	Editor sessions. Editors complete the task script below while someone takes notes.	Every editor has completed every task, or you've recorded why not.
8	Governance: set up roles, an approval workflow and scheduling for your real teams.	Permissions and approvals behave the way your process needs.
8 to 9	Localization, multi-site or other requirements from your list. Security review answers.	Each requirement is shown working or recorded as a gap.
10	Score, write up and present the readout.	The sponsor has a recommendation and the evidence behind it.

An editor task script

Give each editor the same tasks, on real content, without coaching:

1. Find and update an existing piece of content, preview it, and publish it.
2. Create a new page from a page model, add and reorder components, set its SEO title and description, and send it for approval.
3. Edit content in context on the site in Web Studio.
4. Replace an image and adjust how it's cropped.
5. Schedule a change to go live at a set time.
6. Create the same content in a second locale, if you need locales.
7. Find something they changed earlier in the session and restore the previous version.

Record the time taken, where they got stuck, and how confident they felt, on a scale of 1 to 5.

Scoring

Score each criterion from 1 (doesn't meet the need) to 5 (meets it well), multiply by the weight you agreed before the POC, and add up. The weights are yours: they should reflect your priorities, not the vendor's strengths.

Criterion	How to test it	Weight	Score (1 to 5)
Content model fits real content	Content architect's review after import
Editor experience	Editor task script results
Page management and preview	Editors create and preview pages unaided
Governance	Roles, approvals and scheduling set up for real teams
Developer experience	Lead developer's review of APIs, SDKs and docs
Performance	Measure your deployed POC pages
Riskiest integration	Working end to end
Security and compliance	Reviewer's findings against your requirements
Localization or multi-site (if needed)	Shown working on real content
Portability	You can export what you built. See Data Portability and Exit.

Keep a short list of gaps next to the score: what didn't work, whether it's a product limit or a POC shortcut, and what would close it.

Build it faster with AI

With an AI coding tool and the Agility CMS MCP Server, the AI tool can create the content models, components and seed content as well as the front-end code. That can compress week one, leaving more of the two weeks for testing with editors.

• Vibe Coding with Agility explains the approach, what it needs, and when not to use it.
• From Brief to Working Site: The Vibe Coding Workflow is a step-by-step workflow that maps closely onto week one of this plan, from feature map to deploy and demo script.

Whatever builds it, keep the editor sessions in week two. They are the part of a POC that AI can't do for you.

The readout

Keep it short and evidence-based:

1. The use cases and success criteria you agreed at the start.
2. The scores, with the evidence behind each one: recordings, notes, links to the deployed POC.
3. The gaps, and for each one whether it's a product limit or a POC shortcut.
4. A recommendation, and what the next phase would cost in time and people. Building the Replatforming Business Case helps with that step.

Related

• Choosing a Headless CMS: A Capability Checklist
• Evaluate Agility with an AI Agent in 30 Minutes
• Is Agility Right for Your Project?