.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 early-access email explains a pending opportunity to use a product and the step required to pursue it. Its design should distinguish joining a list, applying for a pilot, and receiving active access.
The Folk reference tells the recipient they are on a priority list and invites them to apply for pilot access through a qualification form.
This separates existing interest from a new application. Do not describe a waitlist member as an active pilot user before the program establishes that status.
An application CTA should explain the review or qualification process rather than promise immediate product access.
Describe the relevant capability, audience, and requirements. A recipient needs a concrete reason to apply beyond being among the first.
If testing or feedback is expected, state that accurately. Keep limitations and support routes available according to the actual program.
Avoid invented launch dates or guaranteed priority. The message should describe commitments the team can support.
The mmhmm reference thanks beta participants and explains several improvements with comparison images and interface examples.
This is a participant update rather than a first access invitation. Its relevance comes from changed work and feedback context, so its structure should not be copied indiscriminately into a waitlist message.
Name the actual availability state and any required update or action. A polished email does not imply a general public release.
Apply, accept, download, and open a workspace lead to different outcomes. Label the destination and preserve access context through authentication where relevant.
Expired or closed access needs a useful explanation. A generic product homepage should not leave an invited recipient unable to find their route.
After application, confirm the received request rather than inventing approval.
When invitations progress or the product becomes generally available, update the message sequence. Users should not remain in an obsolete pending state.
Review recipient eligibility, form, confirmation, and follow-up together. Keep essential instructions readable with images blocked and on mobile.
Use SaaSFrame's early-access email references to compare pilot applications and participant updates. Design around the actual relationship and next commitment.
No. Explain whether the recipient is waiting, applying, invited, or already participating.
Not necessarily. Existing participants need changed-work context, while applicants need expectations and access steps.
Confirm receipt and the actual next process, without implying approval before it occurs.
