Paved Road: how Barte cuts friction and speeds up those who build

Every engineering team that grows runs into the same problem: each squad solving deploy, infrastructure and configuration in its own way. The result is energy spent on repeated decisions (which library to use, how to ship the service, where to store the secret) instead of investing in what actually differentiates the product.

The answer we adopted at Barte has a name: paved road. The idea is simple: offer the easiest, fastest and safest path for day-to-day tasks, without forcing anyone to follow it. Those on the paved road move faster; those who need to step off it can, giving up some conveniences along the way.

And there’s one more reason to start here: the paved road is also the foundation of what we’re building with AI. The same standards and guardrails that speed people up are what let us put autonomous agents to work safely. But that’s a topic for the end of the post.

What is a Paved Road

The term “paved road”, also called the “golden path”, comes from platform engineering and describes the recommended, well-supported way to carry out the most common day-to-day tasks of building software.

In practice, it’s the easiest, fastest and safest way to do something that happens over and over: create a new service, deploy, configure infrastructure, instrument observability. Instead of each person researching, deciding and assembling everything from scratch, they follow a path that already embeds the organization’s best practices.

Three characteristics define the concept:

It’s opinionated. The paved road embeds the choices and standards the company has already validated. It doesn’t ask “which database do you want to use?”: it ships with the recommended answer, because someone already paid the cost of deciding.

It cuts friction. It removes repetitive decisions and unnecessary complexity. The time that would go into configuration and boilerplate goes back to what matters: solving the product problem.

It’s not mandatory. This is the point that causes the most confusion. A paved road is not a cage. If a team needs to step off the path for a legitimate reason, it can. It just gives up some conveniences (ready-made templates, support, automation) and takes on more responsibility. The paved road is the default option, not the only one allowed.

The concept isn’t ours to claim. Netflix popularized the term “paved road”, and Spotify described its “golden paths” as a way to fight fragmentation in the software ecosystem. Barte adapted the idea to its own context, and that’s what the next sections are about.

Why it matters

When an engineering team is small, the lack of a standard doesn’t hurt. There are few people, everyone knows everyone, and you can align on anything in a quick conversation. The problem shows up when the team grows.

Without a paved road, every new service becomes an island. One team picks a stack, another picks a different one. One configures deploy one way, the next does it another. Each of these decisions looks small in isolation, but the cost adds up:

Slow onboarding. Newcomers have to learn not one way of doing things, but several, and figure out the hard way which one applies to which service.

Security and compliance risk. When each service handles secrets, scanning and configuration its own way, guaranteeing a minimum security baseline becomes a manual effort. And what’s manual scales poorly and fails.

Expensive maintenance. Diversity without purpose means more things to maintain, update and fix. Each extra standard is one more surface for problems.

This is exactly Barte’s moment: an engineering team that’s growing and shipping fast. In that scenario, standardizing stops being bureaucracy and becomes leverage: it’s what lets us keep accelerating without every new service adding to the chaos. The paved road is our way of paying that cost once, centrally, so that each team doesn’t have to pay it again.

The principles

Our paved road rests on five principles that work as decision criteria: when we’re about to build or change something on the path, these are the principles we fall back on.

Autonomy. Each team owns the full lifecycle of its service, from code to deploy to operation. That means independent deploys, with no dependency on a central team to ship a change, and the freedom to make technical decisions within the scope of the service. The paved road doesn’t take autonomy away. On the contrary: it gives a reliable path to exercise it safely. As an example, take our monolith (which could be a topic for another post): practically every team ends up pushing changes and deploying. No deploy requires involvement from the infra team or any other team. Whoever is proposing the change has the autonomy to deploy it.

Standardization. Shared templates, conventions over configuration and a single, well-defined stack. The idea is that the right standard is also the easiest path: you don’t have to remember to configure the right thing, because it already comes configured. That way, creativity is left for where it really matters, instead of being spent on repetitive tasks. The template repository already holds every configuration needed to spin up a new application from scratch in minutes. A few of its features: migrations, tests (with TestContainers), coverage, Datadog (logs, traces, metrics, etc.), infrastructure with Terraform (ECS, Lambda, EC2, etc.) and a CI/CD pipeline, among others. As a reminder, our core stack is Kotlin + Spring Boot.

Simplicity. The goal is zero-config for 80% of cases. Fewer layers, more pragmatism. We even have an internal rule of thumb: “if it needs a diagram to explain, it’s too complex”. Complexity is only justified when it pays for itself. The rest is friction in disguise.

