One of the common challenges that technology companies encounter is clients requisition various features and customisations that either the business hasn’t planned for or may not be aligned with the direction the business wants to go in. The problem is startups need cash and growth from clients and typically the kind of clients that request for these customisations tend to be larger and cash to spare. Now, there’s already a red-flag because typically the larger the organisation the longer the payment terms, and in the game of cash flow, payment terms are crucial.
Largest organisations can sometimes look for suppliers that fit the specifications of what they might consider building for themselves in-house, then push the suppling company to customise to fit their specific needs. Generally this is simply a calculation for the larger organisation, pay lots to build from scratch, buy something out of the box, or buy something out of the box and customise. In most cases the clout of a larger organisation means they can push for customisation meaning that the costs are still cheaper the building bespoke, and they get what they want, but usually the startup suffers since theres now a resource suck to cater for an ever-growing list of customisation requests and related bugs.
Theres another 2 scenarios that can result from this customisation trap – first, the larger corporation could put through so much customisation that the startup starts to crumble and it becomes a cheap acquisition option for the large corporation, in this case, the corporation might even have been shadowing the production the whole time, without any intention of acquiring the startup, they’ve simply been buying time to release their own competing solution. Another scenario is the corporation is ‘gunking-up’ the startup as a means of draining resources and slowing it down, in favour of a competing product. These are less common, but worth bearing in mind as nightmare scenarios.
Now, its not very possible, especially at the early stages to say no to customisation (specifically this applies to B2B SaaS), no matter how good your product, its inevitable there will be requests for customisation, so what matters is how you determine what customisation to pursue.
First you need to consider if the request is applicable only to one client or all clients, anything that only applies to one client is less important since its not transferable, therefore it should also cost more to develop since its the opportunity cost of taking development resource away from something that will support multiple client and build a better business, in simple terms if you accept a customisation that is only for one customer, it needs to offset the time-cost if not only the time it takes to product the customisation, but also the loss-time that could have been spent on something else… ie. it needs to be 2x more expensive, this also designed to be a deterrent price to the customer.
Next if the customisation applies to multiple companies, you also need to consider if its a quick fix, a front end fix, or a structural fix – if its quick it shouldn’t be an issue, but with increase complexity there is linear increase in developer cost. The cost should therefore be considered against the impact on future revenues before you commit, in English – if a feature is requested that all companies want, and you can charge more for it… then you should spend a proportional time to develop the feature, how much time is tied to how much business growth, renewal and upsell this new feature can bring. E.g. if the feature means clients are willing to spend 10$ more each month over 20 clients and you can get 5 new clients then the value of that feature is 10 x 20 x 12 + 10 x 5 x 12 – however if the cost exceeds this amount then you need to consider its importance relative to its value.
You should remember the dev complexity and therefore time-cost is exponential to the number of variables – so the more variables you present to a customer the more likely you’ll end up ‘gunking-up’ your dev team, this being said certain variables are controllable, and others are finite, so by categorising requests into the kind ov variables, you can account for how much burden you put on developers, and this will also help you to create pricing bands, allowing for a faster sales cycle. As an example we see this with Spotify versus hubspot versus SAP, with Spotify payment give access to variables that are pre-setup, with hubspot increased monthly payments results on features being made accessible, with SAP the feature is developed around the client. In otherwords the larger the value of the contact, the more willing you can be to accommodate for more complex variables that will take up dev resource, the lower the cost, the more you want to limit variables.
Finally, you also need to ensure that any development the you choose to accept aligns with the wider direction and vision for both the company and product, it doesn’t make sense, even with sufficient customer demand, for you to cater for and build solutions that take the business into a space that it doesn’t want to be.