Building tools for experienced developers with André Eriksson from Encore
André Eriksson's answer to "what if Encore goes out of business" was to open-source the entire framework and invest in making migration away from it as painless as possible. His reasoning: a customer you're not secretly holding hostage is the only kind of forcing function that keeps you actually improving the product.
André Eriksson is the founder of Encore, a backend development engine built on Go that treats distributed systems concepts like services and APIs as first-class primitives in your code.
We get into the two and a half years he spent building Encore on the side of a staff engineering job at Spotify, why most dev tools improving one narrow slice of the workflow only ever buy back about 1% of productivity, and why he deliberately made it easy for customers to migrate away from Encore entirely.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What is Encore, in your own words?
We call it a backend development engine, though the comparison to Ruby on Rails is a good one. It's a platform that simplifies nearly every part of the developer experience for primarily early-stage startups — how you write code, how you collaborate and review it, how you merge and deploy to production, how you provision infrastructure, and how you find and fix bugs once something's live.
Encore makes code easier to write without dictating exactly how someone's system should be structured. How does that actually work?
What Encore really does is take the genuine improvements in how we build backends over the last five to ten years — microservices, distributed systems, API design — and encode those learnings into a deliberately opinionated framework, so developers can focus on their actual product instead of boilerplate, configuration, and other work that has nothing to do with what they're actually trying to build.
You spent two and a half years building Encore on the side of a full-time job at Spotify before launching. What gave you the conviction to take on something that ambitious?
Before founding Encore, I was a staff engineer at Spotify, and I hit constant, daily frustration with how we built software there. I started asking what a truly perfect developer experience would actually look like, and realized it looks nothing like how we typically build things — we needed a new foundation built on the system actually understanding what it's doing. Modern backend applications are remarkably complex: hundreds or thousands of services, each with thousands of lines of code and its own infrastructure, and developers are holding all of that complexity in their heads while their tools have zero awareness of any of it. It's no surprise the tools don't help much — they're dealing with 'here's a database,' not helping you make sense of the complexity itself. Encore is built on Go, not a wholly new language, but it exposes backend concepts as first-class primitives directly in your code, which is what lets the framework actually understand your system and power every part of the developer experience around it. Facing that frustration every single day at Spotify is genuinely what fueled the motivation to keep building something better.
Why do you think most developer tools struggle to move the needle on developer productivity even when they solve a real problem?
What's hard about software engineering broadly isn't one big thing slowing you down — it's a thousand small cuts, which means you need a genuinely holistic view of the experience. Most dev tools look at one narrow slice of the workflow and optimize that, which makes sense because it lets you find a niche and focus. But if you're solving one problem out of a hundred, and each one only accounts for roughly 1% of the overall process, even an infinitely better solution to that one problem only buys back about 1% of productivity. You can Google any developer pain point and find a dozen startups addressing it, but you can't realistically buy a hundred different point solutions and expect the resulting workflow to feel coherent — it just becomes chaotic, and none of them integrate with each other.
How does Encore's own approach sit on that spectrum between narrow-and-easy versus broad-and-hard to adopt?
We deliberately went to the opposite extreme from a narrow point solution — being very opinionated about adoption, requiring you to actually write your code in this framework. That makes adoption meaningfully harder, but the payoff, if you do adopt it, is much larger. Every dev tool has to figure out where it sits on that spectrum: narrow and easy to adopt but limited in impact, or broad and harder to adopt but far more valuable once integrated. And the more critical the problem you're solving is, the harder it becomes to replace you later, but also the less likely a company is to want to replace something that's already working well.
Given that harder adoption curve, how did you actually land your first customers?
We focused on experienced engineers specifically, since that's our own background and we deeply understand these problems ourselves. Because of that, the way we describe the problems we're solving immediately resonates with engineers who've genuinely felt this pain — the product essentially communicates 'we understand you, we've lived this too' just by describing the problem honestly. The harder challenge is finding companies at exactly the right moment — Encore is really about going from zero to a working product fast and finding product-market fit quickly, but it's very hard to identify from the outside which companies are at that specific stage. So our strategy leans heavily on content: talking about the problems we solve and this different approach to backend development, letting people discover it, try it on a weekend side project, and then come back to us once they're ready to actually adopt it at work.
What does an actual sales conversation with a CTO look like for something as fundamental as Encore?
We're still iterating on this, because it varies a lot even among early-stage CTOs. Some are deeply technical and mainly want to know whether they can trust the product's underlying technical decisions — would they have made different choices themselves. Others are far more focused on organizational concerns — how Encore improves onboarding, standardizes how the team builds things, improves documentation, or generates architecture diagrams that make it easier for a new hire to get oriented. Some companies aren't ready to scale their engineering org yet and just want to stay heads-down building their product as fast as possible, which calls for a completely different set of features to highlight. A lot of the conversation comes down to reading what's actually top of mind for that specific person and tailoring both the message and the demo to it.
Trust seems central to convincing someone to adopt something this foundational. How do you actually address it when someone's skeptical?
There are really two kinds of trust at play. One is technical trust — can they trust the product is making good decisions and will behave the way they expect, given how critical a piece of their stack it becomes. The other is business risk — what happens if Encore goes out of business. That second concern was the core motivation for open-sourcing the framework: everything your application actually runs on, if you use Encore, is entirely open source, so you're never held hostage to us, whether we go out of business or you simply decide to migrate away. We've also deliberately invested in making that migration path as seamless as possible.
Doesn't making it easy for customers to leave work against your own recurring revenue?
It might look good for the numbers in the short term to make customers feel stuck, but you end up with people who don't actually want to be there — you stop having to genuinely earn their continued business. If you make it easy for a company to migrate away, that becomes a forcing function on your own product: you have to keep improving and actually listening to feedback, because customers are staying by choice, not because they're trapped. That's a fundamentally more powerful position to build a successful product from than holding a captive user base hostage.