Customer Sponsored Features (CSF)

Since 1985 Maintenance Connection Canada and its predecessor (owned by the same owners) have offered Customer Sponsored Features. These are features that customers either fully or partially pay for the original development and normally do not pay for ongoing maintenance other than to pay the same amount of SMA that other customers with the same product with the same feature set pay.

Sometimes when we do CSF the customer is interested a subset of the feature(s). When we do this we look at 'how should this be added so it makes sense for a wide group of people and so that the sponsoring company will not have to pay for custom/ongoing maintenance.'

Since 1985 the owners of Maintenance Connection Canada have been primarily involved with Enterprise product development. This means we create products that can be used by corporations for a variety of purposes ¹. Some of these products have been built 'for' a company for them to resell and maintain, most we build ourselves for resale. Our philosophy as much as possible has been to build features as flexible as possible to give as many companies as possible the tools they need. This means that no one customer is likely to want 'every' feature, and we typically try to build in options to 'turn off' features that specific customers don't want. Since each product is sold 100's or 1000's of times, individual customers only have to pay less than 1% of the development costs, the extra benefit is that they get far more 'features' they want than they would ever be willing to pay for, the downside is they get some features they have no interest in and the product is not 'customized' for their exact needs.

To minimize the downsides even more, we offer two additional options: Customer Sponsored Features and Custom Development. This allows customers to get the base product for a very low cost and then only pay for those features that are not part of the base product.

How do CSF differ from 'Custom Development' and 'Normal Development'?

Custom development typically is done in a way that only the company paying for the feature gets it. It will either be installed separately or it will be 'flagged' so only that customer gets it. CSF are typically made available in whole or in part to other customers, the fees for them will be dependent on what products they own and how we decide to package them. Normal development is, well, what we normally do! The following table gives a high level comparison between the 3 ways we do development.

Maintenance Connection Inc (MC-US) now offers a similar option

In Oct. 2017 Accruent told us they were going to offer a similar program, we understand (2026) they are still doing it, in early 2026 we were told their rates are $700/hr USD, ours are considerably lower. They call theirs 'ABD', Accelerated Base Development. For details of how they do it, contact them, it is similar to what we do with CSF.

Accruent would typically do ABD for the MC software (though we occasionally have done work for MC software such as when we added partial HTTPS support in 2015, full HTTPS support in 2016 and again to their next release in 2017 and finally to their 8.2 release in 2018 – subsequently they added full HTTPS and so we no longer do this for MC), we have done several custom pages through the years.

We don't hide from the truth

This document talks about a subject that almost every software company in the world does, even Microsoft and Apple, but almost all of them are embarrassed to talk about it or admit it publicly.

How do we decide what features to add 'next'?

Several ways:

If we have a specific large sale that cannot be made without that feature, we consider whether it is worth adding. About 15% of the time our answer is 'yes', the other 85% the answer is 'no', but sometimes customers then decide to ask us to do it as a CSV or Custom.

If we have the same feature asked for by many customers, we make adding that feature a higher priority, and when it gets done will depend on many factors including 'How hard would it be to add it now vs.. if we wait for blah to be done first.'

Industries/Sales opportunities. If we feel there is a segment of the market that we can't help with our current product, but if we added 'such and such' features, then they would be a market we could go after then that is a reason for doing it. Our GIS Hub for example allowed us to more readily obtain Municipal customers. (Funny thing about that feature: While it convinced customers to buy our other software – knowing that the GIS Hub was available – very few have actually bought the GIS Hub. It is like a similar product the two owners built years ago in a different company they owned together: a Cemetery product for municipalities. Very few bought it, but several customers bought the main package because we had the cemetery product, and a dozen others, if and when they ever needed it.)

And then there are sponsors. Sponsors are companies that want a feature badly enough that are willing to pay to have that feature added or added 'sooner'. That is what this document is about.

Sponsors:

About 1% of the features in MCe are there because of what we call sponsors. A sponsor is someone who typically wants a feature so much that they are willing to pay for it to be put into the product 'now'.

So how do you sponsor?

So for example, if you wanted to sponsor optimistic locking we could talk about that.

