Ruby on Rails maintenance service

We perform routine maintenance for you, so your team can focus on delivering business value

Your problem

There are two types of teams: those who consistently spend time to maintain their application, and those who eventually get bogged down a bit due to neglecting this. The first type of team is doing a good job, but can benefit from offloading this to a specialist in order to free up more of their time to help grow their business. The second type of team deserves better: they should be able to use the latest tools, have automated tests help them prevent bugs, and have security updates be easy to apply. Their business also deserves software with less bugs and all security updates applied.

Maintaining an application is a bit like maintaining a garden: you don’t have to do it every day, but the longer you neglect it the more effort it becomes to restore it to a healthy state. By putting in a little effort each week, you can solve small issues as you find them and become aware of larger things before they become an urgent problem.

Some of the things that could become issues when an application is under-maintained:

Security updates can’t be applied with minimal effort when required due to needing to first update a bunch of other dependencies. This potentially increases your exposure to people exploiting these security vulnerabilities.
Dependency updates don’t get consistently applied. This makes it progressively harder to add new ones and leaves your application and developers without new features and fixes offered by the latest version.
You’ve accumulated enough unreliable/brittle tests that developers assume a failed test run is due to this instead of their own mistakes, resulting in preventable bugs slipping to production.
New features are delivered with low test coverage, resulting in this slowly dropping over time and more bugs slipping to production as a result.
Your CI pipeline is slow and lowers developer productivity, but it never surfaces as an actionable thing to improve.

If you have a team without senior developers, it might be that they lack the experience to realize that these problems will occur.

The solution

The interesting thing is that a lot of these tasks don’t require a lot of in-depth knowledge of your application or business domain. Over 80% of these tasks are generic technical and debugging skills. Any experienced developer could do it, which you can’t say about delivering new features for your business.

What if you could have an experienced full stack developer come in a few hours a week to triage your dependency updates: read the changelog and summarize changes, resolve the simple failures, and maybe create a ticket with context for a major version update that is better to work on later.

What if that developer would keep an eye on your tests, coverage and CI pipeline? They can be your team’s maintenance conscience. In case of issues they can create a ticket to raise awareness and guide you towards solving it. Your developers can look at it when they have time, or you can have an external developer look into it when your team is too busy.

Our offer

We’ll unburden your team by doing routine weekly maintenance for them. We’ll triage dependency updates and solve small issues we encounter while doing this. For things that would require more work we will create a ticket where we document the details of the problem and a rough estimate. Your team can pick these up when they have time, or you can hire us to handle them for you.

Every month we’ll send you a maintenance health report that shows the status of your application and your CI Pipeline, as well as a summary of action items we’ve generated such as a recommendation to reduce wasted time by optimizing your CI Pipeline or that the number of technical debt tickets is growing faster than it’s being reduced.

You can get started in 3 simple steps:

We’ll have a quick introduction meeting to get to know you and your application
We’ll produce an Onboarding Report while auditing your application
We’ll start the Monthly Basic Maintenance Cycle

We’re open and transparent about our process. We don’t do anything your developers could not do. In fact we hope they are currently doing this! By letting us handle maintenance for you, you will benefit from our experience and save yourself time debugging the root cause of issues we’ve solved before. We will save your team at least 10-15 hours per month, which they can use to grow your business.

We’ve performed this service for clients as part of regular engagements and they’ve always been happy with it.

During onboarding we will install tools that measure test coverage and security vulnerabilities, after which we will produce the Onboarding Report. You’ll get a good idea of the maintenance health of your application this way, and will see areas where there is room for improvement.

Our Basic Maintenance Service will get you an average of 4 weekly dependency triage sessions per month plus a monthly maintenance status report. This service will save your engineers 10-15 hours per month and costs only €900 per month.

If you have more than one application, we can accommodate you by offering a discount based on how similar they are. If it takes less effort to maintain a second or third application, it would be dishonest to charge you full price for each of them.

If your application is not being actively developed, we offer a Maintenance Mode Service: instead of weekly updates we perform them monthly. The goal is not to keep your application up-to-date most of the time, but to prevent it from falling behind too much. Less frequent but larger updates fit in with this and reduce the costs this service to only €500 per month.

