A fourteen-day free trial ain’t gonna cut it
keygen.sh
keygen.sh
My general use case is to download and test software to use it a single time, for some random new task I only need that day. To use the software for 5 minutes.
Then three months later, oh it turns out I need to do that thing again, or test it out in a new way. It says the trial has expired, even though I only used it for 5 minutes. And I'm not going to pay $$$ just to use it for another 5 minutes and possibly never again.
I don't understand why x-day free trials haven't been replaced with usage-based free trials. E.g. whether it's exporting a final result 20 times, or running a filter 50 times, or processing 100 input files, or whatever metric makes sense for the particular product. Or heck, keep it a 14-day free trial but count the days individually -- so if I use it on May 2 and then on May 15, that's only two days.
The idea that, as a consumer, I'm going to sit down and fully evaluate a piece of software over the course of 7/14/30 consecutive days to then make a purchasing decision is bizarre.
Could you elaborate how?
Admittedly I don't play browser games, but is it as the parent comment says, trials in browser games are usage-based?
In principle yes. That's because you want your players to be hooked before you first present them with the prospect to pay for an advantage. So you ensure a specific action is ingrained in muscle memory before it requires payment.
Your debug gems would recharge after watching a short ad.
They want you to pay for it, don't they?
What I do think would be worth it is micropayments, so for each usage you will pay just $0.2 or so. Unfortunately such a payment scheme is not practical under current Visa/Mastercard system.
No offense, but micropayments have to be the most often suggested non-solution to any problem since the "402 Payment required" code was added to the HTTP spec
So if you first play with interface for few days, but end up not attempting to write more of your great next novel for two months because you were swamped with real life, you can come back and there's still most of the trial left.
After 30 days of ACTUALLY using it (days which are sometimes few and far between, and sometimes more closely spaced) is really a point at which, yes, it's justified to purchase, showing that it has been "the tool of choice" so many times, and likely to be so into the foreseeable near to mid future, too.
The trial is critical to a) proving that it does the useful things, b) determining that that it does said specific things better than the alternatives for some relevant definition of better, and c) giving enough of a chance to really learn it well enough to make an informed decision.
The free period builds tremendous goodwill, and is a really sane and "nice to the community" choice for a tool that might get used occasionally. It shows the confidence that the market really is there for it in general. People who can/do reap value from it on an ongoing basis will convert.
The current SaaS model is like going to the store and you can only buy 5 gallons of butter or milk and you have one week to use it. It "feels" like most of your money is being "wasted". At least that's my perception.
Just because you offer a 7 day trial and I had time today to try it out a bit, doesn't mean I'll necessarily have any time at all over the next 6 days to finish evaluating it. Life and other work priorities happen.
Also, the app is self-hosted, so part of the trial benefit is that users can test the installation process, which is usually the biggest push-back against self-hosting.
I wonder if that might fit the average pattern of a casual stats user a bit better (only actually checking the data when asked by the manager) to keep them hooked for a much longer 'wall clock' time and get them to eventually convert (I've been depending on this for half a year now)
After reading more of those comments, I am still unsure what's the way to go. Maybe simply keep the trial but make it 30 days instead of 14 days.
The problem with premium features, is that I would then need a free version of the product. But I don't want to provide a free version without support, as it's a self-hosted product.
A lot of companies are firmly on the evil track, looking for any dark pattern that makes the numbers go up, sadly. Good on you for not being there.
In practice, because it's self-hosted, "cracking" might be an issue. Customers might edit the files that affect the retention, for example. Maybe most customers won't do it, but I don't know. This also feels a bit like I would have to implement some "DRM", which I really don't want.
Now that you mentioned it, maybe a better trial would be a freemium model, where I can serve a different version for free that only has some features. The problem with this, is that the customer won't get all the benefits of using the product, so they might not like it enough to upgrade to the full version.
It's an analytics platform, so I could offer just basic stats for free and for premium all the other features (segments, heatmaps, recordings, A/B tests, AI integration, etc.). This could work as a good marketing technique for the top of the funnel, but then customers would still probably want to trial the pro features, so I am stuck with the same problem as before.
I know everyone complains about Adobe's switch to subscription, but it would fit the model you'd want where you could pay for a month of usage and then turn it back off.
Yes, exactly.
The parent comment says they are not going to pay to use it for another 5 minutes. So if it were usage-based, would they pay to use it for the 21st times, after they run out the 20 free uses?
And they only use it once per three months. So the 21st use is 5 years later. Will the software still be maintined by the time? Will the dev still exist? Will the problem itself still exist?
That was my point. If I'm using something for only the 2nd time, then statistically it's very unknown whether I'll ever use a 3rd time. If I paid for it now, there's a good chance I'd be throwing away my money.
Whereas if I've used something 20 times, then it's extremely likely I'll be using it another 20, 50, 100, or 1,000 times. It's clearly worth paying for after 20 times.
In your example above (needing it every 3 months) it would take over 5 years to reach that point.
I'm going to guess that within those 5 years it's likely that the developer would have released a new major release (with a new trial period), or that you would have reinstalled your OS (resetting the trial timer), or that you would have gotten a new computer...
In other words, you'd never pay for the software.
> I would pay for it *by* the 21st time.
By the 21st time != the 21st time.
By the 21st time == at some point prior to the 21st time. Possibly the 5th or 6th time. Maybe the 10th time. Maybe the 3rd time.
That wasn't my example. It was 3 months between the first and second times.
In my experience, your need for a tool often increases gradually. You have a one-off project that needs a tool briefly, then a couple of projects a few months later you need to try it more, then it becomes a regular thing.
It's pretty rare that I go from never needing a tool to needing it constantly as an instant switch. Which is the only scenario where 7/14/30-day trials make sense.
Even with large relationships, they refuse to provide utilization metrics. So our team has to implement obnoxious processes to validate your use, or pay 15-25% more than we need to.
Then that's a terrible business model.
As a business, you want both customers to come back.
If a contiguous time-based trial model results in losing half your potential customers, while a usage-based trial model results in keeping all potential customers, then the contiguous time-based trial is objectively terrible.
So it doesn't demonstrate the usefulness at all.
Maybe its still better to let them get a long free trial so they tell their friends about it, I dunno. Not a marketer, but it struck me as kind of disingenuous that if you came back to a tool after 3 months where you know you need to use it, they still don't want to pay.
A time-based trial records the date you started to use it somewhere.
A usage-based trial records the number of times you've done something somewhere.
I can't see why there would be any difference in reliability. The mechanism of recording and checking some value is identical.
So my point stands. There's no difference in reliability.
The trial state isn't like a cassette tape that degrades in quality each time you record over it!
A downside of this is that if you don’t choose the right metric, people might burn through a lot of their uses due to mistakes. Like, to use your input files example, imagine someone accidentally selects a huge directory with more than 100 files and then end up with no free uses left.
Some of this also comes down to overall UX design too, of course.
I have a lower tier that users can move to which is an effective filter to see who really wants to move forward, since our set up & initial support costs are relatively high also on trials. So that works well, even if we make a loss on smaller tiers it's a sign of commitment.
I.e. too short to actually be able to try it is a problem. How long "too short" is varies a lot based on what it is you're selling. Too short to be able to try multiple times may actually be a positive for total sales though, particularly in the consumer software space. As always the answer is "test and see what changes your sales" but that not much does it this way is more likely a hint it doesn't execute well with most models rather than nobody is trying it.
Not really. In my experience, I learned only a tiny percentage of the tool -- like how to run a noise reduction filter and nothing else. I know that one thing worked the one time for that one file, but not for other files with different types of noise. And I didn't even remember it -- I googled "noise reduction software" again, discovered the top link was purple, and only then remembered I'd already installed it on my system and forgotten its name. I started it up and it says I can't use it anymore because the trial expired.
I might have a whole bunch of clips I need to noise reduce now, maybe it's going to become a regular thing at this point, but I can only test with competitors' software now...
Often it's an investment in your life to free up time. You can always get and earn more money, but it's impossible to add more time to your life.
I agree not everything has to be a SaaS though, some are better as usage based, or a basic fee plus usage/overage.
> The idea that, as a consumer, I'm going to sit down and fully evaluate a piece of software over the course of 7/14/30 consecutive days to then make a purchasing decision is bizarre.
Maybe it’s my past life as a software reviewer (and current life as someone frequently asked about my assessment/opinion on apps), but for consumer software (SaaS, especially for business like what OP article is about, I think is different), I really don’t think this is that bizarre.
To me, a trial is really instructive because if I’m finding myself opening or using an app frequently during the trial, that’s a good indicator I’ll get value out of the application. Similarly, if I did a trial in January for one task, then came back to do that same task again in May and the trial is expired, it’s a good way for me to evaluate if it makes sense for me to buy a license or not. There are some programs I use two or three times a year that I purchase because it is useful enough for that one task, but there are others that I use infrequently enough to try to seek out other options. A time-based trial, for me, is a good forcing function to determine if I’m actually going to use the program.
I wouldn't be quick to judge either way.
That is very strange.
> https://tailscale.com/pricing
I have genuinely deployed tailscale in paying locations on basis of my really positive experience on the "Personal" plan, which is effectively almost the whole product for up to three users/100 devices, for free.
I don't think there is a universally right answer for all products/services on this question though.
Why? They couldn’t market the obfuscator, so they were winding it down. People didn’t want a license for something they used for ten minutes four times a year.
(We did later hire an intern to fix bugs in the obfuscator. The app was constrained to a specific JAR size, and those gave us enough headroom for about another dozen features. And I made a change late in the project that got me space for two more, via suffix sorting the constant pool instead of prefix sorting it).
It seems you're very focused on what people "oughta" pay for. But what matters is simply what people do pay for. You tell this story, but it seems very inconsistent with my experience or my understanding of pricing theory.
You can die from exposure.
I don’t know who the “you” is referring to. All I said was that in my personal experience, there have been occasions (not frequent, but it has happened) where I’ll buy a perpetual license to something for a task I use a few times a year. Because the $20 or whatever the license cost was worth the time I saved. In most cases, what I said was that if I didn’t use a piece of software after the trial expired, that was a good forcing function to figure out if it was something I find value in or not. And in most cases, the answer is going to be “I don’t need to buy this.”
I’m not at all focused on what people oughta pay for so I don’t know where you are misreading this.
I also said that for business and SaaS options like the OP article is about, things are completely different (your Copilot example). The comment I replied to was about consumer software trials and how they don’t think time limits make sense. I happen to disagree.
That's why they want that model. Complaints like the GP's are just a thin veil over being too cheap to pay for the software they use. You can see it in the other responses to your comment.
Let's say, you sell your software as a single-version perpetual license. You sell it for 150$. A typical user uses it 8 hours a month. After a year, that's 96 hours. So they spend less than 2$ per hour (I'm rounding in the seller's favor.) So using it for 5 minutes, 1/12h, is less than 25 cents. (Again rounding up in the seller's favor.)
Is this about not giving away 25 cents?
This is where SaaS wins over, but even there, the overhead, both for sellers and users, of managing payment for people who want to do one-shot work is never going to be worth it.
Flip that. I find most people do the second thing first. If what I'm doing in the software takes 5 minutes, chances are I can find something else out there that will do the same thing for free as well. Sometimes the same software lets you trial it again because it's been so long. And so all the additional features you'd review them for amount to nothing when I'm just using them to remove the background in my picture.
But here is the bigger issue.
> it’s a good way for me to evaluate if it makes sense for me to buy a license or not
It's a horrible way for me to evaluate licensing. Why? Because, I probably want to get on with whatever task should only take 5 minutes and do something else. I don't want to spend time evaluating licensing and determine the cost benefits analysis of this software purchase (which more and more tends toward a monthly/yearly fee).
I want to do the 5 minute thing and move on, and I will spend more time searching for another free solution than pay.
You want to get me to pay you? Make that 5 minutes showcase the things I did't know I needed.
And yes, if you have the only thing that can do the thing I'm looking to do, sure. But, a monopoly isn't exactly what we are talking about here.
But that's exactly what you described yourself as doing. You downloaded the software, used it, found that it satisfied your needs, and were familiar enough with the software to recognize that you needed it again three months later.
The real bizarre thing is that someone can blame the software provider for giving away free use of their software, or for "only" allowing them to use it for 30 days for free.
Honestly, I don't understand what model would actually satisfy you while also leaving a window for the software developer to get paid. If someone gave you 14 separate days to run a trial and you utilized the software on the same 3 month schedule, you'd have over 3 years to "evaluate" the software without paying a dime.
> The idea that, as a consumer, I'm going to sit down and fully evaluate a piece of software over the course of 7/14/30 consecutive days to then make a purchasing decision is bizarre.
I don't understand this complaint, either. You already used the software, saw that it solved your problems, and then knew it well enough to know that you needed it again 3 months later. What more do you want? A full year to think about it while it solves your problems?
Would you prefer if the software was usable in "trial" mode indefinitely, but you couldn't actually output anything (save files, get non-watermarked output) until you purchased it? That's the only alternative I can think of that would help you try the software longer, but then you would be forced to pay on the very first use in your example above. That actually leaves you worse off, not better.
This whole conversation reminds me of why it's so much easier to deal with B2B and Enterprise software: With cheap consumer software, you get people who will complain to the ends of the earth about your $20 software or jump through hoops to avoid paying less than the cost of a couple drinks to purchase software that clearly solves their needs.
A 14-day (or 7, or 30 day) trial is actually perfect for this situation.
But you can't make everyone happy. If someone is starting the trial and then not using the software for a week or month, that's their mistake.
There was a time when nagware software was popular: You got to use it for free, but it would nag you with a popup or delay every once in a while asking you to purchase it. You can still occasionally find software with this model, but most developers quickly learned that the more leeway you give the free trial users, the less likely they are to buy it.
Yes, you can probably make more by adding more pressure than nagware did. But you’re doing it at the expense of being pro-user. I do think it’s reasonable to be less friendly than that, if it doesn’t work for you.
You can probably make even more than free trials by getting people into a monthly subscription, making it harder to cancel, and/or making it so it’s easier to forget that they’re being charged, etc. There are many ways to enrich yourself at the expense of others. And many companies seem to have justified each of these to themselves.
No, that's your mistake as a software maker. User behavior is user behavior.
If you're losing potential paying customers because you lock them out of the trial because they didn't come back to it for a week, it's your sales that will suffer.
Business are risk averse. They don't care about that as much as the real worst case: you become winRar and you have a lot of paying customers that never convert because you gave away too much of your product. It's really hard to put thst genie back into the bottle.
That's not what happens. I download it, use some tiny part of it once (like the noise reduction filter of a full audio editing suite), forgot about it, googled noise reduction 3 months later, discovered I'd already installed it 3 months ago, and now can't try it with a different file because the trial expired.
> The real bizarre thing is that someone can blame the software provider for giving away free use of their software, or for "only" allowing them to use it for 30 days for free.
But they deserve the blame, because now I'm going to go download a different audio editing suite to try their noise reduction instead. And if now I keep having to do noise reduction because it's no longer a one-off thing, I'll purchase that competitor. Because the first piece of software stopped letting me try it out so I can't even compare anymore. Even though I'd only used it for 5 minutes.
My whole point is that "30 days for free" is meaningless if I only use it for 5 minutes. It makes much more sense for trials to be usage-metered rather than contiguous calendar days.
I don't see the problem here other than "I don't want to pay for software." which isn't the programmer's concern. If you don't want to pay, the programmer likewise couldn't give a damn if you can't use his program.
Someone will drop $20 on lunch from some place with no guarantees to its quality and think nothing of it.
But asking the same amount for software requires a painstakingly thorough evaluation.
---
Products like Gmail, Facebook, Dropbox etc have trained consumers that the normal price of software is $0.
Buying behavior is a psychological concept driven by time and attention. A persons mental wallet is open for a limited period of time. The goal of the trial is a conversion to sale.
The scenarios you describe are edge case-ish, and often times companies will accommodate them as edge cases.
If we're selling consumer software, and our expectation is that people might use it only rarely, and only need a fraction of the features, but get value out of it when they do... can we do free trials without this perception?
Don't do free trials? Cripple the trial so that user can see what it can do, but user can't get the benefit they want? Break a big package/suite into many small tools sold separately, to avoid the perception of paying for more than you need or can evaluate? Pay per metered use? Renewable subscription tiers?
> The idea that, as a consumer, I'm going to sit down and fully evaluate a piece of software over the course of 7/14/30 consecutive days to then make a purchasing decision is bizarre.
Except you did do that, in your example. You evaluated it over the span of 5 minutes (you didn't even need days or weeks), and then were apparently satisfied enough with it that you remembered it and came back to it months later to use it again.
And then you balk at the idea that you should have to pay for something that you already know you get value out of. I find that bizarre.
The same reason that people complain about the weapons behavior in Breath of the Wild or why no one uses the fine china: a usage-based trial actually _discourages_ usage.
As someone else said, Scrivener offers this. I downloaded it and wanted to give it a try, but I was always hesitant to fire it up. I always felt that if I did use it and realized five minutes in that today wasn't the day I was going to write a lot, then I had wasted one of my 30 days. People as a whole are loss adverse, and so it is with usage-based trials.
Hmm I would say usage-based free trials are problematic because a small company might only use it 10 times but an enterprise might need to run 10k files to fully trial the product. So what usage level would you set it at? If you go too high the small companies can be on a free trial for years, effectively a freemium model.
As someone who has made and sold such software, no it is not bizarre.
It's very effective.
We decided to just have an indefinite trial period (library has a watermark) and instead offer 30 days of free support. That way we can help people get started and realize their proof of concept, but if they want to start evaluating on their own time they can do so without worrying about any clock. This makes it much easier for customers who are trying to evaluate multiple options at once.
https://news.ycombinator.com/user?id=simonsarris
which says:
I make GoJS, a powerful canvas-based diagramming library:
Which is not what I think of a graphing (time series, x-y points joined by lines), but otherwise seems relevant to their comment.
Most of us who make such libraries tend to distinguish charting (time series, lines, bars) from graphing (nodes and links). Charting is, in many aspects, a much smaller problem space. Graphing requires a lot more in terms of layouts and interaction tools, grid snapping, guides, undo/redo, copy/paste, grouping, subgraphs, managing user permissions for interactivity, expand/collapse (both subgraphs and tree sections), updating the backing data when the graph is edited, etc.
Then JGo (Java), GoDiagram (C#, WinForms and now Avalonia), GoXam (XAML/WPF C#), and GoJS.
I began GoJS as a greenfield project starting in 2010-2011 as a new grad by working with these guys who had been thinking about diagrams for years. So it had the advantage of being built from scratch (and using the brand new HTML Canvas surface) but with all the accumulated experience of their wisdom at hand any time there were design questions. In some sense I got really lucky to work on such a "brand new, but charted path" project. Not many new grads get that kind of experience...
When we released GoJS I was unsure if anyone would actually pay for JavaScript library. There weren't too many I could find in the space that weren't free (Sencha was one I found while doing research, and funny enough they tried to recruit me, flew me out to CA after I wrote a book about canvas circa 2013). But the problem space really truly is large, and you can save a year or more of development time by buying such a library, so the calculus is very worth it for many companies. Like so many people, what we sell is time, and having thought hard about these problems for so long, from layouts to really mundane undo/redo transactional stuff.
This is a key component for any good low/no code platform, process builders, workflow builders , process documentation and so on. And that is just one area.
It makes tons of sense to buy/use a library like this rather than build your own (unless that is your business). We use one from antd. Antiquated and hard to automate testing. We are looking for a more modern solution.
How compatible is GoJS with web testing tools? Most seem to have trouble with canvas.
But you have to inspect programmatically one way or another. What is easiest really depends on what, exactly, you want to test. Eg testing your permissions (can a user copy a node with these checkboxes in my app selected) can be done by trying to copy and seeing how many Parts exist before and after, etc.
Layered Digraph is by far the slowest layout. In general as you get past ~5k nodes you should consider all of https://gojs.net/latest/intro/performance.html
we have some niche performance examples like this (WARNING slightly epileptic) https://gojs.net/extras/10000parts.html, but most of those are for internal testing and not too useful for customers.
It takes a serious block of time to evaluate any product or service, maybe a few days. If I put a few days into an open source product and I like it I can just use it. If it is a paid product I'm going to have to go to my management, it might be easy or it might be hard, but I have to discount the gains from "I found a product I like" by the probability that "we won't buy it anyway" so that makes me all the more hesitant to complete a trial.
Even at 30 days, it's extremely stressful on the team to get the system up and running, ingest our test case data, and run our tests. This is after going through this process >100 times. There's simply no way to get everything that needs to be done with an evaluation of even basic coverage in less than 30. Full stop.
Lack of adequate understanding of the potential challenges an org is going to face during implementation and use is, IMO, the single biggest reason implementations run WAY OVER budget, time, and eventually fail at integration w/the rest of the org. This is entirely ignoring the required change management, which is another beast entirely.
You can also just buy the software to evaluate it. This way you have unlimited time to see if it fits or not. That's what people do in other industries.
Sourcegraph is $99/u/m and has major network effects. For a moderately sized org this is quickly an entire developer salary.
Snyk is similarly priced, unfortunately “just buy” is a really easy way to:
a) pay more than something is woth
b) have multiple products doing the same thing. (for example, I have Miro and figjam and Mural in my company because each do something slightly better and teams have chosen the tools that work best).
That means we often double pay on licenses for ostensibly similar software.
For any other dev tools companies, I’d strongly recommend having lower prices so that every dev at your customer can use it (if that’s relevant for your product). If you start seeing customers be really picky with who gets a license, it’s probably priced too high.
I was entertained a while back when I saw you getting accused for using sockpuppets, but am I correct in thinking that you're probably just using the API to monitor for name mentions?
Edit: To be clear, I think this is great and that more companies should do this.
B) You can buy software and evaluate and decide not to use it and cancel the license.
> Plumbers and HVAC specialists have tools worth tens of thousands of dollars.
And how many of their tools are annual subscriptions? And do their tools have residual value e.g. sell the business as a whole?
But physical tools wear out when used professionally, so they are an ongoing cost. Not to mention all other material that are simply spent when used by people in physical businesses.
You are not going to win as a startup by using Teams, even if it is cheaper than Slack+Zoom, you are going to win big or not at all and focusing on things that don't matter for the core success just means less time to make something people want.
It's just really hard to "undo" these things, both technically and because of the optics (user experience). Requiring your users to re-license their software is friction -- it burns user trust and costs a lot of time in support.
14 days is just too short to evaluate if the product will even meet your needs, let alone evaluate how much lock-in there is and what the path away could look like.
From the sales side, if we see the prospect the finding a solution is a low enough priority that their engineers can’t spend time in two weeks to simply look at a solution, then they might not be an ideal fit for the product (they don’t enough business pain, don’t have a champion, and/or don’t have an economic buyer to prioritize the purchase of a solution).
This is of course highly dependent on the nature of the software and the ideal customer profile of that solution, but the fact that there’s two sides of this coin is something to keep in mind.
And a trial need not take many sales resources. We can automate that with a demo download and self serve documentation. If it's an on prem demo, a 2 week or 12 week trial costs us the same - it's just a sign up and download. We don't actually need a sales rep to prod them about buying - the demo countdown does that, for people actually gaining value from the demo.
Let's acknowledge the article's evidence that longer trials can convert customers with lower pain points. Secure customers like to evaluate things without pressure. And they might be the majority of customers.
Let's enable this by building sales resilience, engineering the infrastructure painlessly delivery a longer trial that takes near zero sales or production effort.
Even if your sales team spends zero time on them they are the kind of customer that will end up losing money for the company.
This whole thought process is how we get money-losing companies with revenue growth rather than sustainable businesses.
The focus is on closing as many deals as possible rather than selectively engaging with the most profitable customer use cases.
The more so as the team is often small (one-person ops teams are probably the norm, at least by number of establishments), and workload is often already overwhelming.
New technology and/or products always come with unanticipated consequences and downsides. Expecting to make a decision on a major, or even minor tool isn't something that can be rushed.
One model I'd noted as innovative at the time was for a SAAS company to offer a free tier of service, in the case in mind, with limited data retention of a monitoring tool. That struck me as an exceedingly good way to balance the power of the tool (all other features were otherwise available), whilst also providing a clear and reasonable upgrade path to a paid subscription. When that company IPO'd and revealed its CoS (cost of sales), I was surprised to see how high it remained (on the order of 40--50% of revenues).
Selling (and buying) complex information goods is hard, whether that's software, services, consulting, news, or anything else. There's a copious literature on the production side addressing the zero marginal cost / high fixed costs predicament. There's less on the buy side, though Akerlof's "Market for Lemons" addresses this in part. Reducing uncertainty, increasing knowledge, and mitigating purchaser risk without needlessly offsetting revenues seem key to the issue.
1. Show me your price, with multiple pricing tiers. The more tiers you have, the more likely I am going to pick one of them, because I will think "well this lower tier is quite the deal compared to the higher tiers!". If I am an Enterprise customer, I will disregard you as an option if I can't see a price. Don't even show me the tier at all if you aren't going to show me your price. I get immediately incensed when I see that "Contact us for pricing!" bullshit, because I know how much bullshit I am in for if I just want to get a quote, so I look for somebody else. I want to use your product right now. But I'm not going to use it if I think it will be painful to work with your company, or that you might have exorbitant pricing, or you're just looking for whales. Don't make me discount you.
2. Let me use your product, immediately. Let me run it from my laptop immediately. Let me spin up a PoC. Show me your complete reference docs immediately. Show me a toy implementation w/source. I want to know if this will [eventually] give me what I want, within 15 minutes. Do that and you will already have gone above and beyond 95% of SaaS (in my mind).
3. Let me have gradient pricing. Let me sign up right away and start using your product for $0, for 5 users. Send me an e-mail when I have 7 users, informing me that I have 30 days to either reduce the number of users to 5, or it will automatically upgrade my account and charge me more (or make me confirm, or whatever). Same for the next tier, etc. (or 'pre-purchase' discounts vs 'on-demand' overage cost, etc) This gives me flexibility: I know our workflows won't just stop working when we hit a limit, and I can acquiesce to the new price or clean up old users.
4. Let me start using your product without a card on file. Sometimes it takes a while to find the right corporate person with the right corp card (if they even let me use a corp card, rather than invoicing). If you really need a card, give me 15-30 days, and then pause my account if you have to. The point is to let me get "hooked" on your product without needing to figure out which card to use first. (It goes without saying that when the card expires or a charge doesn't go through, give me 30 days to resolve it, because usually the corp card has hit its limit)
But the thing is - the reason large companies often don't give folks like you and me these things is becuase there are proven reasons to do the contrary that actually end up making them more money. It sucks, but it's reality.
1. "Call us" pricing works because for big enterprise deals (4-7+ figures), there's often some serious negotiation involved and if you just show a sticker price up front, you risk a) scaring the buyer because the price is too high, b) losing the buyer because your competitor will just negotiate a better price than your listed price or b) leave yourself no room to negotiate if you really put your best price on the website.
2. Offering immediate free trials where you can jump in right away is the ideal world for nerds -- again, I love it personally. But software is often complex, and a guided demo/implementation is often the best path to make sure your buyers are actually successful. Otherwise you risk a lot of folks who sign up, jump in, have no idea what they're doing, and then abandon the trial immediately and go to a competitor who held their hand.
3. "Let me sign up right away and start using your product for $0..." If only offering Freemium were so simple. You will immediately have to deal with porn (it's always porn - and often kiddie porn. These people will figure out incredibly creative ways to use your SaaS product to host illegal content one way or another), spam, fraud, customer service issues, etc. There are many valid reasons to offer Freemium. There are many valid reasons not to do so. It's just not so simple.
4. Again, think about the flip side here. Lower friction to sign-ups without a card, but SO much hassle when it comes time to pay -- now you have to nag, bug, etc. to get payment, and then you have to delete accounts that are dormant. And you have much lower buying intent signals, etc. etc. etc.
I wish the world of software catered to folks like us, but I fully and completely understand why it doesn't.
I'd disagree and say this can go either way. As an enterprise buyer I know both MY budget and that all numbers are negotiable - to some extent. If you show me that this product costs $100k and my budget is $80k, I'll still talk to you. But if you list $100k and all I've got is $25k for the budget, yes, I'm going elsewhere.
Now you might argue "We can make something work" I'm concerned. You'll do 80% off deal? Clearly you don't think your product is worth what you list so... now I don't think so either. And the "But We've got a tier for that" then list it.
My time is way valuable to me. I do not want to go through 3 screening calls, a shit ton of hoops, and a 2 week wait... just to find out that your product is way too expensive for my budget. Especially when getting into those sales calls where the reps wanna play coy and say "Well whats your budget" or "Well it really depends, we want to get into a POC bla bla bla to understand your useless before providing a pricing". Ain't no one got time for that shit. Give me the MSRP up front (with the understanding that a deal may be reachable if it's a little much) or I'm walking.
Keep in mind that when I'm pricing your product I'm probably pricing 3 to 5 others. There is literally not enough hours left in my life to give each and every vendor a 5 hours of time in order to get a price.
Fortunately the world is shifting. You know who's pricing is available on their website? Salesforce. Okta. OneLogin. Ping. Slack. Github. Gitlab. AWS. Google. Microsoft (for some). Elastic. Tailscale. Adobe. Databricks. Datadog. Cloudflare. Zoom. ... The list goes on. In other words there are a lot of companies out there with their prices available on their website right this second. Sure, almost everyone of them has a "Enterprise call us for pricing" option and that's fine, as long as you've got something for me to start with.
If you're a software vendor and don't have some prices to start with, you're at a major disadvantage. Because your competitors often do. And price is not the only thing buyers are looking for. If it was, Okta would have no business. You can look at their prices and OneLogin and Ping's (and Azure AD and Google). The entire IAM/SSO space has their prices right out front and Okta is... the most expensive. Yet somehow they all still are selling.
Often we don't need the whole company to be locked into whatever the Enterprise feature is. Maybe we only need a single feature, and that has a given dollar value for us, and for the provider.
SSO for example costs the provider almost nothing in terms of compute/network, and little in terms of development and support; so why not let people pay a-la-carte for SSO? Cheap enough to be worth it, not so expensive as to be a turn-off. You could have one bulk price for SSO, or even charge per authenticated user! The point is to make it flexible, but still extract some money for that feature that hardly costs you anything to support.
Another example: let them have complex IAM (groups, roles, etc) for one price, and SSO costs extra. OR they can call to negotiate. This way they can pay now a-la-carte, or they can try to get a better price, or they can just settle for not using the feature. But it gets them on your platform, giving you money, in some form or another. Add up all the a-la-carte features and you get a bloated quote, but you can offer discounts for package deals.
Mutual Fund companies do it, and successfully, even if you’re only signing a letter of intent and aren’t buying at the higher tier today.
The charade involving salespeople, and let-me-talk-to-my-manager isn’t as productive as it seems. I’ve walked from several vendors (or discounted them in an RFP) due to that behavior.
Another thing you need to work out, imo, is what level of *feature use* in your application best maps to conversions, and from there, how can you improve the likelihood of people seeing the benefits of that feature use.
As an example, my current company's app can be used with or without agent deployments, and we saw that trials that deployed agents- even just one-off ones in lab envs- converted at a far higher rate than non-agent trials.
So we worked to lower the perceived barrier of entry that agent deployments posed, which meant more people seeing the increased usefulness they provided, which meant more conversions.
Yeah, exactly! Those two groups are not the same, there's an obvious selection effect there.
You're assuming that the percentage increase in conversions after you extended or removed the trial timeout period across the board corresponds to users who previously would have been kicked out by the trial expiry before they could see the value in converting.
My comment was referring to the period you mentioned where you were offering people manual extensions, and you noted that you saw more conversions among that group than among users who didn't extend their trials.
I've never used Uber in my life but I'll be traveling internationally next month for the first time so I figured it wouldn't hurt to install Uber now to get a feel for what the UI is like.
As soon as I signed up Uber was like, hey we'll give you 50% off your 4th ride if you complete 3 rides within 14 days. I won't even be traveling by the time the offer runs out. All this does is make me feel like I made a mistake for signing up too early without knowing anything was going to happen.
As a ridiculous example: I took an Uber from an office to the Indianapolis airport then an Uber from the Dallas airport to a hotel for the night. As I'm winding down for the night I get a notification from Uber: "Need a ride back to ${indianapolisOffice}?".
Another option I like is providing some amount of free credit that doesn't expire. So you're not on the hook for providing a "free tier" forever, but users can play around with your service at their own pace.
Sometimes there's a shifting business priority, and guess which wins when the choice is "important customer X is on fire" vs "our developer trial for wizbang component xyz is going to expire in 8 days".
Like a few weeks ago I was motivated to learn some music production software, so I downloaded a few trial versions. I worked on it heavily for a few days, but then got busy with other things, and now that 30 day trial or whatever is coming up to an end, but I still don't feel like I've had a chance to decide if it works for me, because I haven't been actively using it that long yet still. I do plan to go back to it, just maybe not for another week or two.
But if it only counted the days I opened the application, I'd still have like 26 'days' left to evaluate them (they might, I haven't checked), and it'd be no big deal, and I wouldn't have to feel all stressed out because I'm 'wasting' the demo time by actually having a life and maybe badly timing when to trigger the trial period.
Where they don't make sense is for subscriptions, because subscriptions are by definition something your users will be using for a long time, and it might take them a while to realize all of its value and get hooked.
For this stuff a free tier that funnels customers to the paid tiers usually works best. You can play with limitations by restricting features, or usage, or anything else, but you probably shouldn't restrict them based on how much time has elapsed since they first signed up. Let them get hooked at their own pace.
It reminds me of YNAB's trial[^1] strategy of offering 34 days. It gives folks just enough time with their app and process. I wish YNAB's trial extended to ~60 days since my "ah ha!" moment was only around then. That's another conversation, though.
I wish I could see how a trial length change would affect their conversions.
Both companies knew that we had been paying a different 3rd company quadruple either of their rates, so I was baffled that the first company would basically write us off so quickly when we were openly motivated to switch.
If I sign up on Monday, I might not even look at the API docs until Friday. Assume the week after that I personally like it, if I'm at a bigger company I'm probably going to spend a month or two just getting approval to expense it.
I stop thinking about the task I was working on, or what lead me to the product in the first place, and start worrying about the details of the trial.
"Am I going to need to enter credit card information to start the trial?"
"Will any images I create be watermarked unless I pay a premium?"
"Are the features I actually need even available within the trial, and are they actually useful during that time?"
I don't want a free trial of anything, ever. I'd rather have a free, community-supported version and a premium version with official support. Or a basic version with free, unlimited access to only the most basic features, and a pro version with more advanced features at a cost.
I just need something I can actually use without worry, and when my use case extends beyond the most basic of features, or the software becomes an important part of my daily workflow, I'll happily pay (and I have) for a more powerful version.
Is this true? You don't take a new make and model of automobile for a test drive?
Are you saying you want to pay cash for the test drive?
How do you propose comparison shopping for the primary experience of a car which is how it feels driving it?
> What I was really asking potential customers to do was wait.
> Wait until they're ready to start understanding the API.
> Wait until they're ready to go through onboarding.
> Wait until the PoC is planned.
> …
> What ends up happening is that people get busy and they end up seeing that 14 day deadline, determine that they're not ready yet, so they bounce until they are ready, but then they never come back.
> I decided that I needed to remove that friction. I wanted to capture these leads as soon as they decide Keygen may be the solution for them. So ultimately, I can start nurturing these leads.
I’d love to hear more about what “nurturing” looks like.
I was using a slow dial-up at the time and spent the duration of the trial downloading the game. When I got to log in for the first time in a playable state, it said my trial expired! So ended my WoW journey.
It would have made more sense to start the trial from the first login/entering character creation.
I like the Path of Exile model. The game is free to play, and you pay the price of a game to unlock inventory management. -- By that time you know if you are invested in the game or not.
for a weekend or so a bunch of games are available for free to try them out. sounds nice until you find out that they are really only available for the duration of the demo days. so one time i looked and i found a dozen games that i wanted to try, but then i realized that i would have to spend the whole weekend playing games in order to try them all. i ended up trying not a single one of them because i just can't tell my family that i won't be available for a few days until i tested all those games.
what would have made sense is to allow downloading all the games for free and then give each of them a time limit of a few hours to play. still not ideal (i am a slow player so i'd like to have a bit more time to evaluate a game) but way better than terminating the trial before i have even had the time to play anything.
> We'll get there.
Just FYI, I consider this tease-based writing to be reader-hostile, the prose equivalent of clickbait. It's the surest way to get me to quit reading.
Like other dark patterns, there times when this sort of thing can make sense, but in practice it's usually done (consciously or not) to get the reader to read more than they would otherwise.
For consumer stuff my experience was closer to 25, but for businesses it was 41.
I also found this data point to tend to indicate that this testing/experimentation was not especially rigorous:
> out those that did [ask for an extension] and those that didn't, my conversion rate was higher when they did ask for one.
My first thought was that there is selection bias among people who ask for an extension. People who are pretty sure it's not a useful tool for them aren't going to take the time to reach out.
I totally understand why it makes sense to the business, it's just hard to work it in to my schedule.
Another thing for these companies to think about is a potential customer is investing their own time in learning your product. They may not act on it right away, but I've been in situations where we had an "oh crap" moment and I was able to say go get product X, I know it works on our data sets and already have example scripts for how we can use it and the vendor indicated a price of Y last year which is like 1/5 the cost this other vendor just quoted you to start implementing this from scratch. Allowing employees some creativity to scratch that itch seems to constantly pay off in my experience as long as they're still being successful at their main job.
they immediately added bs "features" like dark theme, changed to subscription model with 1 year sub price 3x what i paid to buy it outright, and reduced trial from 30 to 12 days
piracy is the only true form of digital ownership.
They want me to pay a subscription, but as long as Windows will still open CS6, I'll keep using it. It still gets the job done for me, even though I wouldn't mind some of the newer features (some of my annoyances I know they've improved in the new version) and probably would have paid for an upgrade by now if it wasn't all subscription models now.
And hopefully by the time it stops working, another non-subscription option for Illustrator that I don't hate will be available.
I really enjoy the Affinity tools; they more than meet my modest requirements.
https://affinity.serif.com/en-us/press/newsroom/canva-press-...
It's been a while since I've used Inkscape, but I remember it feeling clunky and buggy for me, and I had difficulty getting into the workflow.
I'm sure I could probably force myself to get used to, and probably enjoy alternatives, but the more I invest in these proprietary alternatives, the harder it will be to shift anything back to Illustrator if I need to, especially since I don't think any of them bother to output to a CS6 friendly file format anymore, so I can shift to them, but I can't easily shift out of them.
And at this point Illustrator CS6 is just dead simple for me, I don't have to think about where anything is, I know exactly what I need to do for like 98% of what I want to do on it, and most of it is muscle memory, I can whip up some cards in a few hours while watching TV shows in the background.
It's going to take something significant (like it no longer working) to motivate me enough to upgrade. I know I'm playing with fire a bit, since these files are getting more and more out of date, and may not import nicely into even the subscription Adobe Illustrator at some point, but I already have too much other shit I have to learn all the time for my day job, I don't have much left outside of that (maybe eventually I will. I am starting to learn Logic Pro and Ableton Live for making music finally, and for the longest time I only used FLStudio).
That's a cool graphic though. I'll download it for future reference. Also it'll be easier for me to convert for other Adobe products, like I mostly use Paint.NET instead of Photoshop nowadays, for example. Illustrator is the main one I feel I have to stick with. Also Flash, since it doesn't exist in any newer ones (I used to make Flash games, so if I want to open those FLA files again, I need it).
An unlimited free trial falls into the same trap of customers leaving until they're "ready" to integrate, time boxing it sort of forces them to commit to the integration at some point.
If I were to do a timed trial again, it'd apply pressure to evaluate and plan the integration right now, and the product may not even be at the stage where they're ready to do that yet i.e. still in dev. This needlessly applies friction, which I want to avoid doing until they're ready.
What's worked better for me is the "startup scholarship" that a lot of companies are doing now. A year is far enough away that we'll either be out of business or have the cash to pay, and I don't need to worry that I'm getting my money's worth by the time the 60-day trial ends.
I'm a big fan of Posthog right now because they have both a generous free tier & a generous startup scholarship. I've moved a ton of stuff to their platform.
A lot of it probably depends on your product though. If you're solving a very targeted problem then you might not be able to create a reasonable free tier. But a lot of B2B tech stuff is like... sure you can charge a bunch of users $5 apiece, but you risk missing the signup of the one user that was going to pay you $10k. Anything with usage-based pricing is going to have Pareto distributed revenue and you need to do everything you can to make sure you're capturing those customers on the tail.
Yep. That's the problem with timed free trials. It applies pressure to sign up only within your magical goldilocks timeframe, otherwise you'll likely bounce because you're not ready to start your 14/30/41/60/etc. day eval.
Usually it’s just a matter of the implementers on the prospect side not prioritizing the effort.
A free trial should usually be followed by a proof of value where both parties are committed to implementing the solution in a realistic way with the expectation of a signed contract if the proof of value delivers on the customer requirements.
This could be something to be careful of if that applies to you.
So far, people who start using the trial usually convert, so lengthening the trial will likely only decrease this. What it could improve, is the number of customers who are willing to start using the trial, thinking 60-days is a lot of free usage.
Instead of a time-limited trial, we have just one of the plot types (Sankey) freely available indefinitely (https://plotapi.com/page/sankey/).
We tried a time-limited trial, and we just ended up with people re-registering new accounts every 2 weeks.
Had it only been "1 month free" I would not have explored enough to sign up.
That said, any-day trials ain't gonna cut it.
It's not about the number of days, it's that a trial is offered at all.
Software customers these days (especially B2Bs) have an internal list of hurdles that prevent them from signing up at all. Methodically remove each hurdle, and at the end there is nothing left to do but buy, or ghost.
A trial is a hurdle to be jumped.
I would bet that the number of paying customers who actually -trialed the software- is 20%.
Why?
It takes time, effort, resources to set things up in order to trial them. To spend those resources means the purchase already needs to be approved.
TLDR saying that you offer a trial at all, for any length of time, is objection handling, not conversion optimization.
I'd bet you could say you offer a 3 day trial and see zero change to the funnel %s.
The story in the post also doesn't seem to address the problem (lowering TTC):
> paid sign ups also increased, with conversion rate staying steady, but now with no manual work.
Ok, but did TTC (the problem) go down, or up?
>What happened next?
>Overall sign ups increased
Top of the funnel increase is great, but I would be keen to understand whether overall revenue went up. Sometimes free tier attract the wrong type of customers
For example,I use hwinfo64 because I like having some system stats on my stream deck. The free version cuts off the shared memory access after 12h and you have to re-enable it manually. Now this is just a fun nerd thing for me, not something I'm using for work. It's a tiny part of the software's feature set. But I would have to buy a yearls subscription, or a lifetime one for $130 - too much for some colorful graphs.
Just yesterday showed my dad a tennis game on my Quest 3. 15 minutes trial / ~$30 to buy. What am I going to do with 15 minutes? That's hardly enough to get through a tutorial, and definitely not enough to make a decision whether the game is good enough. A sports game on a VR headset is basically workout equipment. I'm not going to play that for a day, "beat it" and move on to the next game - I'll either play it every night for weeks, or not at all. So 15 minutes only makes sense if that's well below the time most people find out that the game is garbage (if it is), and if this is a way to trick people.
We live in a time where you can't trust online reviews at all, and where most people just blatantly lie in product descriptions (when have you seen "4K" actually refer to something remotely close to reality?). We need proper trials.
Just make the product free for non commercial use (including a trial in a commercial setting). If I need support or want to buy something please let me contact support or sales. I don’t want an automated email from Jeff at Randomcorp asking me how my trial is going. If a trial has to take 30 days or 365, just let me finish.
For note taking tools it's also hard. You only get to know the tool and how well you can work with it only after you spend time with it and have some content in there. Hard to do in 14 days.
So letting users evaluate the core part of your service without time limit makes sense and it's good to see a successful example of that.
... for things that take longer than that to test. That's rather obvious. There a lot of software that can be evaluated for fit in a couple of hours, especially of a desktop/installable variety.
That punctuation is so critical; I read as "open source available" first time through. I also make "open, source-available" software (aka, source-available). Do folks like this presentation? Or good old "source-available"?
Either provide the full product, for a limited time/usage, OR, just skip it. The last fucking thing ANYONE needs is to work through the UI of an app, get everything staged, then get a fucking "buy me" prompt when they click "ok" to start the process.
As far as the 7/14/30 day trials, I'm fine with those, as long as the above is respected, otherwise, GTFO.
"People won't know the value of my service if they can't use it!" means that you either aren't doing a good enough job showing them the value of your service up front, or you have an incorrect pricing model.
Let's take Stripe as an example. It is absolutely free for you to create an account, browse the dashboard, read their API documentation, etc etc etc, but they take their cut of every single financial transaction you do on their platform. There's no trial - either you find value in Stripe's services, or you don't.
Notion has a free tier for single user seats because that's their marketing plan. The moment you want to use Notion for what it's built for, team use, you're paying per user - again, there's no trial period there. Same for companies like Atlassian or IFTTT or Zapier or on and on and on.
"You get our full service for X days for free, then you have to start paying" is incorrect for _all_ values of X. Either, "you have to pay to be a user of myproduct.com" or "you can be a free user of myproduct.com but once you get to a level where you're serious about using the product, you have to pay" is the correct strategy.
I'd be curious to see the breakdown of SaaS vs self-hosted customers.
Again, imagine what the funnel would look like if the page simply said, "First 100 license keys are free forever. Then pay $0.005 per license key issued."
That's a very, very easy opex cost for a developer (and a finance department!) to understand.
Right now you can get 50 "ALU"s for free per month but the page doesn't say that at all on first glance; you have to move your slider to the left in order to get that offer. Instead there's so much complexity on that page. API requests per day. Number of licenses. "Number of policies" (whatever that means?!?). Number of products.
Devs, please please please simplify.