ClientsPulse is the post-sale relationship engine for freelancers, consultants & small agencies. Smart timeline auto-built from BCC'd emails, AI-drafted follow-up nudges (human-approved), and one-click client portals with zero login. The chaos-stack killer.
Hey PH! π
I built ClientsPulse after losing 4 retainer clients in two months β not because they were unhappy, but because I just... forgot to follow up. The "I'll reach out when I have something to say" approach is how solos quietly bleed revenue.
The MVP does three things and nothing else:
1. Smart Timeline β BCC a unique address, every client email lands in the right timeline automatically.
2. Auto-Nudge Engine β AI flags at-risk clients and drafts a nudge in your voice. You approve in 10 seconds. Always human-in-the-loop.
3. One-Click Portals β clients approve work or pay invoices with a signed link. No login. Ever.
Stuff I deliberately did NOT build (and why):
- Proposals, contracts, scheduling β HoneyBook/Dubsado already nail these
- Lead capture β you probably already have something
- Built-in form builder β Tally + Typeform are already great
- Native mobile app β PWA covers 90%, native is post-PMF
Founding 100 gets 25% off forever. Once 100 customers subscribe, the discount closes β no exceptions.
Happy to answer anything: technical, pricing, "why no [feature]", or "how is this different from [tool]" π
Managing client relationships post-sale is where so many freelancers and small agencies drop the ballβnot because they don't care, but because manual CRM upkeep is an absolute chore. Turning simple email BCCs into an automatic timeline and offering zero-login client portals is a massive workflow upgrade. Getting clients to create yet another account is usually a losing battle, so removing that friction entirely is a brilliant move.
Quick question on the zero-login setup: How do you balance that frictionless access with security? Are the portal links generated with secure, expiring tokens to make sure private project data or invoices don't get exposed if an email accidentally gets forwarded?
Report
Maker
@manal_essalek1Β Thanks so much, this hit on exactly the friction we kept seeing β clients politely ignoring "create an account to view your project" emails until the relationship quietly went cold.
Great question on the security tradeoff, and it's one we spent a lot of time on. Forwarded-email risk is the obvious failure mode, so the portal tokens are built to assume that will happen and stay safe anyway:
- Cryptographically random, not guessable β each token is 32 bytes of CSPRNG output (256 bits of entropy), delivered as an opaque base64url string. No structure, no client ID embedded, nothing you can decode from
the URL.
- Hashed at rest β we never store the raw token. Only an HMAC-SHA256 hash sits in the database, so even a full DB compromise doesn't yield working links. Verification is constant-time to prevent timing attacks.
- Expiring by default β 14-day default expiry, 30-day hard ceiling. No "permanent share links."
- Scoped, not blanket access β every token is bound to a single client + a single resource (one invoice, one timeline, one project). A forwarded link can't be pivoted to browse anything else.
- Optional single-use mode β for sensitive resources like invoices, the operator can issue a one-shot token that burns after first view.
- Instantly revocable β one click from the dashboard kills the link, and every issue/revoke is written to an immutable audit log.
- Key rotation built in β the HMAC signing key rotates on a 30-day overlap window, so old tokens age out cleanly.
So if a client forwards a link by accident, the blast radius is: one specific resource, for a bounded window, revocable in one click β never an account, never the full relationship history, never anyone else's
data.
Appreciate you digging into this β it's the kind of question that tells me you've actually shipped products that handle client data. π
---
Want me to tighten it, drop the bullet list for a more conversational flow, or trim the technical depth?
Report
No reviews yetBe the first to leave a review for ClientsPulse
mailX by mailwarm
@manal_essalek1Β Thanks so much, this hit on exactly the friction we kept seeing β clients politely ignoring "create an account to view your project" emails until the relationship quietly went cold.
Great question on the security tradeoff, and it's one we spent a lot of time on. Forwarded-email risk is the obvious failure mode, so the portal tokens are built to assume that will happen and stay safe anyway:
- Cryptographically random, not guessable β each token is 32 bytes of CSPRNG output (256 bits of entropy), delivered as an opaque base64url string. No structure, no client ID embedded, nothing you can decode from
the URL.
- Hashed at rest β we never store the raw token. Only an HMAC-SHA256 hash sits in the database, so even a full DB compromise doesn't yield working links. Verification is constant-time to prevent timing attacks.
- Expiring by default β 14-day default expiry, 30-day hard ceiling. No "permanent share links."
- Scoped, not blanket access β every token is bound to a single client + a single resource (one invoice, one timeline, one project). A forwarded link can't be pivoted to browse anything else.
- Optional single-use mode β for sensitive resources like invoices, the operator can issue a one-shot token that burns after first view.
- Instantly revocable β one click from the dashboard kills the link, and every issue/revoke is written to an immutable audit log.
- Key rotation built in β the HMAC signing key rotates on a 30-day overlap window, so old tokens age out cleanly.
So if a client forwards a link by accident, the blast radius is: one specific resource, for a bounded window, revocable in one click β never an account, never the full relationship history, never anyone else's
data.
Appreciate you digging into this β it's the kind of question that tells me you've actually shipped products that handle client data. π
---
Want me to tighten it, drop the bullet list for a more conversational flow, or trim the technical depth?