From the Ashes: (Re)building the Spine Platform with IaC - Part 1

Phoenix image designed by Wannapik

Infrastructure as Code (IaC) is one of the more subtle, yet powerful tools in a Platform Engineer’s belt. More than just a way to codify and store the definition of (cloud) computing resources, IaC is a quintessential reflection of DevOps philosophy: the ability to apply good software engineering practices to the management of (virtual) hardware.

Good IaC allows infrastructure to be reliably and repeatable iterated, tested, and released to production just like any functional code commit. It allows large-scale ecosystems of hardware to be broken up and distributed across a codebase for management by autonomous engineering teams alongside the applications they build. It can also be used to consolidate chunks of inter-related infrastructure into coherent platform-as-products that evolve together as something greater than the sum of their parts.

Arguably though, one of the most compelling reasons to use IaC is repeatability: using declarative IaC, engineers can easily and consistently return their infrastructure to an exact desired state – even if the starting state is “accidentally deleted”. Tweak a few configs, and your Continuous Integration (CI) pipeline can instead deploy a new, duplicate instance. This pattern is used for everything from scaling platforms to new environments (or regions) to templating standard approaches to mundane infrastructure tasks.

An (over)confident Platform Engineer might even say, “so long as we have all the IaC, we could rebuild the entire company from scratch!”, and this is true, theoretically.

How often is that logical extreme application of IaC really put into practice though? And what road bumps might one expect when they try reinventing the universe from scratch?

Over the last few months, we at Spine Energy Technology have been finding out exactly that.

In this blog series, I’ll describe the journey we went on re-bootstrapping an entire SaaS platform from zero to customer-in-production armed only with the IaC recipe and highlight some of the key insights we had along the way.

The Background

Early in 2025, the company I worked for – Origami Energy – sadly folded; going into administration after a long and colourful history. Origami was survived – albeit briefly – by its (really well-engineered) SaaS platform, running on a skeleton crew for a few months while the renewables assets it managed could be offboarded.

However, the time, energy, and passion that went into the development of that original platform was not wasted: shortly after Origami’s end, its key technologies were bought out of administration by a newly minted company: Spine Energy Technology. Picking up the metaphorical (and presumably LED-based) torch of green energy technology, Spine acquired the Origami codebase, some of its key IP, and recruited a few from the skeleton crew, myself included.

Armed with the entire IaC codebase*, and a pretty good recollection of how things had been put together, we set out to (re)build the Spine Platform from scratch.

* - For context on scope and scale: at the end, the production platform (a multi-tenant SaaS product, hosted on EKS) contained around 120 Deployments, and a further 40 StatefulSets, not counting all the AWS resources supporting that rich application layer.

The Good

Let’s start – as all good retrospectives should – with what went well:

• We were successful(!)

The Spine Platform is live in production! So, it is indeed possible to re-bootstrap an entire company using just the IaC.

Time from new AWS root account to live customer usage: ~4 months.

That timeline might seem a little chilling: 4 whole months to get back to production-readiness when we had access to the complete IaC sounds a bit mad. However, given that scale of the team (2 engineers), the need for entirely new product tech to be spun up, and the amount of non-engineering work necessary to incorporate a new startup (lots), I’m incredibly proud of how quickly we pulled it all off.

I’d even go so far as to say that 4 months may be a bit optimistic for the average phoenix-like rebuild of a SaaS platform, as we had an awful lot of fair winds in our favour. Here then, are the factors which made Spine’s rebuild as quick and smooth as it turned out to be:

• We could focus on a sensible MVP

  
  

Of the ~160 individual Kubernetes-level applications in the Origami platform, we able to reduce the required scope to only 57 to form the Minimum Viable Platform for Spine.

While this does mean that the Spine Platform currently has fewer functional capabilities, it also means that the Origami Platform had around 100 more apps than were really necessary given the current market demand. A large part of this reduction in scope was possible because:

• We could drop a lot of legacy code

There are many reasons that legacy code exists: that one customer who refuses to move off /v1/, the product owner who won’t admit defeat for a failed experiment, or simply time’s inexorable march causing the purpose and justification for an app to fade from a team’s collective memory.

