How to Start Developing a New Product?

Starting a new product in 2027? Choose your infrastructure engine like it’s a 5-year decision 

When you start a new product, most early technical choices are easy to undo. Swapping a UI library or moving to a new analytics tool takes at most a few days. 

The tool you use to define your cloud infrastructure is different. Once your servers, databases, and permissions live in code, that code becomes the record of how your product runs. Every deployment depends on it. So does every engineer who joins after you. Teams rarely rewrite it. When they do, it takes months. 

For most of the last decade, the default answer was Terraform. In 2027, founders and CTOs have a real choice between Terraform and OpenTofu, its open-source fork. This guide covers what changed, how the two compare for a new project, plus the tooling you’ll need around whichever engine you pick.

What changed 

Terraform used to be open source under the Mozilla Public License. In August 2023, HashiCorp moved Terraform, along with its other core products, to the Business Source License (BSL), which is not an open-source license. The BSL limits how others can use the code, especially in products that compete with HashiCorp. 

A group of companies, backed by community members, responded by forking the last open-source version. That fork became OpenTofu. Since then, the two projects have moved in different directions: 

For a startup, the license change rarely matters on day one. You can still use Terraform to manage your own infrastructure. What it changes is the long-term picture. Who controls the roadmap? What will it cost later? Can you switch vendors without rewriting your code? 

Terraform or OpenTofu for a new project 

For a greenfield project, the two tools feel almost identical on day one. They use the same configuration language. The same providers work with both, as do the same modules. The differences show up over time. 

Two points matter most for a small team. 

Governance decides the long run. A single-vendor project can change its license, pricing, or priorities at any time, as the 2023 change showed. A foundation-governed project can’t be relicensed by one company. If you want to avoid vendor lock-in, that difference is worth more than any single feature. 

State encryption is a practical win. Your state file holds a detailed map of your infrastructure. It can also contain sensitive values. OpenTofu can encrypt it on the client side before it’s stored. That helps any team handling customer data. It can also make security reviews easier. 

What the engine doesn’t give you 

Terraform and OpenTofu are command-line tools. They read your code, compare it with what’s running, then make the changes. That’s all they do. 

Everything around that step is up to you. As a team grows, that’s where most of the real work sits: 

• Where state lives. The state file needs a safe home the whole team can reach. It also needs locking, so two people can’t change it at once. 

• Who can run what. Someone needs to decide who can change production, who can only plan changes, who signs off. 

• Rules that apply every time. Policies such as “no public storage” or “tag every resource with a cost owner” need to run automatically on every change. 

• A record of what happened. When something breaks, you need to see who changed what, at what time. 

• Pipelines. Changes should run from your code repository, with plans shown on pull requests, not from someone’s laptop. 

With Terraform, many teams cover this with HashiCorp’s own managed service. Teams that pick OpenTofu or want to avoid relying on a single vendor need another way to achieve the same controls. 

Some build it themselves with CI pipelines, cloud storage plus a few scripts. That works at first, but it becomes another internal system someone has to maintain. Others use an infrastructure orchestration platform.  

Spacelift, a founding member of OpenTofu and a sponsor of dedicated contributors to the project, offers native OpenTofu support that runs plans automatically, with policy checks on every change. Centralized state management, role-based access controls, audit logging: all built in. 

The cost of choosing wrong 

The engine itself is cheap to switch while your codebase is small. A few dozen resources and one environment can move in an afternoon. The trouble is that infrastructure code grows faster than most teams expect. 

Two years in, a typical product might run three environments, several services, shared networking, plus a set of modules other teams depend on. Every pipeline, policy or internal script assumes a particular tool. At that point, a switch is a project, not a task. 

The hidden costs of a late move usually include: 

• Engineer time. Someone has to test every module against the new engine, one environment at a time. Then the pipelines need updating, along with the docs. 

• Risk during the move. State files have to be migrated carefully. A mistake can make the tool think resources need to be recreated. 

