"Free first, charge later" is one of the most familiar playbooks in software: give every feature away, let users use, give feedback and build their routines around the product, then start charging once it is woven into their lives. The hope is that people will pay rather than give up something they now depend on.
Notice what that plan depends on. Not that the product is worth paying for but by the time payment arrives, leaving will be harder than staying. Habit is being used as a stand-in for value. The two look identical from the inside: same daily use, same routines. But one is appreciation and the other is inertia, and a paywall can tell the difference instantly, because only one of them converts.
That is one version of free-then-charge, the version worth questioning. There are others. Plenty of products stay free early because the product is unfinished and charging would slow the feedback down, and the best freemium models never paywall what was free in the first place, they charge for new value on top of it: more scale, more users, heavier workflows. Two-sided platforms often cannot charge before liquidity exists or one side never arrives. Those are legitimate. The trap is narrower and easier to spot: charging for the same value people already have, just because by now they cannot easily leave. This piece is about that version.
In our case the plan had two requirements we had not accounted for, and missing either one made the eventual paywall look like a bait and switch. Underneath both was the same mistake: we had asked whether users would tolerate paying, never whether we had built anything they would want to pay for.
Requirement one: users have to know payment is coming
For the version we were considering, we should have told users up front: "Everything is free now. At some point, some of this will be paid. Choose with that in mind." Users who opt in on those terms can experience the paywall as an expected step in a product they knowingly bet on.
What we had done, because it was the easier pitch, was say "free" and silently defer the pricing decision. When the subscription finally arrives, a user can reasonably feel that the thing they organized their work around is holding their data hostage.
That's not a pricing announcement. That's a screenshot waiting to be posted.
Requirement two: the transition is a conversation, and conversations don't scale
At ten or twenty users, moving from free to paid is manageable because it's personal. Each user can be walked through why pricing is changing, what stays free, and what the money actually buys. Exceptions get made and early users get grandfathered. At that scale, changing pricing is mostly talking to people.
Our reason for the habit-building phase was growth: waiting for more users to arrive. By a few hundred users there is no talk-to-everyone option left. There is an announcement, and users can experience it as a switch that flipped on them.
In our case, the model was manageable during the exact phase, small and personal with known users, that it was designed to end. The problem was assuming that the same conversation would survive growth.
The version we ran
This is roughly where our product stood: everything we had built was free, no payment processing anywhere in the flow, monetization deferred to "later, once habits form."
The deeper problem surfaced when we went looking for what would eventually be worth paying for. Everything in the product was genuinely useful, and all of it was things people already got for free on the platforms they used daily. Limit how much they could use? Artificial. Cap how many things they could set up? Arbitrary. Charge for better visibility? That's charging for a problem the product is supposed to solve for free. An analytics dashboard? Nice to have, not a problem anyone would gladly pay to make go away.
Nothing held. The habit had formed around things we could not justify charging for, because people already had versions of them elsewhere. We had months of usage as evidence, and none of it was evidence of value. Usage tells you people came back. It does not tell you they would have paid.
Where this leaves us
To be clear, none of this is a settled decision. It is something I realized while thinking through the model, and the team has not taken it up yet. What we are leaning toward is the freemium shape: a base that stays free, with better features on a paid tier. The realization above is the caution I want attached to that plan, because the shape alone does not save it. The paid tier still has to be new value that justifies itself to someone who has never heard of us, before any habit exists, and not a paywalled version of things people already get free elsewhere. We are still researching what carries that weight.
The free base could then become the marketing. Platforms charging listing fees and monthly subscriptions would be competing against a free base. The revenue would have to come from standalone value that justifies itself to the very first user. That is a higher bar than a paywall, and we have not cleared it yet. It is also the only bar that means anything: if the answer to "why would anyone pay for this?" only works on someone who already depends on you, it isn't an answer.
What we are checking now
- We should have told users payment was coming, then checked whether that conversation could survive beyond the first small group.
- We should have asked whether the features earmarked for future charging were things people already got free elsewhere.
- We are now looking for value a seller in our market can see before a habit exists, and it has to be new value, not a paid version of what the free base already does. That research is not finished.
Waiting for habits to form before charging anything left us researching the business model during exams and luckily we found the problem before the paywall shipped.