My latest article about highly profitable R&D teams got a lot of attention, and thus, we’re continuing with that subject. We’ll start and cover first aid: how can you quickly stop the bleeding in your already unprofitable software?

Unprofitable Software?

First, I feel this is something we have to tackle. I still come across startup founders who refuse to consider the profitability of their software. They know the startup as a whole isn’t profitable yet and hope to get the profitability eventually, but they fail to look at the product itself and whether it’s a loss maker.

Yes, software is supposed to be about zero-margin or close to it. However, as we’ll list in a second, many startups, especially B2B SaaS ones, set themselves up for failure in their initial rush to get logos.

Contracts

Whereas most B2C startups don’t have to think about this, when you’re selling to businesses, you tend to have more contracts. Initially, hungry startups tend to agree to whatever the client demands in order to seal the deal. That means that these contracts can become shackles weighing down entire R&D teams.

Even if you already have some problematic contracts signed, the important thing is to stop amassing more of them. Review them and consider which limitations are in place that don’t make sense as your company intends to scale successfully:

• Versions: The whole lifecycle of your software is a serious issue. How many versions back do you have to support? How much time will clients have before being required to upgrade to the latest versions? Each version doubles the complexity of testing and maintenance performed.
• Access: Relevant both for whether you’re setting up on-premise solutions or a SaaS product, you sometimes agree to different limitations to how you can use the data gathered. When logs, metrics, and usage data are too limited, that has a direct cost of making product decisions harder and slowing down how fast your organization learns and gets smarter. While sticking to regulation and sensible data use, don’t forget the value this data can have to help your users.
• SLAs: When we’re not clear enough about how issues are triaged and prioritized, along with different SLA promises, you might find your team rushing on a daily basis. That happens when minor issues must be addressed outside the regular development cycle to conform to SLAs.
• Fixing Bugs: There will be bugs. Plenty of them. It’s worse when fixing those bugs requires jumping through hoops just to get the damn hot fix deployed. How easy is it to address a critical issue? Imagine that this happens in the middle of the night, and your team has to stay up till it finishes addressing it. How hard do your contracts make this?
  

Join the Matrix

This issue is somewhat part of contracts, but other times, it just seems to be the natural way of operation for account executives specifically and the company in general. Startups sometimes agree to make things too configurable and adjustable. Any new feature or button that surprises a big client automatically gets a toggle.

The problem is that these tend to accumulate and be very hard to clean up. Thus, many of these pile up until the engineers have to keep in mind a vast testing matrix where every feature (or even different parts of the same feature) can be toggled on and off. Where it’s necessary, please go ahead and use these. However, don’t abuse this ability to shy away from having a coherent product vision with healthy defaults.

Feature toggles are supposed to enable quick development and iteration, not endless configuration crutches.

Premise Permission

As a senior executive in a unicorn told me, offering on-premise deployments could be the biggest mistake companies make. Even if you think you “have” to offer this, think hard and long. Postpone it as much as possible.

Now, if you’ve got to have these available, try to contain the harmful effects it has on your team. This connects to the earlier points around contracts but also to your access to these installations. Can you get some metrics and data out to learn about these use cases regularly, not just when things blow up? Is your team in charge of deployments, or can you make this the client’s responsibility? Each decision here is important.

Magic Numbers

When you’re just getting started, it’s easy to dismiss thoughts about data usage, access, and retention. Same for different usage limits (“People using us too much? Those would be champagne problems!”). Nevertheless, these can also bite you in the behind if you wait too long to address them.

Do you know all those feature comparison sales pages that list “unlimited” for different features? Don’t. Instead, embrace the only place where magic numbers in software engineering make sense and decide on limits, even if you have to make them up. When considering your data retention, consider retaining the right to delete old data and accounts that haven’t been used, etc. You don’t have to implement it, but having that as a possibility certainly is helpful.

Professional Services

You might not think about your company as offering professional services. But try to think about how many features got bumped to the top of the roadmap because a big prospect had inquired about them. Have you changed different behaviors just to make that enterprise whale client run things smoother through procurement?

I’m not dogmatic, and sometimes businesses need to do things to close deals. That said, given that your R&D is probably the biggest cost you have, coupled with the huge price of opportunity costs, exercise this with extreme caution.

Aligning Business and Growth

The last point is to be mindful of the different vectors your clients are likely to grow with time, especially as they are making successful use of your software. Wherever possible, attempt to align these growths with the business model, so you’re not punished for having successful clients.

I’ll provide as an example Substack that (as far as I know) still allows unlimited email list sizes but charges a commission based on your subscription prices. That means that some people have moved huge email lists to them that cost thousands of dollars to maintain in other providers without the intention of ever trying to monetize subscribers. I don’t know if these affect their bottom line, but I know you should be thinking about these.

If I’ve missed anything interesting, please let me know how you tackled this in your company!