Why We Began Selling Support and Maintenance Retainers

In the early years of Planet Argon, all of our design and development projects were broken down into short iterations. Prospective clients would approach us with their big ideas, and we'd provide some ballpark estimates to help them determine if they had the budget to make it happen.

🔗 Read 5 Steps For Getting a Better Estimate

We'd then propose an initial discovery phase to help us draft the Product Roadmap with corresponding iteration schedules and cost ranges for each iteration. After each iteration, we'd refine our estimates for the subsequent iterations and make sure we were still on track.

Iterate, iterate, iterate, launch! 🚀

This approach worked great for clients looking to build a Minimum Viable Product (MVP).

This approach didn't work well for clients who also wanted us to provide maintenance and support for Ruby on Rails apps already running in production.

In the scenario where a client's project was already running in production, we opted to build a retainer model that would allow them to reserve time each month with our development (and design) team. This budgeted time could be used to support and tackle those more minor, iterative improvements that production applications regularly need.

The primary goal with a retainer is to Keep The Lights On (KTLO).

We set up a structure where clients could build and prioritize a living Product Backlog at their discretion. At the beginning of each month, they'd reserve a bucket of time that could be used on tasks such as:

• "Add two new fields to form X on page Y."
• "Add e-commerce tracking code to the shopping cart checkout process."
• "Implement A/B testing on landing page X."
• "Export the following data as a CSV for my investor meeting next week."
• "Fix a bug where…"
• "Oh shit, the API is down at 2 AM!!"
• ...etc.

These smaller one-off type requests support issues could be performed against a planned budget without going through our regular iteration-based Statement of Work process.

Simpler for our clients. Simpler for us.

While we knew it would save us a lot of proposal writing, we didn't initially think about how much time this would save our clients who worked within larger organizations.

One client, in particular, called and thanked me for moving them to this model. She said, "I was able to go to my boss and request an annual budget to contract Planet Argon every month. Last year, I had to get approval on over twenty Statement of Work proposals for your team, which required me to sit down and explain all the deliverables would be…twenty times."

One important caveat to this approach was that it required a lot of earned trust and expectation management. With our iteration work, a certain amount of risk was accounted for in our pricing models to protect both parties.

One of the reasons so many agencies sell two-week iterations (or Sprints) is to manage risk. When you provide a client with a list of deliverables with corresponding estimates, the smaller the scope of work, the lower the risk of any of those items opening Pandora's box and blowing the overall project budget.

It was great to know that our retainer model was mutually beneficial. So, we began pitching this model to prospective clients, and within two years, nearly half of our revenue came from secured retainers.

(Update: Retainers currently make up around 70% of our revenue.)

We'd work iteratively for new builds, and for in-production applications, we'd propose a retainer. When a client approached us with a collection of work much larger than what could be accomplished and timely within a retainer, we would still propose a series of short iterations for those deliverables.

We've successfully run these two models in parallel over the years since.

From a business owner perspective, the retainer model drastically increased my confidence that we can weather our seasonal sales cycles.

In a future post, I'll share some additional benefits that we've been able to begin offering our clients within a the retainer model.