Every growing software company eventually hits the same wall. Sales has a prospect who wants to see something. Leadership has an idea that needs proving before it earns a budget line. And the only people who can build it are the core product team, who are already committed to a roadmap that customers are paying for.

So someone makes the call to “borrow” a few engineers for two weeks. Two weeks becomes six. The roadmap slips, the demo is half-finished, and nobody is happy.

I’ve watched that pattern for 30 years of building and rescuing enterprise systems. I’m CTO at Axina Group, where we build AXERP, our ERP, CRM and HR platform, and I take on fractional CTO work through CTO Rescues. In both roles, my answer has become the same: give proof-of-concept work its own dedicated team.

What a POC is for

A proof of concept has one job: make an idea real enough that people can react to it.

Internally, that means a leadership team can click through a working flow instead of debating a slide. Externally, it means a potential customer can see their own problem being solved, ask sharper questions, and tell you what actually matters to them before you’ve spent a year building the wrong thing.

A POC is a sales and learning tool, not the product.

Why a dedicated team

The core product team’s job is to protect the roadmap, the quality bar and the customers already on the platform. Every hour on speculative demos is taken from customers already paying you.

A dedicated POC team changes the economics. It has its own repositories, backlog and definition of done, so the core team keeps shipping. When a demo lands and a deal moves, the core team inherits a validated idea, a clearer spec and real customer feedback, not a half-built side project and a slipped release.

Meet Higgins, my AI major-domo

Before I introduce the team, I should introduce the house it lives in.

Higgins is the AI chief of staff I built for myself: my own major-domo. Think Jarvis, with a better filing system. Every morning, Higgins briefs me and the team. Through the day, it tracks open tasks across our projects, files documents where they belong, and helps with research and first drafts. The result is simple: less time spent chasing information, and more time spent building.

The same idea sits behind the AI Chief of Staff in Axina’s AXINA AI Backoffice Suite, which brings together AXERP, Nextcloud, OpenProject and optional secure mail, hosted on AWS. Higgins is where we live with that idea first, every day, on our own work.

One rule never changes: a person stays accountable. Higgins drafts and organizes. I decide.

Why a chief of staff is the right home for a dev team

The development team is Higgins’s newest capability, and putting it there was deliberate.

A good chief of staff already knows the projects, the priorities and where everything lives. Higgins already knows our projects, what matters this week, and which repositories hold which work. A dev team that starts from that context doesn’t need a long onboarding before every run, and it doesn’t build in a vacuum. When a demo is needed, the request arrives with the background already attached.

Our version: the Higgins dev team

Inside Higgins sits a dedicated development team made up of AI agents, each with one clearly defined role, and each running on the model that fits the role, from Claude Opus and Sonnet to Haiku and Grok.

Here’s the roster:

  • Doug, the Foreman, writes the spec for every run: the PR title, acceptance criteria, files in scope, size, and which builder fits. Doug is read-only. He plans; he doesn’t touch code.
  • Bob, front-end builder: React, Vite, Next, Astro, Tailwind, static sites, AXERP admin screens and accessibility.
  • Chris, back-end builder: AXERP apps, FastAPI, Node, Go, Lambda and Azure Functions.
  • Peter, database builder: PostgreSQL and MariaDB, migrations and indexes, proven on throwaway databases first.
  • Wayne, infrastructure builder: Terraform, Bicep, CDK, Helm and GitHub Actions on AWS and Azure. Wayne checks his changes but never applies them.
  • Gord, analytics builder: dbt, DuckDB, SQL models, Power BI and Fabric, Athena and Redshift.
  • Mike, the tester: on medium and large tickets, writes the acceptance tests before the build. They must fail first, and the builders can’t edit them.
  • Steve, lead reviewer: reviews every change against Doug’s spec, scores the gaps in the tests, and critiques large specs before anything is built.
  • Sandy, security reviewer: reviews risky changes (auth, secrets, uploads, IAM and infrastructure, SQL, workflows) with gitleaks and semgrep results in hand. Read-only.
  • Sally, UI/UX designer: writes a UX brief before medium and large front-end builds, and reviews every UI change from Playwright screenshots at phone and desktop widths.
  • Terry, CI medic and librarian: watches CI on each draft PR, keeps each repository’s lessons, and runs the weekly benchmark.

The flow: Doug specs, Mike writes failing tests, a builder builds, Steve, Sandy and Sally review, and Terry keeps CI honest.

Guardrails, not just speed

Speed without guardrails just produces mistakes faster, so the guardrails are built into the roles:

  • Tests come before code. Mike’s acceptance tests are written first, must fail first, and can’t be edited by the builder trying to pass them.
  • The planner and the security reviewer can’t write. Doug and Sandy are read-only, so the agent who specs or judges a change isn’t the one making it.
  • Nothing touches infrastructure automatically. Wayne proposes and checks; a person applies.
  • A named person approves. Every change arrives as a draft PR. I, or the engineer accountable for that repository, decide what merges and anything consequential that follows.

AI drafts, checks and flags. A named person decides. That’s the same principle we apply to KYC and process inside AXERP, and it applies just as much to how we build software.

It frees our human engineers for architecture, customers and hard trade-offs. Chasing a flaky CI job is exactly the unglamorous work where AI earns its place.

Could this team build the production product?

Honestly, yes. The same specs, tests and reviews that make a good demo are the foundations of production software.

But that’s not the point of a POC team, and it shouldn’t drift into being a second product team. The focus is speed to a credible demo: get it in front of the leadership team or the prospect, use it to support the sale, learn what the buyer really values, and then build the final version properly, with the core team’s standards and roadmap behind it.

The honest trade-offs

A POC skips things on purpose, and you should say so out loud:

  • Scale. It’s built for a demo audience, not thousands of concurrent users.
  • Hardening. Security is reviewed, but full penetration testing, compliance evidence and disaster recovery belong to the production build.
  • Breadth. It covers the path that proves the idea, not every edge case, permission or integration.
  • Operations. Monitoring, support runbooks and SLAs come later.
  • Data. Demo data and throwaway databases, never real customer records.

None of these are failures. They’re choices, and the danger is only in hiding them. If a prospect believes the demo is the product, you’ve made a promise your production team now has to keep on someone else’s timeline. Say clearly what the demo proves and what it doesn’t, and the conversation gets better, not worse. Buyers trust a vendor who tells them where the edges are.

The handoff

The handoff is where a POC pays off or becomes technical debt. Ours carries forward what matters:

  • Doug’s specs become the starting backlog for the production team.
  • Mike’s acceptance tests become the first regression suite.
  • Sally’s UX briefs and screenshots show what users actually responded to.
  • Terry’s repository lessons record what broke and why.

The code itself may be kept, refactored or thrown away; that’s the production team’s call. What survives is the knowledge, and that’s the expensive part.

Timing matters too. Hand off once the demo has done its job, a deal is moving or leadership has said yes, and not before. Hand off too early and the core team inherits a guess. Wait too long and the demo starts to look like a product that nobody planned to support.

Where this leaves us

A dedicated POC team lets you say “yes, let me show you” to a prospect without saying “sorry, it’s delayed” to your existing customers. With guardrails and clear human accountability, it’s one of the most practical uses of AI in software I’ve seen.

If you’d like to talk about setting up something similar for your organization, you can reach me at https://ctorescues.com.

So here’s my question for you: when your sales team needs a demo, who builds it today, and what does it cost your roadmap?

This article was first published on LinkedIn.