.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
SaaS appearance customization lets users change how an interface or shared output looks. It can cover a personal light-or-dark preference, a workspace brand color, or a logo used in customer-facing material. Those changes have different scopes, so the screen should explain whose experience is affected before offering controls.
The SaaSFrame references include onboarding theme choices and a branding settings page with output previews. They illustrate how selection, preview, persistence, and application can fit together. The goal is to help people recognize and control the resulting appearance, rather than maximize the number of visual options.
A personal theme changes the user's own working environment. A brand setting may change checkout pages, invoices, or other material seen by customers. The interface should not present both as equivalent cosmetic choices.
Identify the affected scope in the title or explanation. If a setting applies across a workspace, say so. If it is saved per device rather than per account, communicate that behavior when it affects expectations.
Separate permissions accordingly. A teammate may be allowed to choose dark mode without being allowed to change the organization's logo. Similar color controls do not imply similar authority.
The Threads capture presents light and dark theme choices through interface previews. It also says the choice can be changed later and provides a continue action.
A representative preview helps users understand the option without requiring them to decode a theme name. The ability to revise the choice reduces the pressure of deciding during setup. The selected state still needs a clear visual and accessible indication.
Use previews that reflect the real interface. A generic bright and dark rectangle can communicate tone but not readability or content density. If the product has a system-preference option, explain how it differs from a fixed selection.
A theme question can help a user make the environment comfortable immediately. It can also delay a first useful task when the default is already adequate. Place it according to the audience and the importance of the preference.
The Flowrite capture places a light-or-dark choice after an extension-installed confirmation within a setup sequence. This connects the choice to an initial configuration moment.
When adapting the approach, keep the next action understandable and avoid making a visual preference look like a required technical dependency. If the user skips or accepts a default, provide a recognizable settings route later.
Some customization interfaces apply changes immediately; others require saving. Both models can work, but the user needs to know which one is active. A previewed color should not look permanently applied if changes remain unsaved.
Keep cancel and reset behavior explicit. Canceling can discard pending edits, while resetting can restore a default or previously saved state. Do not use the two labels interchangeably.
For immediate application, provide clear feedback and a reliable way to reverse the choice. A screen changing dramatically without an identifiable selected value can make correction difficult.
The Copperx capture combines logo upload and a hexadecimal brand-color input with a preview area. Tabs distinguish checkout and invoice-PDF output, while a save-changes action sits near the page heading.
This makes customization more concrete than a color picker alone. Users can inspect how the same brand choice affects different customer-facing surfaces. A preview is particularly useful when the output differs from the administrative screen used to configure it.
When adapting the model, keep previews synchronized with pending values and label their status. A saved logo and an unsaved color should not appear as an unexplained mixture. The interface should establish whether the preview shows draft settings or active output.
A logo control should explain the accepted asset and relevant constraints. A full logo, square mark, and icon are different inputs. Tell users what the product needs rather than asking for a file and revealing incompatibility afterward.
Show how the asset will be fitted. Cropping, padding, and scaling can change the result, especially across light and dark backgrounds. A preview should include realistic contexts where the logo appears.
Provide a replacement and removal route. Users may upload an outdated or unsuitable asset. Preserve the previous valid state when an upload fails and explain whether the failure concerns format, size, or processing.
A hexadecimal field can suit users with an existing brand specification. A picker can help people exploring a color. Providing both can support different needs if their values stay synchronized.
Validate the entered format without discarding the value. A user should know whether the problem is an incomplete code or an unsupported format. Show the resulting swatch, but do not rely on the swatch alone to communicate the selection.
Consider the surfaces on which the color will appear. A brand accent used for buttons, text, and backgrounds may require different treatments to preserve readability. Applying one raw value everywhere can create inconsistent or unusable output.
Customization should not make essential content unreadable. Decide how the product handles colors that do not work with its foreground text or background. Explain any adjustment rather than silently changing the user's selection.
Theme design needs more than inverted colors. Status, focus, disabled controls, charts, images, and elevation may all need appropriate treatment. Test the full interface rather than only the selection preview.
Users need a way to recover from a problematic appearance. Keep the settings route and important controls visible after changes. A theme should not hide the very action required to switch back.
A brand setting may cover only selected outputs. A personal theme may apply to the web app but not an exported file. List the meaningful boundaries rather than implying a universal transformation.
If a change affects future output only, say so. Existing invoices, generated files, or published material may remain unchanged. A preview of new output should not suggest that historical artifacts will be regenerated automatically.
For shared workspaces, identify whether the change is immediate for everyone or depends on a publish stage. Keep the account context visible so users understand which environment they are modifying.
Defaults can provide a usable experience before configuration. Label them in a way users understand, such as system preference or product default. An unexplained empty color field can mean either no customization or a missing value.
Reset should identify the destination state. Returning to the original product theme is different from restoring the last saved brand configuration. Explain the effect when it is not obvious.
Preserve custom values when users temporarily switch to another mode if the product supports it. A theme change should not unexpectedly erase a carefully entered brand color or logo configuration.
Review light and dark themes, logos with transparent backgrounds, unusual aspect ratios, long names, and low-contrast color choices. Inspect every output represented by the settings page.
Test unsaved edits, failed uploads, account switches, permission restrictions, and returning sessions. Confirm that displayed values match the active or draft state as labeled.
Ask users to explain what changes, who sees it, and whether it is saved. Those answers reveal scope and persistence ambiguities that a visually attractive preview can hide.
Immediate application can work for a personal preference. A shared branding change may benefit from preview and save. Communicate the chosen persistence model clearly.
Usually it is an interface preference, while branding affects shared or customer-facing output. Define the actual scope in your product rather than relying on the control's appearance.
It shows representative output with the selected values and an understandable saved or draft state. Include the surfaces where the choice has a meaningful effect.