The Technical Debt Tickets we create during routine maintenance can be handled by us for an additional fee. Because estimates are hard, especially when it comes to interactions of new versions of dependencies with your custom software, we prefer to keep this part simple: based on our initial impression we assign tickets a Small, Medium or Large estimate label, which corresponds with a few hours, a day or two, or a week of work. We try to break down larger tasks into multiple smaller steps to help keep estimates accurate. A good example of this is a Rails upgrade: that always has a preparation, upgrade and cleanup phase that will each have their own subtasks. Our process aims to always make clear what our intention is, what we’re doing and how far along we are. When reality disagrees with an estimate, we can investigate alternatives or decide to proceed with an updated estimate. Communicating openly about this helps us stay in sync.

Without obligations or commitments, we charge €100 per hour for additional work that you sign off on. No commitment comes from two sides: we’ll try to fit your task in when we have time available.

If you have a decent amount of work in your backlog, you can upgrade to our Full Maintenance Service that extends the Basic service with a monthly bundle of committed hours that we can use to work on your Technical Debt tickets. In exchange for your commitment we give you a discounted rate. When you commit at least 20 hours per month, you get a rate of €95 per hour. At 40 hours per month, you get them for €90 per hour. Once the backlog clears up, you can switch back to the Basic Maintenance Service without issues.

We only want clients who are happy with the value they receive. For this reason you are free to cancel the service renewal whenever you want. If you’re not happy with our results, we can even cancel the contract and we’ll waive unpaid invoices when you delete the work we’ve delivered. No cure = no pay.

Recurring monthly fees are invoiced at the start of the month they cover with a 30 day payment term. Other tasks are invoiced the month after they were performed. Listed prices are excluding 21% VAT (when this would apply).

Email us to lower your maintenance burden and become a happy client.

Our maintenance process

We like honesty and transparency, so we’re pretty open about our process. You should know the value you will receive for your money.

Introduction meeting

While we love remote async work, there’s no substitute for seeing a human face when it comes to building up a working relation. This is why we start with a video call (or in person meeting when we happen to be nearby). It might be useful to answer some of the questions below beforehand, but going in blind is not an issue either.

We start with a quick 30-60 minute (video) chat with your application’s lead developer (for their technical perspective) and someone authorized to spend money (for their authority and business perspective). We’ll chat about your application(s) and its role in your organization. The goal is to get a feel for the size and importance of the application, as well as its current state of maintenance. During the chat you can get to know us, which is equally important.

These are the topics we’ll want to discuss in a casual manner. It’s not a pop quiz. A best effort or gut feeling answer is fine for most of them.

What does your application do? (What are its primary responsibilities or business processes)
How important is it to the business? (Does it earn you your money, or is it only used once per month to generate some non-critical reports?)
Does it integrate tightly with other applications or services? (Both internal and external)
Is it being actively developed? If so what’s the team size and experience level? How long have the devs worked on this application? This helps us gauge how much we can rely on the team for judgment calls or question about choices that were made during development.
Do you have a budget for maintenance?
How up-to-date is it currently? Do you have an automated update process?
Do you have an automated test suite that covers everything the business values?
Do you trust these tests blindly? If not, which parts of the application are you nervous about? Do you have the time and knowledge to remedy this?
How long does an average test run take?
Do you have a CI pipeline? If so, which tools do you use?
How/where do you host your application?
Is deployment automated, and which toolchain do you use? If not, what’s your process and how often do you do it? How do you handle rollbacks of bad deploys?
Do you have a staging or acceptance server?
Do you have a system to track production errors/bugs?
How does your PR/code review process work? Do you use PRs? Do you require peer review? Do you require passing CI checks?
What system/workflow do you use for tickets/issues/backlog? Github issues, Jira, Pivotal, etc. Do you work with sprints? Do you have formal releases or do they happen continuously?
Do you track your technical debt?
How well documented is the application/code/domain? Is there a wiki, and is it maintained? Can someone fixing a failing test during maintenance find enough information to grasp the domain concepts and architecture that is used? Do you use Domain Driven Design? Is there a gap between the names used in the codebase and the user side or business domain?
Is there anything else that’s odd or non-standard about the application that’s useful to know for maintenance tasks?

