How do you decide what features should be free and what should be paid?
Let me start from the creator’s perspective:
I personally don’t have a product (apart from hiring people for creative work or offering personal consultations).
But as a creator, I constantly share content, insights, and information, value that helps me build trust (for free). Based on that perceived expertise, people eventually decide to work with me (a paid service).
So some things I share for free to eventually move toward a paid collaboration.
Personally, it’s sometimes hard to judge when I might be giving away too much for free.
And I assume it’s similarly tricky for builders.
You want users to try the product, but then comes the question of paid features, or a trial limited by time or usage.
How do you decide which parts of your product or service remain free, and which become paid?
When I share content publicly, I usually provide generalised advice. But when it comes to a specific case or a tailored strategy that requires a personal approach, that’s where it becomes paid.
Replies
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.
CharpstAR
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?