.webp)
We sell SaaSFrame licenses on Gumroad, a secured online selling platform for creators.
SaaSFrame gets updated all the time! Every new update and version will immediately be made available to all SaaSFrame users.
The licence key required to create your SaaSFrame account is send by Gumroad once you made your purchase. If this email is blocked by your email client, send me an email at antoine[at]unmake[dot]io so I can resend the licence key.
You can generate an invoice on Gumroad once you purchased SaaSFrame. You will find the link in the order confirmation email.
If you're not satisfied, you can ask for a refund within 7 days. Just send me an email at antoine[at]unmake[dot]io
A SaaS verification email helps a recipient complete a pending proof step, such as confirming control of an email address. It should explain the action and its consequence without presenting an unverified account as already confirmed.
This guide concerns visible communication design rather than the technical security of verification systems.
The Confetti reference explicitly asks the recipient to confirm an email address and provides a single confirmation action. Guidance for an unexpected message sits below the explanation.
This makes the task narrow and understandable. Confirming a mailbox does not establish every aspect of a person's identity, so avoid a broad verified label that exceeds the actual proof.
The FullStory capture combines a welcome heading with a verification instruction and an account-activation action. The message remains compact.
A greeting can accompany the task, but the pending state should remain clear. Receiving a welcome message does not necessarily mean every access requirement is complete.
If activation depends on verification, explain that relationship using the actual product model.
A confirmation action should lead to the relevant proof step. Avoid a generic product-exploration button when the immediate task is verifying the address.
If the flow uses a code instead, present the value and instructions according to the implementation, with a usable entry destination. Do not mix link and code language ambiguously.
Sending the message and completing verification are separate events. Confirmation should follow a result the product can establish.
If the action expires, provide the real rule and a route to request a new message. An expired link should not look like a completed verification.
Support correction when the destination address is wrong. Repeatedly resending cannot solve a typo in the pending account information.
For an already-confirmed address, provide a coherent continuation rather than an alarming generic error.
After verification, return users to the appropriate setup or intended destination where the product supports it. Authentication and workspace setup may still be separate tasks.
Do not imply that a product action succeeded merely because the address was confirmed. Each completed state should be named accurately.
Keep unexpected-request guidance clear and appropriate to the real process, without unsupported conclusions about account activity.
Test valid confirmation, expiry, repeat opening, address correction, and the next destination. Check consistency with the verification screen inside the product.
Use SaaSFrame's verification-email references to compare explicit confirmation and welcome-plus-verification layouts. Design around completing a narrow proof step with accurate feedback.
No. A greeting and confirmed proof are different states.
The actual confirmation or activation step, with a destination that preserves the pending task.
Explain the state and provide a route to obtain a new verification message.
.avif){kind=small}
