@UncleWally I'll second that. Well worth listening to.

Matt and @Strawman articulated really clearly the reasons why I invest so much time in DCF modelling.

On $RUL, I just wish Matt had more fully addressed the issue of shouldn't they be spending more on developing the platform, rather than buying back shares. The development spend as a % of revenue is meagre compared with great tech companies. (Even though I know that some of the development gets paid for by clients and is expensed and not even counted as development spend,... so the best kind.) To be honest, that is the one issue that is holding me back from taking a bigger position in $RUL.

That's a good point @mikebrisy.

I don't know the answer but perhaps they don't re-invest back into the platform as much as they could because they think they are the only ones in that space (a comment I have heard somewhere recently) and if the the price is right, they have indicated they will sell out - according to Matt.

If that is the case then buying back shares will give a higher return per share. This is pure supposition but it's a possibility.

I hold on SM and IRL.

They did stop a lot of reinvestment about 2 years ago or so after flagging that they had but out every module for a whole life mine and for most type of mines - and through acquisition like AMT (which in hindsight was very astute as one of their best selling, industry leading, product). I do hope they don’t fall behind but they do appear to know what they’re doing and guess it doesn’t really need to adapt all that much once built - perhaps better UI

Very good point @mikebrisy. The "customer pays for development" angle has always been a tricky one for me. The idea is good in theory if your customers have uniform problems and issues to solve and any work you do for one customer can be easily ported across to others. In practice however it is rarely the case, generally you are solving a specific problem for a customer, usually based on a legacy software or process that conflicts with your overarching modules.

I remember many years ago speaking to a former BVS CEO (maybe three CEO's previous now!) who spouted the same benefit. Ultimately they took massive impairments and downgrades as over time they had different customers running completely different software stacks because they had been customised so much.

If done right, having customers fund development is obviously a great feature, but when it's done wrong you lose a lot of the unit economic benefits that software brings.

Was great to get Matt's views on RPM.

And an interesting question raised here. (great insights as always @mikebrisy @Wini @UncleWally )

I'll see if we can line up a chat with management, and maybe get some insight on how they think about development spend.

@Wini I think this is a great point. Another way to put it - would a customer be happy paying for development on a feature that is widely applicable to others?

Having worked for a company that had customers contribute to dev work on a SaaS product, this collaborates with the situation I saw. It happened for custom features, or the product itself was sub-scale where one customer's usage dominated.