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
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.
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 mean alot of it for anyone (like me) building in AI, is determined by margins. I.e., creating AI images/videos on our paltform, well it's tough to cover that cost - but creating a tiktok slideshow with our existing image sets, that doesn't cost us too much, so does not kill us to make free