From ClickOps to Infrastructure as Code

A focused project area for teams that have working infrastructure, but too much of it lives in cloud consoles, scattered notes, or one founder’s memory.

Manual cloud setup is normal in the early stage. You click together what the product needs, keep moving, and avoid spending time on infrastructure abstractions before the business needs them.

That tradeoff changes when you raise funding and start hiring engineers. If important production resources only exist because a founder clicked them into place, the team has no reliable way to understand, review, reproduce, or safely change the setup.

When This Matters

This is worth looking at when:

• Nobody is fully sure which cloud resources are production-critical
• Infrastructure changes happen manually in the console
• Staging and production are similar but not intentionally defined
• A new engineer cannot tell how the system is assembled
• There is no review history for infrastructure changes
• Recreating the setup would require founder memory
• The team is not sure whether it needs Terraform, OpenTofu, Pulumi, or something simpler

The goal is not to put every tiny resource into code on day one. The goal is to make the important parts understandable and repeatable first.

What We Might Work On

Depending on the current setup, this could include:

• Mapping the current cloud resources and production dependencies
• Identifying which parts should become infrastructure as code now
• Choosing a right-sized IaC approach for your team and stage
• Importing or recreating key resources in Terraform, OpenTofu, Pulumi, or another workflow
• Creating a clear module and file structure that new engineers can follow
• Adding review and apply conventions for infrastructure changes
• Documenting what is code-defined, what is intentionally manual, and what can wait

Possible Outcomes

After the work, the team should be able to answer basic infrastructure questions without archaeology:

• What exists?
• Why does it exist?
• What environment does it belong to?
• How do we change it safely?
• What is still manual and why?
• What should become code-defined next?

The output is a calmer baseline: the important parts are visible, reviewable, and less dependent on one person’s memory.

A Good First Step

If you are not sure what should become infrastructure as code first, the best starting point is a free discovery call or an Infrastructure Foundations Review if the right next move is not clear yet. The review separates the risky manual parts from the ones that are fine to leave alone for now.