Our Patent-Pending Tech: Dynamic Text Rendering
Anna Danyi
1 November 20255 min read
Most growth teams still ship copy the old way: design a layout, hard-code the strings, rebuild when messaging changes. That works until you need ten variants by channel, cohort, or offer — then production becomes the bottleneck. We filed a UK patent application for a system that treats text and layout as something you can render dynamically, in real time, without forcing a full rebuild of every surface.
This post explains what UK patent application GB2639868 is about, how dynamic text rendering shows up in acquisition and retention work, and how to read a patent filing without treating it as a product brochure. We are deliberately precise: an application protects a technical approach; it does not, by itself, guarantee outcomes.
What GB2639868 covers (and what it does not)
Exp(G) has a published UK patent application — GB2639868 — for a system and method for dynamic text rendering. In plain language, the invention is about rendering text and related content in a way that can adapt in real time and along non-linear paths: what the user sees can change without a rigid, pre-built page for every combination of segment, offer, and creative state.
If you want to verify the filing yourself, start with the UK Intellectual Property Office and the official search-for-patent service. Public patent databases such as Espacenet and Google Patents are also useful for reading published specifications once you have the application number.
A few guardrails on language. A published application is not the same thing as a granted patent. Claims can be narrowed during examination. We describe the technical capability and the growth use cases we care about; we do not claim that every surface in every client stack already runs on this invention, and we do not claim that a filing alone improves ROAS. Patents protect methods. Growth still has to be measured.
Why dynamic text rendering matters for growth
Growth systems live or die on iteration speed. When every copy change needs a designer, a developer, and a release, you cannot run the volume of tests that modern auctions reward. Dynamic rendering shortens that loop: copy, offers, and micro-layout can update at the edge while brand constraints stay intact.
That maps cleanly onto work we already do in production growth stacks — landing experiences that adapt by paid channel or cohort, in-app messaging that updates without waiting for an app release, and creative systems that keep typography on-brand while varying hooks at scale. If you are building high-velocity creative pipelines, see how this sits next to our AI creatives production approach and the 60-day creative testing framework.
The practical win is not "AI wrote the headline." The win is control: you can change what a segment sees, keep measurement clean, and avoid shipping twelve nearly identical landing pages that rot the moment the offer changes. For web-to-app surfaces especially, message fit between ad and landing page is often the cheapest conversion lever left — see our web-to-app funnel guide.
Where we apply it in the funnel
- 01
Acquisition
Channel-aware headlines and offers on landing pages and custom store paths so the promise in the ad matches the first screen. Pair with Apple Custom Product Pages when the install still happens in the App Store.
- 02
Activation
Onboarding copy and paywall framing that can shift by acquisition source or early behaviour without waiting for a binary release.
- 03
Retention
In-product prompts and re-engagement surfaces that update when the offer or segment definition changes — useful when fatigue hits paid creative and you need the product side to keep pace, as in creative fatigue.
- 04
Experimentation
More variants per week with the same engineering budget, which is the real constraint behind most "we should test more" meetings.
Technically, teams often reach for canvas, SVG, or layout engines when they need precise control of type on the client. Specs such as the HTML canvas text APIs show how browsers expose low-level text drawing; our filing is about a broader system for dynamic, non-linear rendering in growth contexts — not a tutorial on `fillText`. The point for operators is simpler: messaging becomes a controlled input to the growth system, not a static asset buried in a release train.
How to evaluate claims like this as a buyer
If another vendor waves a patent number at you, ask three questions. First: is it an application or a grant, and in which jurisdiction? Second: what problem does the method actually solve in your stack — latency, variant volume, brand-safe personalisation, offline rendering? Third: can they show instrumentation that proves the dynamic surface moved a metric you care about (D7 ROAS, activation rate, payback), not just that the text moved on screen?
We hold ourselves to the same bar. Dynamic text rendering is infrastructure for faster, cleaner experimentation. It sits inside the wider Growth Engine loop: unit economics → creative velocity → measurement → weekly decisions. Sanity-check the economics side in the Payback Engine and ROAS calculator before you invest in more surfaces to personalise.
If you want a walkthrough of how we use dynamic rendering on live acquisition and retention surfaces — including what is patent-pending versus ordinary product engineering — book a discovery call. Bring one funnel and one bottleneck; we will be specific.
Sources & further reading
Anna Danyi
Founder at Exp(G) — building and scaling mobile apps with AI-powered growth systems. About the team