Whatever the reason, legacy code is ultimately a drag on development – constraining the evolution of the product, while costing a disproportionate amount of hosting $$$, cognitive load, and maintenance effort.

So, with a laser-focus on customer requirements, and a firm management of expectations, we were able to clean the slate for Spine. Beyond the reduction of maintenance overhead (not to mention the catharsis of archiving legacy repositories), this made our lives a lot easier because:

• All our applications are distributed and independently deployable

One non-functional benefit of a microservice architecture is that you can represent your modular, composable applications with independent, self-contained code repositories. If you also store each app’s IaC alongside its functional code, then (along with a lot of great benefits around application lifecycle management) you can very easily deploy your complete app – supporting infrastructure and all – in a single CI pipeline.

This means that omitting or retiring an app is incredibly easy: simply don’t run those pipelines. Implemented across an entire platform of applications, this means the effort required to rebuild that platform scales linearly with the number of required applications within it.

Of course, this approach could still mean an uneven amount of rebuild effort per-application, depending on the age and complexity of each repository. However:

• We had recently migrated all apps to a single hosting standard

Around a year prior to Origami’s demise, the Platform Team had led an effort to consolidate deployment and hosting standards within a single best-practices internal developer platform. Part of this work involved updating all applications to adhere to the new hosting guard rails (generally meaning the removal of per-application boilerplate config) and migrating to a new hosting cluster**.

** - Note that this earlier migration process also involved the retirement of many legacy legacy applications.

This meant that at the start of the Spine rebuild, not only was every application starting from roughly the same deployment scope and standard, but each app had also already been through one cluster-to-cluster (and in some cases account-to-account) migration. This gave us every confidence that nothing at the application level had hardcoded or implicit dependencies on the previous environment itself.

Also, it bears mentioning that despite a common set of deployment standards and platform-level abstractions to simplify development, the platform as a whole was not locked to a single IaC toolchain. Despite this:

• IaC technologies work well together (for independently deployed projects)

We used at least two different IaC frameworks (raw terraform and CDKTF) across our software projects. This was great for squad autonomy (which has its own benefits), but could plausibly have caused some issues for maintaining the wider platform. However, given that each independently-deployed application used its own independent IaC with its own state files, these frameworks can happily coexist in parallel.

While we weren’t using the most disparate frameworks (CDKTF renders down to terraform under the hood), I have confidence that the same peaceful coexistence would emerge for any arbitrary combination of IaC frameworks, so long as no two pieces of IaC attempted to own the same individual resource.

Beyond the application layer, the above migration work also benefited us because:

• We had built repeatable platform-as-product blueprints

In defining the new hosting standards and internal developer platform mentioned above, the Origami Platform Team developed two “platform products”: one for hosting (Canvas), and one for auth and identity management (Signature).

In essence, each platform product is an IaC monolith super-project, unifying multiple infrastructure components and platform-level applications into a single coherent deployable product.

This massively simplified the process of configuring, deploying, and evolving these large-scale Platform components, meaning that the recreation of the base Spine platform was essentially two CI pipelines. However, the platform product pipelines had one other benefit:

• We practiced tearing down and rebuilding the base platform regularly

As both a cost-saving exercise and means of regular testing of the platform bootstrap IaC itself, we regularly tore down and rebuilt our development sandbox environment. This regularly caught issues with dependency ordering (note: foreshadowing) but also gave us a lot of confidence in the repeatability of an otherwise very complicated deployment process.

Rebuilding the Platform Products for Spine was, therefore, not too far from a well-tested lifecycle process.

So, in summary our IaC had every advantage going for it, and the Developer Platform was intentionally designed to be rebuilt in the kind of way that Spine needed. So, why did it take four months to get to production readiness?

In part 2, I’ll cover the various devils in the IaC details: the pain points, the ugly truths, and the places where reasonable choices made in the past did not help us out in Spine’s rebirth.

In part 3, I'll wrap everything up with some key takeaways and best practices.