• Lost features. If you’ve built around features only one engine has, you’ll need to rework that code before you can move. 

• Contract timing. If you depend on a vendor’s managed service, a switch often has to line up with a renewal date. 

None of this means the choice is permanent. Teams migrate in both directions. But the cheapest time to make the decision is before your first production deployment, when changing your mind costs almost nothing. 

A decision checklist for founders and CTOs 

There’s no single right answer. Work through these questions with whoever will own your infrastructure: 

1. How much does vendor independence matter to you? If you want the freedom to change tools, managed services or hosting without rewriting code, an open-source, foundation-governed engine gives you more room. 

1. Will you sell to large or regulated customers? Enterprise buyers often ask about licensing, supply chain risk, where your data lives. A clear open-source license and encrypted state can shorten those security questionnaires. 

1. Do you need a managed service on day one? If yes, compare what each option costs as you grow, not just on the free tier. Ask how pricing scales with the number of resources you manage. 

1. What does your team already know? Both engines use the same language, so existing Terraform skills transfer directly to OpenTofu. 

1. Which features do you need now? If state encryption or another OpenTofu-only feature solves a real problem for you today, that’s a strong signal. 

1. Who will maintain the tooling around the engine? Decide early. Will you build pipelines, state storage, access control yourself, or use a platform? 

If you’re starting from scratch and have no compelling reason to tie yourself to a single vendor, OpenTofu is a safe default. You keep the Terraform language with its ecosystem. You also avoid a license that one company can change. If your team already depends heavily on HashiCorp’s managed service, staying on Terraform may be simpler for now, as long as you plan for the option to move. 

Already on Terraform? What a move looks like 

Many products aren’t truly greenfield. You may have inherited Terraform code from an earlier version of the product or from a contractor. Moving to OpenTofu is still usually manageable, especially early. 

1. Check your version. OpenTofu is a drop-in replacement for Terraform 1.5.x. Code and state from later Terraform versions need the official migration guides. 

1. Back up your state. Before anything else, take a copy of every state file so you can roll back. 

1. Run a plan with OpenTofu. Point OpenTofu at your existing code and state, then run a plan. If it shows no changes, the engine sees your infrastructure the same way Terraform did. 

1. Move one environment first. Start with development. Run it for a while before moving staging, then production. 

1. Update pipelines and docs. Change the binary your pipelines call. Update onboarding docs. Make sure nobody keeps running the old tool out of habit. 

If you use a platform to run your infrastructure changes, check whether it lets you switch the engine per project without losing your policies or integrations. That makes a gradual move much easier. 

Three myths worth ignoring 

“OpenTofu is just a copy.” It started as a fork, but it has shipped its own releases and features since 2023, including state encryption. 

“Our modules won’t work.” Existing providers work with OpenTofu. So do modules. It uses the same language as Terraform, with the same registry protocols. 

“Open source means no support.” Several companies offer commercial support for OpenTofu. The project itself sits under the Linux Foundation, with CNCF backing, rather than with a single vendor. 

Questions to ask your development partner 

If an agency or contractor builds your product, they’ll often make this choice for you, sometimes without asking. Before work starts, ask: 

• Which infrastructure as code tool will you use? Why that one? 

• Will all of our infrastructure be defined in code? Will we own the repository? 

• Where will the state file be stored? Is it encrypted? 

• Which managed service or platform will run the changes? Whose account is it in? 

• What would it take for another team to take over our infrastructure if we part ways? 

A good partner will have clear answers. They’ll also set things up in accounts you control. If the answers are vague, you may end up locked into their tooling as well as a vendor’s. 

Decide before your first production deploy 

Your infrastructure engine will likely outlast your first tech stack. It may even outlast your first business model. It deserves more thought than it usually gets. 

In 2027, the choice comes down to control. Terraform is a mature tool owned by one company. OpenTofu offers the same language under open-source governance. Whichever you choose, plan for the tooling around it. Keep the code in accounts you own. Most of all, decide while it’s still cheap to change.