Marcus KohlbergHow Later built an event-driven AI matching engine on their own AWS with zero DevOps
Choosing Encore over an established NestJS and Kubernetes stack
Powering the creator economy with AI
Later is a leading social media and influencer marketing platform used by brands and creators worldwide. With over a decade of data on influencer content, performance, and audience demographics, Later has a massive dataset for matching brands with the right creators.
When the company set out to build a new AI-powered influencer matching system, they needed an architecture that could handle high-volume data ingestion, event-driven workflows, and complex AI pipelines. Kyle Chamberlain, the engineer leading the project, evaluated several approaches and landed on Encore as the best fit. Encore's infrastructure SDK let him define cloud primitives like queues and databases directly in his TypeScript code, while Encore Cloud automated all the provisioning and deployment into Later's own AWS account.
Choosing Encore over an established NestJS and Kubernetes stack
Later has an internal operations team with an established infrastructure stack built on Kubernetes and ArgoCD. For any new project, the default expectation was to follow this established approach, but the requirements of the new project called for an approach that would let a small team move fast without waiting on infrastructure processes.
When starting this project, we wanted ephemeral branch deployments like a web app on Vercel. But the system needed queues, event-driven workflows, and long-running processes. Encore gave us all of that packed into the preview environments we wanted.
The pitch was straightforward: Encore is an infrastructure SDK where you declare cloud resources in code, and Encore Cloud automates provisioning and deployment into their existing AWS account. The artifacts are the same cloud primitives (SQS queues, RDS databases, etc.), and the team wouldn't need DevOps support. That case held up despite significant inertia behind established patterns in the org.
Building an AI-powered knowledge graph
The system Kyle built with Encore is a sophisticated AI pipeline for matching brands with influencers. It ingests brand documents, campaign briefs, and content guidelines, then uses LLMs to extract entities and relationships into a knowledge graph. Influencer data from Later's existing stores, spanning over a decade of posts and performance metrics, gets stitched into the same graph.
The architecture is fully event-driven. Document uploads trigger parsing, which triggers entity extraction, which triggers relationship mapping. Each step is defined using Encore's Pub/Sub SDK primitives, which Encore Cloud automatically provisions as SQS queues in AWS, keeping the system decoupled and flexible.
Encore maps really cleanly to event-driven architecture. A document was uploaded, a document was parsed, a new node was created, a new relation was created. We don't always know what we'll want to do in response to these events when they are created, but when we figure it out, it's easy. Just subscribe and add a handler, let encore sort out sending those messages through SQS, retrying, and managing the DLQ.
The graph itself lives in SurrealDB, a multi-model database that unifies graph traversal, vector search, and document storage in one engine, so the relationships Encore's pipeline produces are persisted and queried in a single place.
The matching itself combines vector embeddings, explicit filters, and demographic data into an AI-assisted search experience for Later's account executives. They can refine matches conversationally, save search sessions, and progressively build queries, all powered by the underlying knowledge graph.
The infrastructure that just works
After more than a year of building on Encore, Kyle's consistent experience has been the total absence of friction.
I don't think Encore has ever been the issue. If we have a problem, it's never been an Encore problem. That's about as good of a report as you can want from a tool like this. It just gets out of the way.
That reliability extends to the entire development lifecycle. Local development environments spin up without Docker Compose files or manual configuration. CI pipelines and tests work on the first attempt. And package compatibility has been completely painless, even where other platforms create constant headaches with native dependencies.
Encore's inferred infrastructure has allowed us to move at unprecedented speed. Combine with database branching in Neon, we're able to spin emphermal environments up and down with incredible ease. Stakeholders love preview app URLs, but be warned once you establish this new tier of engineering delivery, your team won't allow you to go back.
I've wasted zero minutes wrestling with package compatibility on Encore. With other platforms, I was arm-wrestling packages to work every single week due to differences in newer JS runtimes. Encore just gives you a Node runtime and everything works the way package authors intended.
The Pub/Sub experience has been a particular highlight. Infrastructure changes that would normally require clicking through the AWS console, copying resource IDs, and managing queues manually are all handled automatically.
Every time I push a Pub/Sub change and see "you've got these SQS queues coming up, and these ones got deleted..." I appreciate it. Without Encore, I'd be doing click-ops in the AWS console, creating queues manually, copying IDs back into my code, making sure I didn't leave unused resources dangling and costing money.
Stability through a year of upgrades
Encore's upgrade experience has been remarkably stable over a full year of production use.
I have a script that updates the Encore packages, regenerates the client, makes a PR, then merges the PR. I've done that all year through patch and minor bumps, and nothing has ever broken. I can't say that about any other package we use.
TypeSafe clients over GraphQL complexity
Later's standard infrastructure stack includes GraphQL. Encore's TypeSafe client generation gave Kyle the same tight API contract without the client-side complexity tax of GraphQL: schema generation, client codegen tooling, Apollo caching complexities, and the ongoing maintenance of keeping everything in sync.
With Encore, you change the endpoint, regenerate the client, done. No need to pay the GraphQL client complexity cost, didn't need to pull the schema into a quilt of client generation tooling. It's all integrated into one tool with reasonable boundaries.
When to reach for Encore
Having built projects across a range of infrastructure approaches, from serverless to Kubernetes to managed platforms, Kyle has a clear perspective on when Encore makes sense.
As soon as you need something beyond stateless API endpoints, maybe long-running processes, dependencies between services, or background workers, that's when Encore's value comes into focus. If, for example, you're starting from a Next.js app on Vercel, you can bolt on queues and caching through various services, but it gets fragmented, expensive, and hard to replicate locally. You can go deep on Terraform, but that doesn't map well to your local dev experience or preview environments. Encore just gives you all of it out of the box.
Results at a glance
- Zero DevOps engineers assigned to the project
- 10+ months in production with zero issues
- Seamless onboarding for new engineers, no infrastructure knowledge required
- A full year of upgrades with zero breakage
- Complex event-driven AI system built and maintained by a very small team
- Seamless local development and CI, no custom Docker Compose setup
Encore's infrastructure SDK and cloud automation platform enabled Later to build a sophisticated AI-powered system with the speed and simplicity of a greenfield project, deployed to their own AWS account. All without writing infrastructure configuration.
Want results like Later? Book a 1:1 intro to see how Encore Cloud can help your team move faster, eliminate DevOps overhead, and stay focused on building great products.
More customer stories
