How to Run an IaC Platform POC: What to Test in Two Weeks

If you have just a couple of weeks to recommend an IaC platform, you’ll find that it’s plenty of time to run a good POC but not enough time to run a bad one. Most teams spend the first week fighting setup and the second one clicking through a demo environment. They then decide based on which UI felt nicer and stick with that decision for years.

In this article, we will walk through the most common reasons IaC POCs fail, which POC prerequisites you need before you start, the two-week IaC platform POC plan, what to actually test (a POC evaluation checklist), and how to compare platforms after the POC.

What we’ll cover:

1. What are the most common reasons IaC POCs fail?
2. Before you start: POC prerequisites
3. The two-week IaC platform POC plan
4. What to actually test: A POC evaluation checklist
5. How to compare platforms after the POC

Before planning anything, it helps to know why IaC POCs often fail.

• You test the happy path: Vendors give you a clean sample repo with four resources, and everything works as expected. In your real setup, you have a 3,000-line state file, a module nobody has touched since 2024, and a provider pinned for reasons that are no longer clear. If your POC does not include at least one ugly scenario, you are testing marketing, not the product.
• You do not define what “good” looks like: Without criteria upfront, you will end up choosing whatever impressed you most in the last demo. We’ll look at how to avoid that in the next section.
• The POC does not involve the actual users: If your platform engineers run the POC and think it’s great, that doesn’t mean, for example, that the application team will think the same. If the people who will use the platform every day never tried it, you did not test adoption; you tested your own preferences.
• You forgot that the platform itself creates additional work: You choose a tool, and then seven months later your team spends most of its time maintaining the platform instead of shipping infrastructure. Your goal should be to focus on writing, planning, and applying infrastructure, without putting significant management into the platform underneath. So, during the POC, ask how much work each option will be to run, not how much work it saves you today.
• Two weeks can turn into two months: Not having a fixed end date, POCs can drift. So, to avoid this, set a two-week timeline and stick to it.

Define your evaluation criteria upfront. It’s important to know what you are actually judging these platforms on before you open a single trial account. Here are five criteria worth starting from:

• Ability to scale up and down based on demand: Infrastructure workloads can fluctuate significantly; you can have quiet days and then a release day where twenty runs land at once. The platform has to absorb that without you babysitting a worker pool.
• Simple workflows for engineers: Your app teams should be able to open a pull request, see a plan, and get their change applied without learning a new process. Every extra step you have to explain is a step where adoption leaks.
• Responsive technical support: If something went wrong in production at a bad hour, how fast the vendor answers is a product feature, and the POC is your only chance to test it before signing.
• A pricing model that makes sense as you scale: You need to know your costs, not just for the current infrastructure, but also when you have three times as many stacks and twice the number of engineers. Pricing behaves very differently as you grow.
• Readiness for agentic infrastructure workflow adoption: Now the team generates Terraform with LLMs, wires up MCP servers, and lets agents open infrastructure pull requests. Verify whether the platform has an API story, MCP support, and a plan for agents touching infrastructure; if not, you’ll have to replace it sooner than you think.

Evaluate the list above and see whether it fits your situation, or create your own, and then compare the two. Decide which criteria are dealbreakers and which are nice-to-haves.

Also, you need to line up the stacks, access, and people. Firstly, you need to choose two or three real stacks: one simple stack to test the basics; one complex stack with dependencies, modules, and a decent amount of state; and one production-shaped stack, or a clone of one.

Sort out access early because VCS integration, cloud credentials, and network access are common places where POCs stall. If your security team needs a week to approve an OIDC connection or a new IAM role, submit the request early and prioritize it accordingly.

Make a list of the people involved, naming the platform owner running the POC, at least two application engineers who will use it, and someone from security or compliance who can review the policy story.

Write down your baseline. How long does a plan take today? How many manual steps exist between a merge and an apply? How often do you find drift? You cannot show improvement without a starting number.

This plan covers ten working days. The first week checks that the platform works with your own code and state, and the second week tests how it behaves under load, failure, and policy. Run the same plan for every platform you evaluate, using the same stacks in the same order, and write your notes at the end of each day.

Day 1 and Day 2: Connect and import

Configure your VCS integration, connect your cloud accounts, and import your first stack. Be aware of how much time you spend running your first plan because that tells you something about the next hundred stacks. Then import your complex stack and see what breaks.

Time the full setup, from empty account to a first green plan, including credential approval. Note anything the platform asks you to change in your repository, such as a required directory layout, a wrapper file, or a different state configuration.

Day 3: Run the core workflow end-to-end

Open a pull request, get a plan, review it, merge it, and watch the apply. This is the loop your engineers will live in every day.

Check how much of the plan appears in the pull request itself and how much requires opening the platform separately. Then repeat the loop with a change that should fail, and see whether the error message is clear enough for the engineer to fix it alone.

Day 4: Add dependencies and modules

Real infrastructure isn’t just a flat list of configurations; it has an organization stack managing folders and IAM, separate staging and production stacks running your clusters, storage and databases, and a shared service stack holding things like your ArgoCD deployment and your CI runners.

All of these are wired together with dependencies and shared modules. Here, you can test whether one stack’s output feeds another or whether the dependency graph triggers downstream runs when something upstream changes.

Day 5: Let an app engineer test it

