Blog

When you run a SaaS solution, it’s a true long-term partnership. In packaged software and in custom offerings, the team writing the code never really “owned” the business. When issues arise, the path to fix may be impacted by questions like “how many hours do we have to eat to do this?” and “are we going to be able to get sign-off with this work-around in place?” In a SaaS offering, every workaround belongs to us. Every sub-optimal solution is something we have to deal with, so there’s a strong incentive to get it right. Take a short cut, and we’ll be stubbing our toes on that same rock over and over again.

The flip side of this is that our clients have real businesses that they need to run. Deadlines are very real, and our job is to help our clients realize their business goals. As a result, we’re very often asking ourselves “how do we meet this business goal while not creating a mountain of technical debt?” Many SaaS providers skirt this question in a clever way. They generate a substantial portion of their revenue from “platform fees” and various “license costs.” In this way, they are insulated from the impact when their solution isn’t meeting the client’s needs. Vindicia’s business agreements with our clients are entirely based on successful revenue captured. When our clients make money, so do we. If they don’t, we don’t. It creates the counter-balance to ensure we understand the urgency of our clients’ business issues and it aligns our business interests with our clients’ interests.

For as long as I’ve run services at Vindicia, I’ve told the team to “fix it like you own it.” The idea has a two components:

• Fix it right, for the long term. We have a large number of clients, so solutions can’t make a mess of the code base.
• Be timely. Our clients have business goals, and we have to embrace those goals – including the pressures to meet deadlines.

To the extent that these ideas are in conflict with one another, that’s where our job gets tricky. We have to work with our clients to get them the fix they need quickly, but also get them to move to the “right” solution as soon as we can fold it into the product in a manner consistent with our architecture and long-term technical goals. The near-term solution might be to provide a custom report, or to build a client-specific code loop. In developing the long-term solution, it needs to work across our entire client base and all of the code and infrastructure that we operate.

To fix an issue, we draw on any resource needed, and the underlying philosophy is that we treat this massive platform like we’re running it just for that one client. How would they fix it if they were running CashBox in house? A custom data extract? A new client library? Is there a short-term way to meet the goal, and if so, how does that interact with our longer-term objectives of growing the business and minimizing technical debt? Whatever the client might do to solve this if they ran it “in house,” we need to examine that path as a key criteria for how we’re going to fix the issue at hand.

In implementing the short term- solution, we make it a point to commit to the long-term fix at the same time we’re formulating any work-around. It’s an incredible team effort involving our support organization, client success managers, product management, engineering, QA, SWAT and operations. It also involves the client, because they’ll also commit to implementing the long-term fix when that becomes available. Experience has shown that the shared sense of urgency makes that trade-off worthwhile for everyone, though. The client meets their near-term business goal and they are usually willing to go back and touch that fix again when the long-term fix is ready. They do it because we made sure they met their near-term goals. We treated their problem like it was our problem, because it was – and we fixed it together. It’s a simple idea, really.