How do you decide what features should be free and what should be paid?

This is something I’ve been thinking about too while working on a project recently, so the timing of this post is perfect. Really insightful perspective, thanks for sharing this Nika :D

From how you framed it, what clicked for me is:
free = helps people understand the value
paid = helps them actually get results faster or at scale

So basic use cases or smaller usage make sense to keep free. But once it becomes part of someone’s actual workflow or starts saving real time, that’s where paid feels more fair.

Still figuring out the balance though, it’s trickier than it looks.

Really timely question for me — just launched Zeno Finance and wrestled with this exact decision for weeks.

Landed on full product behind a 7-day trial, no freemium tier. Here's my thinking:

Freemium attracts people optimizing for free. A time trial attracts people who actually want to solve a problem. The freelancers I built for aren't looking for a free tool — they're looking for the right one. If 7 days isn't enough to know, the product isn't good enough yet.

Your point about generalized vs tailored is exactly the right framework. The free tax calculator I built gives anyone a general estimate — no signup, instant value. The paid dashboard is the tailored version — your clients, your real numbers, your specific situation.

Free = the concept. Paid = your version of the concept.

The giveaway that converts best isn't a watered down version of your product. It's something genuinely useful that makes people realize they need the full thing.

Yeah, this took some iteration on my side too. My first instinct was to gate features behind a subscription. After running through the onboarding flow a few times, it started to feel like I was asking people to pay before they’d really had a chance to experience all aspects of the product.

I ended up moving toward a fuller free experience. My thinking is that free should be enough for someone to genuinely understand the value and build trust in the product. Paid starts to make more sense when the product becomes vital at a deeper level, especially for team use.

And honestly, I appreciate products whose free tier is enough for light use. Even if I never upgrade, I remember them and recommend them.

Most answers here are about features, but I think the cleaner split is actually about uncertainty.

Free should reduce uncertainty enough for someone to say:
“ok, I understand the problem and why it matters”

Paid is when the user wants to reduce uncertainty in their specific situation.

That’s where things become expensive:
– interpretation
– consequences
– trade-offs

In my case (I’m building a simulation tool for startup ideas), the free layer shows adoption patterns and friction.

The paid layer is where it answers:
“what does this mean for my idea, my timing, and my risk?”

So it’s less about holding features back, and more about:
where does the output become decision-critical?

If you charge before that point → people don’t convert
If you give that away for free → people don’t need to pay

It's easy for a product, you keep the cheap, valuable, aha moments feature for free, and keep the expensive, high credit/unit economics feature premium.

For us in QueueForm, the only 2 features that we have made paid only, is Custom Domain and the ability to send emails via SES. They cost us for each unit, so they are behind the paywall.

Anything else that just does not cost us much, is free for user to try, play and experiment.

I think the decision is actually a simple one, and it all depends on if you can afford to self fund the free service out of pocket, which if you can then go ahead. if you can't then monetize from day one and only offer the most minimal amount of freebies to get users to convert to paid.

ive learnt this from my own product which i monetized from day one and tbh, you'd be surprised that people are willing to pay if it solves a true pain point and actually adds value to them.

Great question, Nika. I think about this a lot because I'm building in this exact space.

I built Signbee — an e-signature API designed for AI agents. So literally my product lets agents handle legally-binding documents. Which means I've had to sit with this question deeply: where does the trust boundary actually sit?

My take: trust the agent with execution, never with authority.

What I mean is — an AI agent can draft a contract, send it to a signer, and track the status. That's execution. But the human still has to read and sign it. That's authority. The agent never holds the pen. That distinction matters.

Same principle applies to your examples:

• Finances: I'd let an agent prepare an invoice or flag an anomaly. I wouldn't let it approve a transfer. (The Sapiom news is interesting but notice — it's agents buying tools, not making investment decisions.)

• Health: Let an agent summarise your lab results. Don't let it decide your treatment.

• Communication: Let an agent draft a message. Don't let it send without review. At least not yet.

The pattern is: AI handles the workflow, humans hold the checkpoints.

That's actually why I built Signbee the way I did — the agent can orchestrate the entire signing flow via API, but there's always a human at the signature step. The protocol itself enforces the trust boundary.

As for the Sapiom raise — I think it's less about "trusting agents with money" and more about infrastructure catching up. Stripe just launched MPP (Machine Payments Protocol) this week. Cal.com has Cal.ai for scheduling. AgentMail handles email. We handle signatures. The stack is forming, and each layer has its own trust model baked in.

The real question isn't if we'll trust agents — it's whether the tools they use are built with the right guardrails. That's on us as builders.

I'm about to launch a desktop app called Notion Launcher and dealing with this exact question right now. Can't decide between limiting features or limiting usage count on the free tier. Feature-gating feels cleaner, but usage limits let people try everything before they commit. Anyone here tried both and found one converts better?

This is such a real problem.

As creators (and builders), we’re constantly walking a thin line between building trust and giving away too much.

Free content/products bring attention and credibility.
But if you overdo it, you risk removing the need to convert.

What’s worked for me (and what I’ve seen work well):

Free = demonstrate value
Paid = deliver outcomes

Free should make people say “this is useful”
Paid should make them say “this solves my problem”

Curious how others here think about this,
Do you draw the line based on usage, features, or outcomes?

I run a website that sells phone cases with AI generated designs. This is how I split the free and paid "tiers":
- Let users create the designs for free (even though it costs me a substantial amount of money)

- Only charge users when they buy a case.

Requesting payment is always a source of friction. If you do it too early customers will walk away without getting to know your product. For example, if I charged people money just to design a case, most people wouldn't even try it. In my opinion, the best approach is to give the customer the opportunity to fall in love with your product, then offer a paid option. When it comes to my business, the customer is most likely to open their wallet when they're looking at their dream phone case design, which is why I absorb the AI token costs and let them design it for free.