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 get
A written inventory, prioritised risk list, triaged findings and a phased implementation plan.
What we need
The target support or compliance requirements, build and CI configuration, and relevant scan results.
Schedule
A bounded review; the delivery date is agreed after the repository and questions are scoped.
Out of scope
Implementation, penetration testing and compliance certification.
Let’s talk it through · scope, timing and next steps
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.
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.