Engineering principles at Barte: less control, more direction

Every growing engineering team hits the same moment: the discussions start repeating themselves. Which stack for the new service? Can this flow live in a no-code tool? Who owns this domain? I need something from another team, but they won’t prioritize it — now what? Each of these conversations sounds reasonable in isolation. The problem is when they come back every week, in different squads, with different outcomes.

There are two classic management answers to this. The first is to centralize control: architecture committees, approval chains, someone who has to say “ok” before any decision. It works up to a point, but it creates bottlenecks and teaches the team to wait instead of deciding. The second is to answer nothing and let each team figure it out. That also works up to a point — until the day you realize you have five stacks, three deploy tools, and business logic scattered across places nobody audits.

At Barte we chose a third path: making the trade-offs explicit. Instead of approving decisions one by one, we decide once, in writing, and let the team decide the rest on their own.

What a principle means to us

A principle, in our vocabulary, is not a poster on the wall. It’s a trade-off the team has already discussed, decided, and documented — so nobody has to revisit the same discussion in a loop.

Two details matter in how we write ours:

A principle describes the path, not today’s snapshot. Our documents make this explicit: what’s written there doesn’t necessarily reflect current reality, but the direction we’re taking from now on. That removes the weight of “but system X isn’t like that yet” and turns the principle into direction, not an audit.

A principle exists to multiply decisions, not to restrict them. An engineering team makes thousands of micro-decisions a day. No management structure can (or should) be part of all of them. What management can do is provide criteria: if the direction is clear and the trade-offs are explicit, each person decides autonomously — and the decisions come out consistent without anyone having to check them one by one.

The metaphor we use internally is the light backpack: every extra technology, every off-standard tool, every dependency between teams is weight in the organization’s backpack. You can carry it, but it costs speed. Principles are how we decide, deliberately, what goes into the backpack.

The three principles we chose

1. Unified stack

We have a standard stack, and it’s the default choice for any new service, application, or component: Kotlin with Spring Boot on the backend; Next.js with TypeScript and our design system on the frontend; AWS as our cloud; Terraform for infrastructure; GitHub Actions for CI/CD; Datadog for observability.

Leaving the stack isn’t forbidden — it’s an exception. It requires a clear technical justification, recorded via RFC, and it comes with a rule that changes the game: whoever chooses to leave owns the cost. The team that adopts something off-standard becomes responsible for operating, maintaining, and supporting it. We don’t introduce new languages, frameworks, or databases out of personal preference.

The rationale is organizational, not technological. A unified stack reduces cognitive load, simplifies hiring and onboarding, lowers the cost of security and operations — and, as we’ll see below, it’s what makes both cross-team collaboration and AI at scale viable. Technology is a means, not an end.

2. No no-code/low-code in the core

We don’t use no-code/low-code tools for core domain and functionality: transactions, balance, settlements, refunds, banking operations. Not even as an MVP.

The yardstick is a single question: “if this breaks or leaks, are the customer or Barte directly affected?” If the answer is yes, it goes to the tech stack. No-code still has its place — institutional sites, non-critical communications, internal support automations — but never in the path of money or customer data.

The rationale: core logic scattered across external tools is hard to version, test, monitor, audit, and operate in production. And MVP is not an excuse — a no-code MVP that touches core domain becomes debt and a security blind spot the minute it hits production. We’d rather prototype and iterate inside our own stack.

3. Inner source: an active internal community

Any team can send PRs to other teams’ repositories. The owning team remains 100% responsible for direction, standards, and operations — and is the one who accepts or rejects contributions. When you need something in another team’s domain and they can’t prioritize it, the path is not waiting in line: it’s contributing.

There’s an important nuance here: inner source is plan B. Plan A is eliminating dependencies between teams — through architecture, domain transfer, or reorganization. Inner source kicks in when that elimination isn’t possible, and it works because the stack is unified: contributing to another team’s repository is easy when their stack is the same as yours.

Principles don’t live alone

A common mistake is treating principles as an isolated document. Ours only work because they lean on an ecosystem that makes them practical — and this is where the pieces connect.

The paved road is the principle turned into tooling. There’s no point declaring “unified stack” if following the standard takes more effort than leaving it. Our paved road flips that equation: an application template that spins up a new service in minutes, Terraform ready to go, independent deploys, observability and security built in. The right standard is also the easiest path — and then nobody needs to be convinced to follow it.

The test suite is what makes autonomy safe. Independent deploys and decentralized decisions only work if there’s an automatic safety net. We’ve written about this: AI made code cheap, but trust is still expensive — and the test suite is what sustains that trust, for humans and for agents.

Observability and incident management close the loop. Autonomy without visibility is abandonment. Every service on the paved road is born instrumented (OpenTelemetry + Datadog, logs correlated with traces), and incident response follows a single process, with clear roles and blameless postmortems. The message to the team is coherent: you have the autonomy to decide and deploy — and you have the tools and the process to operate what you decided.

And AI is the multiplier of all of it. This may be the most strategic consequence of the principles. Coding agents work best within clear boundaries: a predictable stack, consistent standards, automatic validations, trustworthy tests. An agent opening a PR in any Barte repository finds the same structure on every team — same stack, same CI, same quality bar. Explicit principles are, in practice, the context we give the machines. A team with five stacks and logic scattered across no-code tools can’t safely put agents to work; a team with a light backpack can.

What this changes for management

Explicit principles move the management work somewhere else. Instead of approving decisions, management starts maintaining the criteria for decisions — writing, reviewing, and evolving the principles as context changes. The manager stops being an approval bottleneck and becomes an editor of context.

This shows up in concrete ways. Onboarding gets shorter: newcomers read the principles in their first week and understand not just what we use, but why — instead of discovering the rules the hard way, one rejected PR at a time. Technical discussions move up a level: nobody burns a meeting debating which framework to use; the debate happens once, becomes an RFC, becomes a principle. And exceptions become visible: since leaving the standard requires a record, the organization knows exactly where and why it’s carrying extra weight in the backpack.

And there’s an effect that only shows up over time: principles are how we plan the future. Product vision says where Barte is going — new domains, new volumes, new markets. Principles translate that vision into engineering direction: if we know what’s coming, we write today the criteria that will decide well tomorrow. That’s how it played out with AI — the unified stack and the paved road existed before coding agents were a reality, and when they arrived, the house was already in order. Planning the future of engineering, for us, is less about predicting technology and more about making sure tomorrow’s thousand decisions already have criteria.

None of this is static. A principle that can’t be revised becomes dogma, and dogma is just centralized control under another name. The rules of the game: following the principle is free, questioning it is welcome — silently ignoring it is what doesn’t fly.

Conclusion

The question principles answer is not “how do we control what the team does?” but “how do we make sure a thousand decisions a day, made by different people, point in the same direction?”. Our answer: decide the big trade-offs once, in writing, and build the ecosystem — paved road, tests, observability, AI — that makes the chosen path also the easiest one.

Less control, more direction. That’s how we try to scale engineering without scaling bureaucracy.

And if building this kind of thing excites you, come meet Barte: we’re growing the team. Check out the open roles: vagas.barte.io