Whose Name Is on the Pull Request

Founding UP2CLOUD in 2022 came out of a pattern I had seen from the inside at every mid-size company I had worked for: they needed someone with a decade-plus of architecture decisions behind them, but only for a defined stretch, not for good. Hiring a full-time principal architect is hard to justify when the backlog of hard problems is six months deep, not permanent. Handing the platform to a large consultancy solves the staffing problem, but often means the people who scoped the work are not the people doing it. What most companies needed, it turned out, was judgment on tap: senior enough to be trusted near production, temporary enough to make financial sense.

The first weeks of an embedded engagement look nothing like the discovery workshop some clients expect. I ask for read access before I ask for a meeting: the infrastructure-as-code repos, the billing exports, the incident channel, whatever passes for a runbook. I sit quietly in standups. I want to see what breaks on an ordinary Tuesday, not what the roadmap slide promises for next quarter. Clients used to large consultancies sometimes wait for a findings deck that never comes. Instead they get someone cross-referencing the Terraform state against the cloud bill, because those two documents tell different, sometimes contradictory stories about the same infrastructure, and the gap between them is usually where the real problems live.

The difference between advising and embedding shows up in whose name is on the pull request. An advisor reviews an architecture and hands back a recommendation; the client's team owns whatever happens next, and if it stalls, the advisor has already moved on to the next engagement. Embedding means I open the ticket, write the module, sit through the review comments, and I am still reachable when the change I proposed causes a problem three weeks later. That changes what I am willing to propose. Recommending a rewrite is easy when someone else has to live with it. It is a different decision when I am the one debugging it against the client's own SLA at two in the morning.

None of this is free, and I have stopped pretending otherwise. Ramp-up time is real: the first month of any engagement runs slower than clients want, because understanding why a system was built a certain way takes longer than reading its diagram. Trust builds the way it does for any new hire, through small correct calls before anyone lets you near anything that matters, except there is less time to earn it, since the engagement itself has an end date. Working from Vila Real for clients in Spain, the Netherlands, the UK, Brazil, and the US adds its own cost: a two-hour overlap window with a team in Sao Paulo, an 8am standup for one client and a midnight change window for another. The week gets built around whoever has the least overlap with me, not the other way around.

What makes the model work is specificity, not flexibility. Companies rarely need generic cloud advice; they need someone who has already made a particular kind of mistake (a multi-account billing setup nobody can reconcile, a shared Kubernetes cluster where teams do not trust each other's workloads, a schema that cannot absorb next quarter's data volume) and can recognize it faster the second time. Where it does not fit is anywhere that needs a person in the building every day for years, accumulating the institutional memory a full-time employee builds by default. I have learned to say so plainly when what a client needs is a hire, not a consultant of any kind. The engagements that go well are the ones where both sides were honest, from week one, about which of those two things they actually needed.