WeTransfer tells you a file was sent. Email tells you a message was delivered, maybe. Neither tells you the one thing that actually matters when you're sending a signed contract, a legal notice, or a client's financial records: did the right person actually open it?
That gap is what we're building Senduta to close — a secure digital courier for confidential documents, built for lawyers, chartered accountants, recruiters, consultants, and architects who need something closer to registered post than a share link.
The problem with "just send it as an attachment"
Most document sharing today optimizes for convenience, not accountability:
- Email attachments can be forwarded infinitely, with zero record of who opened them.
- Generic file-transfer tools confirm upload, not delivery.
- Nobody produces a certificate you could actually hand to a court or a compliance auditor.
For a lawyer serving a notice or a CA sharing financials, "I think they got it" isn't good enough.
What Senduta does differently
Senduta treats every send like a courier parcel, not a storage bucket:
- Email-OTP verification — only the intended recipient can unlock the file
- Full audit trail — delivered → opened → downloaded, each with timestamp, IP, and device
- Certified delivery PDF — a branded certificate with a SHA-256 integrity hash of the file
- AES-256 encryption in transit and at rest, plus dynamic watermarking
- Self-destruct — files are permanently deleted 24 hours after download
- Link expiry & instant revoke, resumable uploads up to 50GB
The self-destruct part is deliberate: Senduta is a courier, not a storage service. It delivers, then deletes — which also means we're not sitting on a growing pile of other people's confidential documents.
The stack
Nothing exotic — mostly boring, reliable choices so we can move fast without fighting the tools:
- Next.js 16 / React 19 for the app
- Supabase for auth, Postgres, and session state
-
AWS S3 (via
@uppy/aws-s3for resumable multipart uploads) for file storage — since files are transient, S3 with lifecycle rules made more sense than baking storage assumptions into the DB layer - Resend for transactional email (OTP codes, delivery notifications)
- pdf-lib to generate the certified delivery PDFs server-side, embedding the SHA-256 hash at generation time
- sharp for watermarking and image processing
- Claude API (Anthropic SDK) — this is the part I'm most excited about. We're layering in AI-assisted document summaries and smart tagging on top of the delivery pipeline, so recipients (and senders) get a quick sense of what's inside a document before committing to a full read
What's next
We're mid-build across a staged roadmap: core send/receive flow and audit logging are in place, and we're working through OTP gating, watermarking, and the certificate/hash pipeline before layering the Claude-powered document intelligence on top.
If you send confidential documents for a living — or you're just interested in the "prove it, don't just trust it" approach to document delivery — I'd love feedback. Follow along at senduta.com.
Building in India, for the world.
Top comments (4)
I like the self-destruct decision a lot. Deliver then delete means you're never the honeypot, and that's exactly what I'd want to hear if I were the lawyer.
One thing I'd think through before the Claude layer goes in: the pitch is that the document only meets the verified recipient, but AI summaries mean the file content also meets a third-party API. Whatever the provider's data policy says, a chartered accountant is eventually going to ask that question in a sales call. Curious whether you're planning summaries as default-on or per-send opt-in.
Hey Pon, This is the sharpest question anyone's asked me about the AI piece, and no, I haven't fully closed it out — you're right that "the document only meets the verified recipient" and "we also hand the file to an LLM" are in tension, and a CA will absolutely surface that in a sales call before I do if I'm not careful.
Where I've landed for now: summaries are per-send opt-in, not default-on. The whole pitch of Senduta is confidentiality-by-default, so quietly routing content through a third-party API by default would undercut the thing I'm selling. If someone wants a summary, they'll have to explicitly ask for it on that send — same way the self-destruct/delete-after-download behaviour is the default and not deleting is the exception someone has to choose.
The other things I'm working through before it ships for real: using the Claude API's zero-data-retention option so content isn't sitting anywhere longer than the call itself, and being upfront in the docs/DPA about exactly what leaves the system when summaries are on, so it's not a surprise buried in a privacy policy nobody reads. Appreciate you flagging it now — better to bake the opt-in in from the start than retrofit it after a client asks the awkward question first.
Circling back on this, went ahead and baked it in properly. AI summaries are now hard-off by default and opt-in per send (never account-wide or silent), set up to use Claude's zero-data-retention mode, so nothing lingers past the call, and I've documented exactly what happens in the privacy policy instead of burying it. Your question is the reason it's opt-in from day one rather than a retrofit genuinely appreciate it. 🙏
That was fast. Hard-off by default and documented in plain sight is the version a lawyer's procurement checklist can't argue with — you turned an awkward future question into a selling point in a day. Glad it helped, and good luck with the certificate pipeline, that sounds like the satisfying part to build.