Security by default. Security can’t be an optional step at the end. On the paved road it comes built in: mandatory secrets management, automatic security scanning and built-in compliance. Whoever follows the path is secure by default, without having to become a security specialist for it. A real example is the code-scan flow that runs automatically on every new PR (using SonarCloud). On top of that, we have an automatic AI review flow that already looks for potential security gaps in the code.

Developer Experience. All of this exists for a smooth experience: Clone → Code → Push → Deploy. A local environment that actually works and clear, accessible documentation. When the right path is also the most pleasant to walk, people follow it of their own accord. And that’s when standardization no longer needs to be imposed.

How the Paved Road takes shape at Barte

Principles only count when they turn into concrete tooling. At Barte, the paved road is a set of pieces the team uses every day, each one taking care of a stretch of the path. Here’s the map; each piece will become its own post in this series, with the detail of how we built it and why.

Application Template. The starting point for any new service. Instead of assembling the structure from scratch, you start from a template that already comes with the right standards, configuration and integrations. Clone it and start solving the problem, not configuring it.

Terraform. Infrastructure as code, versioned and standardized. Provisioning stops being a manual, error-prone step and starts following the same predictable path for every team.

Deploy. The process of getting code to production independently and safely. This is where team autonomy meets security by default.

Observability. Instrumentation that comes built in, so that understanding what’s happening in production isn’t an extra effort bolted on afterward, but part of the path.

SonarCloud. Code quality, automatically and continuously, integrated into the developer’s flow. In times of AI-assisted development, Sonar became a fundamental piece of static code analysis, aimed at ensuring higher quality in the generated code.

Code Review AI. Using AI to support and speed up code review, keeping the standard without becoming a human bottleneck.

DORA Metrics. The metrics that tell us whether all of this is actually working: deploy frequency, lead time, change failure rate and time to recovery. It’s how we measure whether the path is, in fact, paved.

Each of these pieces has its own story of decisions and trade-offs, and that’s what we’ll open up in the coming posts.

What changes in practice

The result of a well-built paved road doesn’t show up in a single place. It shows up in the speed and the peace of mind of the team as a whole.

A new service goes from zero to live in a fraction of the time, because the template, the infrastructure and the deploy are already solved. New hires become productive faster, since there’s a clear path to follow instead of a collection of exceptions to memorize. And security, observability and quality stop depending on each person’s memory: they come out of the box.

The most important gain, though, is in where the team’s energy ends up going: less on plumbing, more on what differentiates the product. That’s the whole point of the paved road: leave the repetitive work on autopilot so there’s time left for what matters.

Who maintains the Paved Road

Here’s a confession that might surprise you: we don’t have a dedicated platform team. There’s no squad whose job is to take care of the paved road full time.

The path was created and is being maintained by the most senior engineers on the team, in the middle of product work. And that’s a choice, not a limitation we’re waiting to resolve. We believe in lean engineering teams and in growing the paved road as an internal community: those who use the path also help pave it. When someone solves a problem that’s valuable to everyone, that learning flows back into the template, the documentation, the standard.

This has an interesting effect. Since no one is the “exclusive owner” of the path, no one treats it as another team’s black box. The paved road belongs to everyone, and the simplicity rule of thumb helps keep it sustainable even without a full-time team behind it. A path that few people can maintain is, by definition, too complex.

It’s not the right model for every company, and it may change as we grow. But, at our current stage, it’s what keeps the balance between standardization and a lean team.

The Paved Road as a foundation for AI

There’s one more reason, perhaps the most strategic, to invest so much in this path: the paved road is the foundation of what we’re building with AI.

Autonomous agents are only safe within clear boundaries. They need guardrails: predictable standards, consistent environments, automatic validations, built-in security. That’s exactly what a well-built paved road already offers. When the path is standardized, an agent that creates a service, opens a PR or adjusts a configuration operates on known rails, with the same quality and security checks we apply to a human.

In other words: the same effort that paves the path for people is what makes it safe for machines. Without that foundation, “autonomous AI in engineering” would be a risky bet. With it, it becomes a natural extension of what we already do.

How this works in practice, and what we’re already building with agents, is a topic for a future post in the series.

Conclusion

Paved road, for Barte, is as much culture as it is technology: the bet that standardizing well is what gives you the freedom to move fast. It’s how we live Tech Driven in practice, and it’s the foundation on which we build everything from a new service to our first AI agents.

In the next posts of this series we’ll open up each piece of this path from the inside: Application Template, Terraform, Deploy, observability, metrics and more.

And if building this kind of thing excites you, it’s worth getting to know Barte: we’re growing the team. Check out the openings: vagas.barte.io