Everyone their own way
Capyvara has two products and a small, mixed team: developers, design, business people and students early in their careers. Everyone worked their own way, and what decided whether something was "done" was the opinion of whoever built it.
In a team like that, the risk isn't a lack of talent. It's every delivery depending on who remembered to test, who reviewed it and who knew how to ship it.
A standard for every PR
The first step was writing down what until then lived in people's heads. I created the platform's engineering baseline and a mandatory PR template. Every PR now says what changed and why, goes through a checklist for permissions and expected failures, records the tests run with and without permission, and brings its impact and evidence.
Specification before code
Next, I adopted spec-driven development. Every feature starts as a spec with acceptance criteria, which then becomes a plan and a task list. So the work board wouldn't drift away from the spec, I automated publishing those tasks as Trello cards, with assignee, labels and reruns that don't duplicate cards already open. The board started reflecting the spec, not the other way around.
One path to production
I organized the development, staging and production flow through PRs, so nothing reached the customer without going through the test environment. I also made the pipeline comment on the PR itself with the log excerpt and the list of failures when something breaks. That way anyone on the team, including people just starting out, understands what went wrong without having to ask for help.
Before a launch, I wrote a readiness assessment with the product's real state: what was ready, what wasn't, and a day-by-day plan up to the decision to launch or not.
Priorities by criteria
I also standardized how technical debt and product requests are recorded: priority, impact, who it hurts, effort and what to do. With that, the conversation about what comes first became a comparison between cards rather than a contest of who talks loudest. I ran meetings with users and customers and turned their feedback into stories with acceptance criteria, separating interface tweaks from product decisions.
Knowledge outside one head
So the team wouldn't depend on me, I documented QA onboarding, the release process, a product knowledge map and decision records. On the customer side, I wrote the success criteria document with a public sector customer, and the product's success indicators.
What changed
The team now has a shared definition of done, written into the PR template. Deliveries go through a single path to production, with staging in between and an evidence-based launch decision. And planning became traceable, from spec to card and from card to PR.
What I take from it
Good practices only stick when they cost less than skipping them. A checklist in the PR template, a pipeline that explains its own failure and cards generated from the spec worked better than any conversation about discipline.
Leading a small team is, to a large extent, deciding what not to do right now, and leaving that decision written down, with criteria, for everyone to see.