. * * window.aa needs to exist and be usable by ANY module's script, * however early it runs - main-nav's script, for one, runs near * the top of

91̽»¨

, well before the real search-insights.js * so the download * begins as early as before. Repeat calls share the same downloads, a * failed load is retried on the next call, and the versions / SRI * hashes live only here. * * Algolia Insights is unaffected: window.aa above is still created in * on every page and queues events until search-insights loads. * * window.loadAlgoliaLibs({ priority: 'high' }) (Oct 2026): used by the * /search page, where the first results wait on these libraries. Chrome * gives async scripts low priority, behind images and fonts; this asks * for high instead (fetchpriority). Only the first call for a library * sets its priority - later calls share that download. */ (function (win, doc) { var LIBS = [ { ready: function () { return !!win['algoliasearch/lite']; }, src: 'https://cdn.jsdelivr.net/npm/algoliasearch@5.52.1/dist/lite/builds/browser.umd.js', integrity: 'sha256-I2oYUIvhx1g6l4lTP+yoERbzLIHKzw4AKaBRQPwIeDY=' }, { ready: function () { return !!win.instantsearch; }, src: 'https://cdn.jsdelivr.net/npm/instantsearch.js@4.98.0/dist/instantsearch.production.min.js', integrity: 'sha256-ngmqZk4WBxUw257aMYZayyNBd983INngagv0jI6Ecfs=' } ]; function loadOne(lib, options) { if (lib.ready()) return Promise.resolve(); // One download per library, shared by every caller; reset on // failure so the next call retries just the library that failed. if (lib.pending) return lib.pending; lib.pending = new Promise(function (resolve, reject) { var script = doc.createElement('script'); script.src = lib.src; script.integrity = lib.integrity; script.crossOrigin = 'anonymous'; script.async = true; if (options && options.priority === 'high') script.setAttribute('fetchpriority', 'high'); script.onload = function () { lib.ready() ? resolve() : reject(new Error('Loaded but not available: ' + lib.src)); }; script.onerror = function () { script.remove(); reject(new Error('Could not load ' + lib.src)); }; doc.head.appendChild(script); }); lib.pending.catch(function () { lib.pending = null; }); return lib.pending; } win.loadAlgoliaLibs = function (options) { return Promise.all(LIBS.map(function (lib) { return loadOne(lib, options); })); }; })(window, document); . */ window.hsConversationsSettings = window.hsConversationsSettings || {}; window.hsConversationsSettings.loadImmediately = false; (function (win) { var EVENTS = ['pointerdown', 'keydown', 'touchstart', 'scroll', 'mousemove', 'wheel']; var done = false; /* 19 Oct 2026 - chat widget layout shift (field CLS). Phones fail Core Web Vitals on CLS (p75 ~0.2 site-wide in CrUX for months). Biggest cause found: HubSpot's chat container is fixed to the bottom-right corner and changes size - 100x96 launcher to 282x253 when the welcome message pops up (~5 s after load), and to full screen when a visitor opens the chat. Its top-left corner moves, so Chrome scores it as a layout shift: 0.088 per page view at 360x640 (0.044 at 412x850), on every page. Taps happen inside the chat iframe, so the parent page never sees the input and the open/close shifts count too. Fix: whenever the container's size changes it is made transparent for 400 ms (Chrome doesn't score shifts of invisible elements), then shown again at its new size. Tested on live io1001 at 360x640 in a cookie-less frame: the 0.088 shift no longer appears. The chat itself is unchanged - it just appears 0.4 s later at each resize. Relies on HubSpot's container id; if that changes this does nothing (no error). */ function cloakChatResizes() { var ID = 'hubspot-messages-iframe-container'; function watch(c) { if (c.getAttribute('data-bb-cloak')) return; c.setAttribute('data-bb-cloak', '1'); var last = c.offsetWidth + 'x' + c.offsetHeight, timer = null; new MutationObserver(function () { var size = c.offsetWidth + 'x' + c.offsetHeight; if (size === last) return; last = size; c.style.setProperty('opacity', '0', 'important'); clearTimeout(timer); timer = setTimeout(function () { c.style.removeProperty('opacity'); }, 400); }).observe(c, { attributes: true, attributeFilter: ['style', 'class'], subtree: true, childList: true }); } var found = document.getElementById(ID); if (found) { watch(found); return; } if (!document.body || !('MutationObserver' in win)) return; var mo = new MutationObserver(function () { var c = document.getElementById(ID); if (c) { mo.disconnect(); watch(c); } }); mo.observe(document.body, { childList: true }); setTimeout(function () { mo.disconnect(); }, 30000); } function loadWidget() { var api = win.HubSpotConversations; if (api && api.widget && api.widget.status && api.widget.status().loaded) return; try { cloakChatResizes(); } catch (e) {} if (api && api.widget) api.widget.load(); } function onFirstInteraction() { if (done) return; done = true; EVENTS.forEach(function (type) { win.removeEventListener(type, onFirstInteraction, { passive: true }); }); var start = function () { if (win.HubSpotConversations) loadWidget(); else (win.hsConversationsOnReady = win.hsConversationsOnReady || []).push(loadWidget); }; if ('requestIdleCallback' in win) win.requestIdleCallback(start, { timeout: 1500 }); else setTimeout(start, 200); } EVENTS.forEach(function (type) { win.addEventListener(type, onFirstInteraction, { passive: true }); }); })(window);

91̽»¨

Skip to main content
Therapeutics

Every cell type we create can give rise to multiple next generation therapies

Cell therapies that are accessible and affordable

We have the ability to create any human cell type and manufacture it with consistency at scale. This unlocks unparalleled opportunities in cell therapy.

The possibilities for novel cures are endless.

Solving the 'cell' problem with our cell coding platform

The biggest hurdle in cell therapy today is access to consistent batches of human cell types at scale. Therapeutic development needs trillions of cells at an affordable cost in order to generate medicines that are accessible to millions of patients. 91̽»¨â€™s cell coding platform is able to provide a source of defined human cell types that are inherently consistent and scalable. We believe that our approach also has the potential to reduce the cost of cell therapies by up to two orders of magnitude.  

 
custom-cells-half

Partner with us to develop human cells for your cell therapeutics

Therapeutic development and manufacture needs to scale to trillions of cells to generate enough doses of a therapy that can be deployed to millions of patients.

Our platform provides partners with the ability to create new, inherently consistent and scalable cell types to form the basis of a cell therapy. By solving the cell problem, our partners are enabled to shift focus from “How are we going to make enough cells to treat one patient?� to "How can we ensure our therapeutic can treat every patient?".

Business meeting-v2

News

bluerock and bitbio

Collaboration with BlueRock Therapeutics

In August 2023, 91̽»¨ announced a collaboration and option agreement with BlueRock Therapeutics for the discovery and manufacture of iPSC-derived regulatory T cells

MJFox and bitbio

Collaboration with The Michael J. Fox Foundation

Multi-year collaboration agreement with The Michael J. Fox Foundation (MJFF) to generate human cell products for research and drug discovery in Parkinson’s disease

Synthego and bitbio

Synthego and 91̽»¨ expand strategic partnership

To build a platform for the development of safer and more efficient genetic engineering of human cells for cell therapies

Ginko and bitbio

91̽»¨ announced as inaugural partner of Ginkgo's Technology Network

As a Network partner, 91̽»¨â€™s ioCells portfolio of human cells for research and drug discovery can be integrated into Ginkgo’s platform ecosystem

Related pages

Discover ioCells Learn about our range of human iPSC-derived cells for research and drug discovery
Our platform Discover the cell coding platform behind our cells
About us Find out more about us and our people