Give the engineer a task without training for about one hour. Then see how far he gets and what confuses him. This is your workflow simplicity test, and it is more than any feature list.

Watch instead of helping, and note every point where you wanted to step in and explain something. Each one is a place where adoption will slow down later.

Days 6 and 7: Policies and guardrails

Start by writing three real policies. For example, block destroy operations in production, require approval when a plan touches a database, and enforce that production runs go through private workers.

Write the policies yourself instead of copying the vendor’s examples, then open a pull request that violates each one. Check that the run is blocked and that the message explains the reason to the person who wrote the change.

Day 8: Scale and load

Simulate a busy release day by firing off as many runs all at once, and watch what happens to queue times. In this way, you find out whether the platform scales on demand or quietly makes you wait.

A platform that is fast with three runs but struggles with thirty won’t suit you.

Day 9: Failure modes and support

Modify something in the cloud console by hand and see if the platform notices. Also, you can cancel a run mid-apply or break a state lock on purpose. Then open a real support ticket and see the response time.

For drift, measure how long it takes to be notified and whether the platform can reconcile the change or only report it. Base the support ticket on a real problem from the POC rather than a test question.

Day 10: Cost and the write-up

Estimate your cost at your current size and at three times your current size. Then write up your findings and decide whether the platform still makes sense for you.

Ask for a written quote with the assumptions listed, and check how the price changes if you add another environment, 20 more engineers, or single sign-on. Keep the write-up to one page per platform and finish it on day ten.

Score each item from one to five and keep them grouped under the five criteria. That will give you a separate result for each one, instead of a single number nobody can trace back to anything.

Ability to scale up and down based on demand

• concurrency and queue behavior when you fire off runs at peak volume
• if workers auto-scale or you have to size a pool yourself
• private worker support for anything touching production
• how the platform behaves during a long, heavy apply

Simple workflows for engineers

• allocated time to first successful plan, and time to import an existing stack with real state
• readability of plan output in a pull request
• whether approvals and run history make sense to someone else than you
• wiring stacks together and passing outputs between them
• module registry, versioning, and templates for new stack
• whether an untrained engineer can ship a change alone
• coverage for the tools you already run, for example OpenTofu, Terraform, Pulumi, Ansible, Kubernetes

Responsive technical support

• what is the response time on a real ticket opened during the POC
• documentation coverage and quality for situations of emergencies
• whether you get a queue or a human

Pricing model that makes sense as you scale

• what the bill looks like at three times your size
• how the model charges (per resource, per user, per worker behave differently)
• hidden costs: extra environments, extra workers, SSO as a paid add-on

Ready for agentic infrastructure workflow adoption

• API coverage and MCP support
• whether policies and RBAC are strong enough to let an agent run safely
• audit trail quality, because you will want to know what the agent did

Teams are already tuning LLM-generated Terraform workflows, building internal infrastructure agents, using MCP for stack summaries, and experimenting with agentic workflows. This work only happens on a platform that was ready for it.

Once you have scored every platform, review the results and weigh the criteria you called dealbreakers.

Another thing to do before deciding which platform suits you better is to ask yourself these questions:

• Which one did the app engineers prefer? Choose a platform that your engineers don’t avoid because otherwise you’re paying for it twice.
• Which one will spend the least time maintaining? Here, you should think about worker pool upkeep, upgrades, and custom code you had to build to make the platform fit your workflow. You need to keep in mind that the maintenance burden compounds over time.
• Which one still works at three times your size? Look at your load test results and your scaled pricing together because cheap today and painful at scale is a bad trade.

If, after evaluating, two platforms score close, choose the one that provided better support during the POC.

Spacelift runs POCs on your infrastructure, not a sandbox. You connect your VCS, import existing stacks, and run your own cloud accounts, having full control of everything happening inside the platform.

You have multi-infrastructure tool support (Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Kubernetes, and Ansible), policy as code at multiple decision points based on Open Policy Agent (OPA), dependencies with shareable outputs between your configurations, self-service infrastructure, shareable variables/lifecycle hooks/mounted files for your configurations, AI intelligence baked in, and so much more.

Spacelift offers a free trial with no credit card required, in which you can test all Spacelift features, and here’s an example of how one of our customers has created a Spacelift accelerator, a configuration setup that builds most of the things you’d need to get started and to get a taste of what Spacelift has to offer.

Teams that choose Spacelift usually land on this choice for three specific reasons:

1. Reliability at scale (auto-scaling with demand)
2. Simple to operate (easy to plug in, and a very responsive support team in case you get stuck)
3. Built for what’s next (OpenTofu flexibility, policies and templates, and a path to agentic workflows)

Read more: Why DevOps Engineers Recommend Spacelift

Write down your evaluation criteria before day one. A solid starting list can be: scaling on demand, simple engineer workflows, responsive support, pricing that holds up as you grow, and readiness for agentic workflows.

It’s important not to test only the demo repos; test your real stack, including the more complex ones, and ask your app engineers to test the platform without any training, and watch what happens.

During the POC, you should also open a real support ticket and see how the support team responds. Consider how quickly they respond, how well they understand the issue, and how satisfied you are with the resolution.

You should score every platform the same way, and then validate the winner against adoption, maintenance load, and cost at scale.

If you want to learn more about Spacelift and get started with a POC, book a demo with one of our engineers.