Go engineering

# Go maintenance, taken seriously.

Runtime upgrades, dependency repair and scoped security triage for teams with production Go services. Clear scope, reviewable changes and a release path.

## Choose a starting point.

These starting points help us talk through your service, constraints and next steps.

### Maintenance assessment

A bounded investigation of Go versions, dependencies, vulnerability findings and the blockers to a safe upgrade.

What you getA written inventory, prioritised risk list, triaged findings and a phased implementation plan.

What we needThe target support or compliance requirements, build and CI configuration, and relevant scan results.

ScheduleA bounded review; the delivery date is agreed after the repository and questions are scoped.

Out of scopeImplementation, penetration testing and compliance certification.

Let’s talk it through · scope, timing and next steps
[Discuss maintenance assessment](https://coopanio.com/services/?topic=security#enquiry)

### Go upgrade sprint

Upgrade a defined Go service and its build pipeline to the agreed target toolchain.

What you getReviewable changes, CI results, compatibility notes, release instructions and an agreed rollback path.

What we needCurrent and target Go versions, repository access, CI, representative tests and a deployment owner.

ScheduleA scoped implementation sprint; the schedule depends on compatibility blockers and review availability.

Out of scopeAn unbounded multi-service migration or production deployment ownership unless explicitly agreed.

Let’s talk it through · scope, timing and next steps
[Discuss go upgrade sprint](https://coopanio.com/services/?topic=upgrade#enquiry)

### Dependency rescue

Resolve one unsupported, incompatible or vulnerable dependency through removal, repair or replacement.

What you getA documented decision, the agreed integration, regression tests and handover notes.

What we needThe dependency and version, affected usage, licence constraints and a way to test the application.

ScheduleInvestigation first, then implementation against the accepted scope. Upstream review can affect timing.

Out of scopeGuaranteed upstream acceptance or indefinite maintenance of a fork.

Let’s talk it through · scope, timing and next steps
[Discuss dependency rescue](https://coopanio.com/services/?topic=dependency#enquiry)

### Go Care

Scheduled Go maintenance for an agreed estate, with a defined monthly capacity.

What you getDependency and vulnerability triage, prioritised patch work and a record of changes and exceptions.

What we needAn inventory, update policy, access boundaries and agreed reviewers for each service.

ScheduleA recurring monthly arrangement with capacity, review cadence and response windows agreed in writing.

Out of scopeUnlimited work, 24/7 coverage and emergency incident response.

Let’s talk it through · scope, timing and next steps
[Discuss go care](https://coopanio.com/services/?topic=ongoing#enquiry)

Other bounded engineering tasks can be scoped separately. Availability is confirmed before acceptance. No 24/7 support, emergency response or production deployment ownership is included by default.

## From the problem to a release-ready change

- Share the context. Service count, versions, blockers, deadline and any access or compliance constraints.

- Agree the work. A written scope, quote, schedule, acceptance checks and named responsibilities.

- Implement and verify. Reviewable changes, representative tests, vulnerability triage and documented exceptions.

- Hand over the release path. Changes, evidence, release notes and rollback instructions. Deployment stays with your team unless agreed otherwise.

[Read how engagements are agreed](https://coopanio.com/terms/) .



Go service finder

## Tell us what's stuck.

Pick the problem, deadline and size of the Go estate. We'll suggest an appropriate starting point. Use it to start a conversation about your needs.

Nothing is uploaded from this form. An enquiry is prepared in your email client, and you decide whether to send it.


## Questions before an engagement
Who does the work?

Dario Castañé is the founder and technical contact. The people responsible for an engagement are named in its written scope; collaborators and access need to be agreed before work starts.
Can you work with a private repository or under an NDA?

Private repositories are welcome. Ask about an NDA before sharing sensitive details. Confidentiality terms and least-privilege access are agreed before access is granted; never put credentials or private source code in the initial enquiry.
What does “done” mean?

The agreed target toolchain and build configuration are in place, acceptance tests and CI pass, known vulnerability findings are triaged, and release notes and rollback instructions are delivered. A release-ready change is distinct from a verified production rollout.
Who deploys, and what if a release fails?

Deployment ownership, rollout checks and rollback responsibilities are agreed before implementation. By default, your team reviews and deploys the changes. Production rollout and post-release support need an explicit scope.
How much will it cost, and when can you start?

Send the affected service count, current and target versions, blockers and deadline. We confirm fit, availability, fees and a delivery schedule before an engagement is accepted. Prices and dates are quoted for the actual scope.
Can you certify compliance or handle an active incident?

A technical review can supply evidence for your compliance process, but is not a compliance certification or a penetration test. Active incidents should go through your incident-response arrangements; urgent capacity is not guaranteed.
Which languages and time zone do you work in?

Enquiries and engineering discussions can be in English, Catalan or Spanish. Dario is based in Catalonia and works in Europe/Madrid time, observing CET or CEST as appropriate. Meeting and response windows are agreed per engagement.
Why pay when update bots and Go tools exist?

Use them: they are valuable inputs. The work here is resolving compatibility and integration decisions, testing the change in your service, and handing over evidence and a release path. We scope around the remaining engineering work.
