Introduction

Playwire helps publishers monetize websites and mobile applications. Publishers add a JavaScript tag to their sites, while Playwire's internal Yield team uses a control panel to configure which ads appear, where they render, and how they behave.

That control panel had grown into a large Ruby on Rails application over eight to ten years. Playwire needed to replace it with a backend that could support its next stage of development. The company chose TypeScript and Encore, which let the team build the new system without delaying its existing DevOps roadmap.

Quantifying the impact

• 1-2 months of infrastructure work avoided — No separate Kubernetes and CI/CD project was needed to get started
• Deployments cut from 25 minutes to 5 — And without interrupting users mid-session
• Ruby engineers productive within one sprint — Contributing features and merging approved TypeScript PRs
• Zero DevOps engineers dedicated to the stack — 18 months in, the team has not needed to take over the infrastructure
• Preview environments for every PR — Each with isolated infrastructure, giving product managers working software to review

A critical application had reached its limits

The control panel's architecture reflected years of changing requirements, and some of the capabilities Playwire needed next no longer fit cleanly. A new, fine-grained authorization system was one example. Retrofitting it would have required changes extensive enough that rebuilding the application made more sense.

Playwire decided to rebuild, using what it had learned over the previous decade to start with a simpler architecture.

The choice of language also mattered. Rails had served the company well, but recruiting Ruby engineers was becoming harder. Meanwhile, Playwire's browser-side systems were already written in TypeScript. Using TypeScript across the frontend and backend would let teams own features end to end instead of handing work between language-specific groups.

Rather than one team for this repo and one team for that repo, we could have one team for a feature set end to end.

Choosing the backend stack

Playwire evaluated its options in the fourth quarter of 2024. TypeScript was decided early. The remaining question was what the team should build on.

The evaluation included Bun, Cloudflare Workers, Hono, and Encore. Pat Lawley liked Hono's use of web standards and its flexibility. But choosing it would still leave Playwire responsible for building development environments, CI/CD, cloud infrastructure, API tooling, and the conventions needed to keep the codebase consistent.

Encore provided those pieces as part of the stack. Developers could run the application locally, inspect and call backend APIs through the local dashboard, generate a type-safe frontend client from the backend, and deploy the application to Playwire's AWS account.

We could build similar stuff in Hono or another framework. With Encore, we just didn't have to.

The evaluation was brief because the difference became clear quickly. Engineers responded well to the local development workflow, while the generated client carried backend types into the frontend without another integration layer to maintain.

Open source was a requirement. Playwire was making a long-term architectural decision and did not want the application's future to depend entirely on a vendor.

Encore is open source, which gave us the escape hatch we needed. We were making a major investment in a new framework, and relying on a closed-source platform would have been too great a risk.

Building in parallel with the DevOps roadmap

Playwire already had a DevOps team, but it was committed to moving the company's existing infrastructure to Kubernetes, GitOps, and Terraform. Building the foundations for another backend stack would have competed with that work.

Encore removed that dependency. The control-panel team could establish the new application and deploy it to AWS while the DevOps team continued its existing roadmap.

Pat estimates that setting up Kubernetes, CI/CD, environments, logging, and the related operational details would have taken one to two months once reviews and edge cases were included.

Encore allowed the new control panel team to jump in and get a bunch of work done without distracting the DevOps team. It just let us work in parallel.

Encore provisions and manages the application's Kubernetes infrastructure in Playwire's AWS account. Playwire owns the account, the resources, and the cloud bill, while Encore manages the underlying infrastructure and deployment layer.

The original plan was for Playwire to take over management of that infrastructure once the new system had stabilized. After 18 months, the team has not needed to.

I assumed we would eventually want to take over management of the Kubernetes infrastructure running the Encore application in our AWS account. More than a year in, we haven't, because there's been no need. It just works.

Bringing the existing team onto TypeScript

Playwire began with Pat and two TypeScript engineers, who established the core architecture and development patterns. Once those patterns were working, engineers from the Ruby and browser-side JavaScript teams joined the project.

Ruby engineers who were new to TypeScript were contributing features and merging approved PRs within a single sprint. The first tasks were deliberately scoped, but the speed of the transition still exceeded Pat's expectations.

He attributes part of that result to the consistent structure Encore gave the codebase. Services followed the same layout and conventions, reducing the amount of project-specific knowledge engineers needed before they could make a useful change.

Engineers moving from Ruby to our Encore TypeScript stack were actively contributing features within a single sprint.

Shorter deployments and a faster development loop

Deployments of the Rails application took around 25 minutes and required a Slack message asking users to save their work. Deployments of the Encore application typically take about 5 minutes and do not interrupt users.

Playwire added a small amount of CI/CD configuration to publish frontend builds to its CDN. Authorized engineers can now create a GitHub release and deploy the complete application without help from the DevOps team.

The local feedback loop improved as well. Running the application locally provisions the infrastructure it needs on the fly, so an engineer gets a working environment without configuring one first.

Because Encore parses the application's API definitions, it also knows every service's contract and checks call sites against it as the code changes. Backend changes reload immediately, and type or contract errors surface while the engineer is working rather than later in the build or integration process.

Encore instantly recompiled or told you there's a syntax error or contract error now. It makes the development feedback loop much faster.

Preview environments for every PR

Playwire uses MongoDB, which it manages separately from Encore. The team connected its own database-seeding process to Encore's preview environments.

Each PR now creates an isolated application environment and a matching MongoDB database. The database is populated from JSON seed files stored with the branch, so its state is versioned alongside the code. Both the environment and the database are removed when the branch is merged.

This gives product managers working software to review before a change reaches production. Instead of discussing unspecified edge cases in a ticket, engineers can share the preview and collect feedback against the actual behavior.

With Encore's preview environments, it's really easy to hand a PR to a product manager for them to click around and get a realistic view of what those edge cases are and how they want to solve them. We can quickly get feedback on that.

Why Encore remained the right long-term choice

Encore's value continued after the new application reached production. It manages the Kubernetes infrastructure in Playwire's AWS account, keeps deployments self-serve, and provides a consistent development workflow as more engineers join the codebase.

Playwire could take over the infrastructure itself, but doing so would add an operational responsibility without solving a problem the team has. More than a year in, the application has remained reliable and the platform continues to save work for both application and DevOps engineers.

Encore skipped a lot of work that I didn't have to give to my DevOps team. The point never came where I felt we weren't getting good value from the platform.

Encore's response when Playwire encountered edge cases further reinforced the decision. Issues raised by the team were addressed in new releases within roughly 72 hours, reducing the risk of making Encore a central part of its backend architecture.

Seeing how fast Encore ships updates and addresses problems as they come has been hugely beneficial to the confidence that we made the right decision.

Results at a glance

• Rebuilt a 10-year-old Rails application in TypeScript without a separate infrastructure project
• Avoided an estimated one to two months of Kubernetes and CI/CD work
• Reduced deployment time from 25 minutes to 5 minutes
• Ruby engineers merging approved TypeScript PRs within one sprint
• Runs on Encore-managed Kubernetes in Playwire's AWS account, with no dedicated DevOps engineers

Playwire set out to replace a decade-old Rails application, standardize on TypeScript, and let teams own features across the frontend and backend. It also needed to do this without delaying an existing DevOps program.

Encore gave the team a working backend foundation from local development through deployment in its own AWS account. Playwire avoided a separate infrastructure project, brought existing engineers onto the new stack within a sprint, and reduced deployment times by more than half.