When To Request A Custom License Instead Of Checking Out Directly

Direct purchase licensing is designed to keep common commercial use simple. But not every project is common, and that is exactly where a custom license request becomes the cleaner path.

Use the inquiry path when the scope is unusual

• The font will be embedded in a product, app, or game beyond standard retail terms.
• The work will be distributed across a larger company or multiple business entities.
• The client needs written approval for broader transfer, redistribution, or audience scale.
• The project combines assets, deliverables, or channels that do not fit a standard checkout option cleanly.

Why this matters operationally

The safest order flow is one where the purchased terms, the certificate, and the real use case all line up. If a buyer forces a complex project through the wrong retail license, the friction appears later during delivery, compliance, or client review.

Custom requests are part of the product, not an exception

Sibelumpagi is built to sell standard licenses directly and move broader cases into inquiry workflows. That is part of the intended commercial model.

If the project description sounds bigger than a normal retail order, treat that as a signal and ask for custom terms before payment.

Practical workflow for when to request a custom font license

Identify usage that exceeds standard tiers before payment, including unusually large teams, multiple entities, broad distribution, or combinations of embedding and broadcast rights. Start with a written project brief instead of evaluating the typeface in isolation. Record the real words, users, outputs, channels, and technical conditions involved. This makes the visual test repeatable and gives the license decision a factual basis.

A written usage inventory gives both buyer and foundry enough detail to confirm scope. It should include users, products, websites, apps, campaign reach, duration, territories, and whether third parties need file access.

Use this review sequence:

• Write down the exact usage and distribution instead of relying on a broad label such as custom license, retail checkout, commercial use.
• Count every person or entity that needs to install, access, embed, or distribute the font.
• Separate static design output from live web, app, software, template, and broadcast delivery.
• Keep the invoice, license PDF, font package, and approved usage statement together for future review.

Common mistakes to avoid

Do not approve a font only because one supplied specimen looks attractive. Avoid testing only a short placeholder, ignoring mobile or small-size use, assuming every font format grants the same rights, or sharing the commercial package with people who are not covered. Keep the preview decision, production implementation, and license scope connected.

Questions buyers ask

What should be prepared before using this guide?

Prepare the exact copy, final output sizes, target channels, number of users, and the longest or most difficult text the project is likely to contain. For digital work, include viewport sizes and embedding details. For print, use an actual-size proof. This is more reliable than judging an isolated alphabet.

How do I know when the font is ready for production?

The font is ready when the important words remain recognizable, hierarchy stays clear, spacing works without constant repair, required characters are present, and the design remains consistent across the smallest and busiest layouts. Ask someone outside the project to scan the result without being told what it says.

Which font license should cover the final use?

Use a standard tier when the published terms clearly cover the project. Request custom licensing only for broader usage rights for existing Sibelumpagi fonts, not for custom design or consulting work. Review the current Sibelumpagi license page before checkout because rights depend on the actual deployment, not only the visual style or file format.

Final recommendation

Use when to request a custom font license as a decision process, not a trend checklist. Save the tested copy, approved settings, selected glyphs, implementation notes, and license record with the project files. That documentation makes future updates faster and prevents another designer or team from unknowingly changing the visual system or exceeding the purchased rights.