
I built an expense tracker to try out Encore. It's a small project with Go on the backend with a few REST endpoints, PostgreSQL as the database, and SvelteKit on the frontend, but substantial enough to get a real feel for the framework. Here's what I found along the way.
I've been wanting to try Encore for a while now. The pitch sounded interesting: a backend framework with infrastructure built right in. But I was skeptical. How much does it actually save you, versus just adding another abstraction layer on top of things you'd set up yourself anyway?
So I built something real: a personal expense tracker with an Encore Go backend and a SvelteKit frontend. Here's what I actually found.
Full source on GitHub: Adisudirta/expense-tracker. Backend in Encore (Go), frontend in SvelteKit + TypeScript.
The Stack
What I Actually Liked
- Database, zero config. No Docker Compose, no connection string wrangling. Define migrations, run the app.
- Deployment out of the box. Encore handles provisioning and deployment for you. No extra configuration files to write, no separate tools to set up.
- Auto generated API client. One command generates a fully-typed client for your frontend. Done.
- Simple monorepo. Frontend and backend live together, without the usual Nx / Turborepo ceremony.
No Database Setup, No Deployment Headaches
This was the first thing that genuinely impressed me. Normally when I start a backend project, there's a setup tax before I write a single line of actual app logic: spin up Postgres locally, write a Docker Compose file, figure out how environment variables flow between dev, staging, and production.
With Encore, I imported encore.dev/storage/sqldb, declared my database, and dropped a migration file into the migrations/ folder. That's it. Encore provisioned Postgres locally and ran the migration automatically when I started the dev server. No fuss.
The same story applies to deployment. Encore Cloud takes care of infrastructure provisioning. You push, it deploys. I didn't write a single line of CI/CD YAML or a Dockerfile for this project. That felt almost suspicious at first, but it just worked.
The Frontend API Client Generator is a Genuine Time Saver
This is probably my favourite feature for full-stack development. One of the most tedious parts of building frontends is keeping your TypeScript types in sync with whatever the backend returns. You write the API, then you write the types, then you write the fetch wrapper, then you update all of it whenever the API changes. It's mechanical work that doesn't need to exist.
Encore has a command that generates a fully typed client from your live API:
Run that once, and your frontend gets a typed client that knows about every endpoint, every request shape, and every response type, without you writing any of it manually. When the backend changes, you regenerate. That's the whole workflow.
For the expense tracker, this meant I could focus entirely on the SvelteKit UI without ever worrying about whether api.ts was drifting out of sync with the Go backend.
Simple Monorepo, Without the Tooling Overhead
I wanted to keep the frontend and backend in one repository. A monorepo is just more convenient when you're working on both sides at the same time.
Encore actually supports a few different ways to structure this. If your project grows and you need shared packages between frontend and backend, Encore has official integration guides for both Turborepo and Nx. Both let you share code across your frontend and backend with proper build pipelines.
But for a project like this, you don't need any of that. The simple monorepo approach is just putting your frontend and backend in separate folders under the same repo. No extra tooling, no configuration files. Encore is not opinionated about it either way, which I appreciated.
For the expense tracker, the simple setup was more than enough. Frontend in /frontend, backend in /backend, one Git repo. Done.
Clean and Opinionated in a Good Way
Encore is opinionated. You define APIs with Encore API annotations, you use structured errors following Encore's conventions, and you follow the directory-as-service structure. You don't have a lot of choices to make about how to structure things.
I love opinionated frameworks, and this one hit the right level. The conventions exist where they genuinely save you decisions (infrastructure, error handling, API shape), not in places where you'd want flexibility (business logic, response design).
The best part of an opinionated framework is you don’t need to think about the stuff you don't have to think about anymore (folder structure, code convention, etc) you just need to focus with the product. Encore gets this ratio right.
The local dev dashboard is also a nice bonus. You get distributed tracing and an API explorer at localhost:9400 for free. It's the kind of thing you'd normally set up yourself after getting annoyed at blind debugging for the third time.
A Few Things to Be Aware Of
It's not all frictionless. Encore's abstractions mean you're in their ecosystem. The database is provisioned by Encore, the deployment goes through Encore Cloud. If you need to eject later and run everything yourself, that's work. That trade-off is worth it for most projects, but it's worth knowing upfront.
The client generator is also a one-way tool. You still need to think about versioning your API properly if the frontend and backend don't always deploy together. Nothing new there, but Encore doesn't solve that problem for you.
Would I Use It Again?
Yes. For projects where I control both the backend and frontend, Encore removes a real amount of setup and maintenance work without taking away meaningful control. The generated client alone saves hours across a project's lifetime.
If you're curious, the full source is at github.com/Adisudirta/expense-tracker. It's a small project, but it covers the full loop: database migrations, typed REST endpoints, generated frontend client, and a working SvelteKit UI. A decent starting point if you want to see what Encore actually looks like in practice.