If your application is not yet ready for our service, we can create an Onboarding Roadmap to help establish the steps needed to get there. Your developers can then work on this, or we can help you with it for an additional fee.

Onboarding Report

When we agree to work together, our first task will be to produce an Onboarding Report. This requires us to get your application and its supporting toolchain working, and to extend it with tools to gather useful metrics:

the number of tests, coverage level, brittleness and total runtime: how complete and reliable are your tests?
the total number of dependencies, how many have known security vulnerabilities, how many are up-to-date and how far behind the rest are
add Brakeman and scan for (possible) security vulnerabilities in your application code

This results in the Onboarding Report that gives an overview of these metrics. If there are issues we can create tickets in your tracker to address them. The Onboarding Report measures a baseline of how your application’s metrics looked before we started working together and which areas have room for improvement. Besides delivering the Onboarding Report, we can create a Pull Request (PR) that add our instrumentation tools to your CI Pipeline (if you have one).

Monthly Basic Maintenance Cycle

Once onboard, we’ll start our Monthly Basic Maintenance Cycle: setup Dependabot (or Depfu or whatever you prefer) to provide a few dependency updates to triage each week, so the consistent effort helps us catch you up over time.

We’ll triage each update for you: summarize the changes, solve easy upgrade issues and offer the PR for final review and acceptance by your team so they stay in control. Things which would require too much time/attention will result in a ticket with a description, possible blocking factors, and a rough estimate how much work it appears to be. We tag them with “technical debt” so they are easy to track.

Every month we’ll generate another report like the Onboarding Report, so you can compare the metrics and see how your application is doing. If some of them require action we’ll create tickets.

Any tasks we create can be picked up by your team. Alternatively we can agree to handle them for an additional fee.

We try to focus our mornings on routine maintenance, and use our afternoons as a nice chunk of uninterrupted focus time to work on tasks we agreed to work on.

Additional work

The tasks with larger bits of maintenance work can be done by us. Writing a contract for each ticket would be a lot of overhead, so we will make a clear agreement beforehand where you specify spending limits and have the team prioritize and sign off on tasks we can do for you. If you want to change these spending limits, you can easily change them by sending an email: “from next month, you can spend up to 10 hours on extra tasks signed off by the team”. For larger projects that have a nice list of Technical Debt Tickets, we even give a discounted rate via our Full Maintenance Service.

The easiest way to handle this is to setup a Github Project where we put all Technical Debt Tickets, and setup the following lanes/statuses:

New: an unsorted collection of tickets. Your old tickets go here, and we’ll add new ones as we need to.
Unscheduled: these have been reviewed by us and given information and a rough estimate, but they are not yet planned.
Up next: these have been signed off on by your team, and are ordered by priority: the topmost goes first, then the next, etc.
In progress: this is a ticket we’re working on. It usually connects to a Pull Request that solves it. Basic/routine maintenance tasks enter the flow here.
In review: we’re done with the ticket, so now your team can review it and merge it. They remain in control.
Done: this ticket was completed or cancelled.

If you use another system to track tickets, we’ll setup a similar thing there. The important thing (for us) is that it is clear what work you’ve signed off on for us to do. This is not easy when it’s buried in emails and Slack channels, so having a nice project board keeps it all in one place.

Tools and expectations

Tools we hope to find / will introduce over time:

Automated tests (RSpec/Minitest)
Test coverage, with increasing strictness to encourage discipline (SimpleCov)
Continuous Integration (Github Actions, Semaphore, CircleCI, etc)
Automated Dependency updates (Dependabot, Depfu, etc)
Automated Security updates (Dependabot, Depfu, etc)
Application code security vulnerability analysis (Brakeman)
Basic test improvements (parallel tests, VCR/webmock, anti-brittle test retries)
Production error reporting (Honeybadger, Appsignal, Bugsnag, etc)
Code best practices checking (Rubocop)
Code style consistency rules (Rubocop, Standard.rb, Prettier)

Each tool has a good reason to be used, but of course each application and team is different so the suite of tools we’ll end up using will match your needs.

You are welcome to use our process. If you’d like to offload your burden to us, please email us.