Original Summary

I'm building a small SaaS for freelancers (Client Kit). The client gets one link where they read a proposal, sign it, and pay the freelancer. I want to share one business-model decision, because it shaped the whole product and I'm curious how others here would have played it. The obvious model: take a cut Most tools in this space (HoneyBook, Bonsai and similar) process the payment themselves. The client pays by card through the platform and the platform keeps a percentage. For a SaaS that's great: revenue grows with your customers' revenue, and you get a clear "payment succeeded" signal for free. Why I didn't My users are Indian freelancers doing jobs of roughly ₹15k–₹1.5L. Their clients pay by UPI, which costs nothing and goes straight from bank to bank. When I talked to freelancers, the thing they hated most about the big suites was "they sit between me and my money and charge me for it." A 2–3% cut on a ₹60,000 job is ₹1,800+, which is a meaningful amount for a solo designer. So the product never touches the money. It charges a flat monthly fee for the software (plus a free tier) and takes 0% of job payments. What that cost me No usage-based revenue. Pricing is a flat per-month subscription, so heavy users don't pay more automatically. I tier by sends per month instead. No payment signal. This was the big one. If money moves directly from the client's UPI app to the freelancer's bank, I have no way to know it happened. And the #1 complaint I heard was clients sending fake "payment done" screenshots. What I built instead of a payment processor UTR instead of screenshots. The client enters the 12-digit UPI transaction reference. The freelancer checks it in their own bank app and taps confirm. Each reference can only be used once per freelancer, so the same UTR can't be "reused" on another job. The UI never says "verified", only "confirmed by {freelancer}", because I can't verify it and I didn't want to pretend I could. Payment stages on the same link: advance → balance on delivery. The link says "work starts after the advance is received", so the freelancer doesn't have to be the bad guy. An optional bridge for people who already use a gateway. If a freelancer already has their own payment gateway account, the link can create a payment link on their account and auto-confirm from the webhook. The money still settles to them; I only read the notification. A hash-chained audit log + a one-click "proof pack" PDF , for when a client stops answering. Without the trust signal a payment processor gives you, a tamper-evident record became the next best thing. Open questions I'm still chewing on Did I leave too much on the table? A % model would have been far easier to scale revenue-wise. Is "sends per month" the right value metric for a flat subscription, or should it be active jobs? For those of you selling to pri

  • 情报分类：工作与职业机会
  • 分类依据：内容涉及招聘、求职或职业发展
  • 信息来源：Reddit · SaaS
  • 发布时间：2026/10/8 22:22:11