Backend expertise

Your backend has become slow, fragile, or expensive. You need to evolve an existing system, build a new capability, or simply understand the situation well enough to decide what to do next.

I take on these kinds of problems with your team, from understanding what is happening through to production and hand-over.

My technical background is particularly rooted in Go, backend systems, and production engineering — without forcing a particular technology where the problem calls for something else.

This is probably a good fit if¶

• the problem has a real impact on the product, operations, or the team;
• you need senior technical judgment and autonomy, not simply additional engineering capacity;
• you want a bounded engagement with clear exit criteria;
• your team needs to be able to take the work forward after I leave.

Four ways I can help¶

Focused technical assessment¶

You know you need to act, but not yet in which direction.

The assessment is meant to reduce uncertainty enough to make a decision: understand the facts, identify likely causes, compare options, and recommend a direction.

Depending on the problem, this may involve profiling, metrics and log analysis, benchmarks, an architecture review, or a limited prototype.

At the end, you have:

• the findings;
• a clear picture of the technical situation;
• the available options;
• a reasoned recommendation.

An assessment is not a mandatory first step. If the problem and direction are already clear enough, we can define a delivery phase directly.

Stabilize¶

Your backend has become slow, fragile, expensive, or difficult to operate.

The goal is to bring the situation back under control, not to become the person who permanently compensates for its weaknesses.

The engagement may combine investigation, application changes, performance work, observability, infrastructure, deployment, or architecture where the problem calls for it.

Typical situations include:

• recurring incidents;
• response times or resource consumption drifting over time;
• infrastructure costs that are difficult to understand or control;
• insufficient observability to understand what the system is doing;
• risky deployments or fragile operations.

We agree upfront on observable criteria tied to the problem that will let us call the phase done.

Transform¶

Your system still works, but its architecture or technical choices are starting to limit its evolution.

This may mean migrating a language or platform, progressively replacing a component, restructuring an existing system, carrying out a partial rewrite, or changing an architectural boundary. The goal is to move from one state to another without losing sight of production.

I favor progressive transformations: a first representative vertical slice, usable intermediate states, and explicit decision points rather than a big-bang rewrite.

Typical situations include:

• a technology migration;
• a component that has become difficult to maintain;
• an architecture that slows down delivery;
• technical debt blocking an important change;
• the need to evolve a critical system progressively.

A larger transformation can be split into successive phases. Each should produce a useful outcome and provide a clear point at which to decide what comes next.

Build¶

You need a clearly defined new backend capability.

I mainly take on this kind of work when it requires senior technical judgment, meaningful trade-offs, or strong ownership through to production — not to replace a full product team.

I can start from the need, make the technical choices, build, integrate, deploy, and hand over a component that your team can then maintain and evolve.

I don’t join your team as extra capacity to work through a backlog. We agree on a specific capability to deliver, with clear exit criteria.

Examples include:

• a new backend service;
• a critical integration or business workflow;
• an application infrastructure component;
• an internal tool;
• a new operational capability.

These ranges reflect the kinds of engagements for which bringing in Cabestan generally makes sense. A much smaller need may call for a simpler solution — or may not justify a consulting engagement at all.

How does an engagement work?¶

Learn more about how I work →

How is the price determined?¶

The price is tied to the agreed outcome and scope, not to the time actually spent.

The amounts shown on this page are budget ranges, not an automatic price list. The exact price depends on factors including the state of the system, the expected outcome, production constraints, external dependencies, and the level of risk involved.

When there is too much uncertainty to define a delivery phase responsibly, I start with a focused technical assessment. If the situation is already clear enough, there is no reason to add an assessment simply to produce a proposal.

Selected work¶