We work out a budget with them (usually a fixed price quote) then if approved, we build the feature into the product. Our price depends on many factors – obviously the amount of work is one and the more work, the higher the cost, on the other hand, if the feature has value for a lot of customers then the quote comes down. For example, recently we did a large job which we only charged the customer 10% of the total project – because there were some other things we were planning on building anyway that needed to be built for that feature, and we wanted it for all customers. Other times, when it is truly custom (we see no opportunity to resell) that we bill 100% of the costs, though at that extreme level we usually do it as custom development. Typically we come in around the 66% where customers pay 66% and we fund the other 33% - and when these projects go 'over budget' as they usually do because we come up with great little improvements we decide to add, unless negotiated ahead of time, we handle all the over budget costs.

Why would anyone pay for a feature that will likely be added in the next year or two? Or that someone else might sponsor?

Simple – they want it now and it is worth it to them.

If it isn't important enough for you, just wait and let someone else sponsor it, or wait until we just naturally add it to the product – it will cost you less (just licensing fees) that may or may be free (an upgrade to the product you already have a license for.)

If you don't need it today, but will at some point in the future, talk to us about the costs and time we need to build it, then when it gets closer to you needing it, talk to us again. Or give us lots of warning, we will usually quote a lower price if the deliverable date is much further out because it can then be built with spare resources when they have nothing of high priority to do.

Why would anyone pay more for ONE feature than they paid for the entire product?

Why would anyone pay $10,000 or $50,000 or $100,000 to sponsor a feature when they only paid $10,000 to buy the whole product in the first place? As one person said 'if I'm going to pay $50,000 for that feature, I'm going to go have my IT department build a product and not use yours'.

Again, simple – a product like MCe costs millions of dollars to develop to the level of sophistication it is today. The cost of buying a copy is insignificant compared to the cost of developing the product. So individual features cost a lot of money to add them.

So yes, you could go and build the product yourself.

Interesting side note: The customer that said they were going to have their IT department build it instead of paying us $50K, ended up deciding that it was much cheaper to pay $50K to have the feature added to MCe than for them to build the product for themselves, their IT department gave them a budget of over 1 million to write the product plus 100K/year for maintenance, and their IT department told them "and we can't give you the offline functionality or (list of features to be cut - more than 75% of our product) in that budget" and their IT department promised to deliver it 'in about 4 years'.

AND: The reason it was so cheap (just over 1 Million) was because they would have been able to customize it for themselves and not put in all the features that 'other' people need – a package has to think of 1000's of users, not one set.

It is the same reason that some people will get a 'free' copy of Linux and then pay RedHat $8K/year for 'standard' support per server plus additional for special services they want. One might ask – why would you PAY anything for free software? And the answer is because it is cost effective. It's also the same reason some high-profile cities in Europe have stopped (2017) using Linux/Libre Office and moved back to Windows/Office – the cost of the free software was way too high for them.

Note: I'm not making a slam against Linux. We use Linux. This author has used Unix before that for years. There are times that free software is better. There are times that, while not better, free software is more cost effective. But there are also times when free software costs too much. The point of all this is that price of software and the cost of specific features has no correlation, and you need to decide based on the value it is to you.

How do you become a sponsor?

So. If you have a feature you want and would like to be a sponsor – talk to us, we'll discuss pricing/feature options and then you can decide. We promise – no high-pressure sales tactics and no obligation. We really are easy to talk to about these things even if you don't like the reality of the cost.

Who do we sponsor?

Not only do we accept feature sponsors, but we have paid money to sponsor a couple different open source projects to add specific features and functionality for us! Back in the 1980's one of the owners of this company agreed to pay Microsoft to add a feature to their Pascal and FORTRAN compilers (Yes they had a Pascal and FORTRAN compiler back then².)

So why would we pay to have features in an open source (free) product? Exactly the same reasons as above.

We know we have some great programmers on our team and we are proud of it. But that doesn't mean we can build every product we use – and often it is cheaper and/or better for us to pay someone to add the functionality than for us to do it ourselves.

Sometimes we contribute (well, several times a year) to open source projects (we write the code and provide it free for everyone to use.)

But in other cases, we pay the experts in that product to add the features we want. So we practice what we preach.