E-ink adaptive UI toolkit & e-ink-first web frontends
Problem
E-ink phone/tablet adoption is growing (Bigme, Boox, Daylight), but modern web and AI apps are nearly unusable on e-ink screens: streaming LLM output causes constant flashing refreshes, ghosting makes scrolling miserable, and there are no accepted UI conventions for grayscale, high-contrast, slow-refresh displays. A developer who switched to an e-ink phone found that even browsing HN is painful and had to build his own Lemmy and OpenRouter frontends from scratch.
Opportunity
An open toolkit/framework of e-ink UI patterns (chunked rendering, pagination instead of scroll, ghosting-aware refresh control) plus ready-made e-ink-first frontends for popular services (news readers, LLM chat clients). As e-ink device sales grow, the software ecosystem gap becomes a real market.
Market analysis
The ecosystem gap is real and barely contested: searches surface device-specific apps (EinkBro, vendor reading apps) but no general e-ink UI toolkit or framework, so a first-mover could genuinely set the conventions. The catch is that the market is a small hardware niche and refresh control is fragmented across vendor-specific Android forks (Boox, Daylight, Bigme each expose different refresh APIs), so a solo builder signs up for per-vendor maintenance forever.
Market · Niche but growing: e-ink power users and developers who own Boox/Daylight/Bigme devices and want real web/AI apps on them; strong word-of-mouth demand in HN/e-ink communities, weak purchasing power.
Pricing · Open-core is the realistic path: free toolkit/components to become the standard, paid polished frontends (LLM chat client, news reader) as one-time purchases or small subscriptions ($3-8/mo), mirroring how EinkBro distributes free via F-Droid while vendors monetize hardware.
Pros
- + Genuine whitespace: no general e-ink UI toolkit or framework surfaced in searches.
- + Authentic, vocal demand from early adopters who already build their own workarounds.
- + Toolkit + app combo builds an ecosystem moat if it becomes the default pattern library.
Cons
- − Small addressable market tied to niche hardware sales.
- − Refresh/ghosting control is vendor-specific; every supported device adds maintenance cost.
- − Open-source toolkits are hard to monetize directly; revenue depends on the frontends.
Existing / similar tools
Source
Hacker News (Ask HN)
The non-obvious risk here is that the hard 20% is not CSS but refresh control. Chunked rendering and pagination are straightforward web work, but eliminating flashing and ghosting means tapping into per-vendor display modes (Boox’s A2/refresh APIs, Daylight’s Live Paper), each undocumented differently — that is where a solo builder’s time disappears. The strategic play is to ship the frontends first (an e-ink-first LLM chat client is the killer demo, since streaming tokens are the worst-case scenario the source post describes) and extract the toolkit from what you learned. A toolkit with no famous app built on it gets ignored; a great app makes developers ask how it was made.