“Can this be customized?” is really two different questions depending on what you mean by it. One is about how it looks. The other is about how it behaves. Off-the-shelf products can usually solve the first. Only a handful of suppliers can actually solve the second.
Most e-paper suppliers will tell you their products are customizable. Most of the time, what they mean is that the housing color, logo placement, and mounting bracket are adjustable — which is genuinely useful, but it’s a narrow slice of what “customization” can actually cover on an e-paper project. The more useful question isn’t whether customization is available, but which layer of the product you actually need to change.
When Off-the-Shelf Is Genuinely Enough
Not every project needs customization, and it’s worth ruling this out first, since it’s the cheaper and faster path when it fits. Off-the-shelf hardware is usually the right call when:
- The deployment is small enough that branding/cosmetic differentiation doesn’t matter operationally.
- Standard sizes, resolutions, and refresh behavior already match the use case (a standard partial-refresh mode is fine, no special transitions or unusual aspect ratios needed).
- Timeline is tight enough that any custom engineering work would meaningfully delay deployment.
- The application doesn’t require integration with a specific existing CMS, fleet management system, or proprietary firmware behavior.
Customization starts to earn its cost once one of these breaks down — usually because the product needs to look like it belongs to your brand rather than a generic vendor, or because it needs to behave in a way standard firmware doesn’t support out of the box.
The Four Layers of Customization
1. Cosmetic and Mechanical
The most common and least expensive tier: housing color and finish, bezel design, front-panel branding, mounting hardware, and enclosure form factor. This is what most people mean by “OEM customization,” and it’s available from nearly any manufacturer — the barrier to entry here is low, so it’s worth expecting as a baseline rather than treating it as a differentiator when comparing suppliers.
2. Hardware Configuration
One level deeper: panel size and resolution selection, color vs. monochrome, connectivity module choice (Wi-Fi, 4G/cellular, or both), and power configuration (wired, battery, or solar-ready, as covered in our outdoor deployment guide). This tier requires a supplier that stocks or can source multiple module and panel options, rather than being locked into a single fixed configuration — worth confirming early, since some vendors’ “customization” stops at cosmetics and can’t actually swap the connectivity module or power setup underneath it.
3. Firmware and Software Behavior
This is where customization starts to require real engineering capability rather than just a parts catalog: custom boot logos, CMS integration with a specific content management platform, update-trigger logic (scheduled vs. event-driven refresh), and UI behavior tailored to a specific deployment. A supplier that can only offer their own fixed CMS, with no ability to integrate with a customer’s existing system, is effectively capping customization at this layer even if they claim otherwise.
4. Driving Electronics and TCON-Level Customization
The deepest and least commonly available tier: actual changes to how the display is driven — refresh waveform tuning, custom partial-refresh transition effects, and driver-board-level engineering rather than firmware configuration on top of a fixed board. This is genuinely rare, because it requires in-house TCON design capability rather than integrating a third-party driver board (see our explainer on what a TCON actually does for background, and our TCON mainboard product line if you’re sourcing the board itself). It’s also where the most meaningful differentiation in a finished product actually lives — two displays using an identical panel can behave very differently depending on what’s happening at this layer, which is the basis of MyGica’s own custom TCON work on partial-refresh transition effects.
Matching the Layer to the Actual Need
A practical way to scope a customization conversation with a supplier: identify which layer your requirement actually lives in before asking “can you customize this.”
| What you need | Layer | What to ask a supplier |
|---|---|---|
| Branded housing, specific color/finish | Cosmetic | Turnaround time, minimum order for custom tooling |
| Different size, connectivity, or power setup than the standard SKU | Hardware configuration | What panel/module options they actually stock or can source |
| Integration with your existing CMS or fleet software | Firmware/software | Whether their firmware is open to third-party integration, or locked to their own platform |
| Custom refresh behavior, transition effects, or unusual display geometry | TCON/driving electronics | Whether they design their own TCON in-house, or integrate a third-party driver board |
Most vendors can genuinely deliver on the first two layers. Firmware-level customization narrows the field. TCON-level customization narrows it further still — and it’s worth asking directly rather than assuming, since “customizable” on a spec sheet doesn’t tell you which of these four layers it actually applies to.
FAQ
What’s the difference between OEM customization and just picking configuration options?
Configuration options (size, color panel vs. monochrome, connectivity module) are typically available across a supplier’s existing product range without new engineering work. True customization — firmware behavior, CMS integration, or driving-electronics changes — usually requires dedicated engineering effort and is a meaningfully different conversation with a supplier.
Do all e-paper manufacturers offer TCON-level customization?
No — this requires in-house driver and timing-controller design capability, which most suppliers don’t have; many integrate a third-party driver board and can only adjust what that board’s firmware already exposes.
Is cosmetic customization enough for most projects?
For many deployments, yes — if the standard hardware configuration and firmware behavior already fit the use case, cosmetic customization (branding, housing, mounting) may be all that’s actually needed. It’s worth confirming this before assuming deeper customization is required.
How do I know which layer of customization my project actually needs?
Start from the requirement, not the display: if the issue is how the product looks, it’s cosmetic; if it’s what specs it has, it’s hardware configuration; if it’s how content is managed or updated, it’s firmware; if it’s how the screen physically refreshes or transitions, it’s TCON-level.