Our work

We built the AI and ML pipeline that trains a model on H&E-stained cancer biopsy scans to predict a patient’s chance of responding to treatment.

Context

A European CRO working on cancer biopsies wanted to know whether the tissue itself carries enough signal to say, before treatment starts, which patients are likely to respond. The input is the routine artefact of any pathology lab: H&E-stained biopsy slides, digitised at high resolution. Nothing new is collected, which is what makes the question worth asking. If the answer is in material that already exists, the path from research to clinical use is much shorter than it is for a new assay.

Challenge

Three properties make this harder than a standard image task. A whole-slide scan is far too large to put in front of a model directly, so each slide has to be broken into tiles and the tiles reassembled into a single prediction per patient. The label does not live in the image: response is a clinical outcome recorded later, so every slide is weakly labelled and the model has to find the signal without being told where it is. And the number of patients is small even when the number of tiles is very large, which means a model can memorise the cohort long before it learns anything that transfers.

Approach

We built the pipeline end to end. Ingestion and quality control of the scans, tissue segmentation to drop background and staining artefacts, tiling with stain normalisation so slides from different scanners are comparable, feature extraction over the tiles, and an aggregation step that turns thousands of tile representations into one patient-level prediction. Splits are by patient and never by tile, so the same patient cannot appear on both sides of a split. The validation scheme and the reporting metric were agreed before training started. Data and code are pinned and every training run is recorded, so any figure in a report can be traced back to the run that produced it. The shape of the pipeline is the one this class of problem calls for: whole-slide image to tiles, a pathology feature encoder over the tiles, attention-based multiple-instance learning to aggregate them, and a biomarker prediction per patient at the end.

Outcome

The pipeline trains and evaluates a model that predicts response to treatment from the biopsy scan alone, and it does so reproducibly: the same data and the same code give the same numbers again. Validation is by patient-level cross-validation against a metric agreed before training, and the held-out split stayed untouched until the end. The work was scoped as a technical feasibility study, and we publish no performance figures from it.

Stack

Python throughout, with versioned data, pinned dependencies and recorded experiment runs. The partner holds the code, the model weights and the full training record, and can retrain without us.

We designed the setup and the concept for a joint venture in health real-world-data research, covering structure, scope and operating model.

Context

Real-world data in healthcare is valuable to research and awkward to organise. The data sits with the organisations that generate it in the course of care, the research questions sit elsewhere, and no single party can act alone without taking on risk the others would rather share. A joint venture is one answer to that: a separate entity with its own mandate, into which each partner contributes something it already has. Our client asked us to design that entity before committing to it.

Challenge

The hard part of a joint venture is not the idea, it is the set of questions that have to be answered in the right order. What exactly does the venture do, and what does it deliberately not do? What does each partner contribute, and what does each one get back? Who decides what, and what happens when the partners disagree? How does data reach the venture without any partner losing control of it or its own compliance position? Answer those late and the venture is renegotiated after it launches, which is expensive and usually fatal.

Approach

We worked the design from the research questions backwards. First the scope: which questions the venture exists to answer, and which adjacent ones are out of bounds. Then the contribution model: what each partner brings in data, access, capability and funding, and what a fair return looks like on each. Then the operating model: how a study is proposed, approved and run inside the venture, who staffs it, and how results are handled. Governance came last, because governance is a description of decisions already understood rather than a substitute for making them. Every option was written down with its consequence, so the partners were choosing between documented alternatives rather than reacting to a recommendation.

Outcome

The client received a written setup and concept for the venture: scope, contribution model, operating model and governance, with the open decisions named as decisions rather than buried. It is a document the partners can negotiate against.

Stack

No software. The output is written work: the venture strategy, the scope and remit of the venture, the roles and contributions of each party, a scoping of the business opportunity, and the structuring of a term sheet, each with the reasoning that produced it.

We built the control plane that runs coding agents against real repositories as durable, sandboxed, reviewable work — and we run our own delivery on it.

Context

Coding agents can write code. That is no longer the hard part. The hard part is everything around them once more than one is running against a real repository: an agent that can be interrupted loses hours of work, two agents in the same checkout overwrite each other, and an agent with push access to a main branch is a liability nobody in an engineering organisation will accept. Most teams answer this by keeping agents in a toy corner where they cannot do damage, which also means they cannot do work. We wanted the other answer — agents pointed at production repositories, with the constraints that makes necessary built into the system rather than into the prompt.

Challenge

Four properties have to hold at once, and each one rules out the obvious implementation. Long-running work has to survive interruption, so a run cannot be a process that dies with its terminal. Concurrent attempts have to be genuinely isolated, so they cannot share a working tree. An agent must not be able to reach past the task it was given, so file and network access have to be bounded by something stronger than instructions. And the output has to arrive as a proposal a human can reject, not as a change already applied — which means the system needs a publishing step that is structurally incapable of writing to a branch directly.

Approach

We built it as a control plane rather than a wrapper. Work is modelled as sessions and tasks that hold their own saved context, stop and resume on demand, and become immutable once complete, so a record of what an agent did cannot be edited after the fact. Each attempt runs in its own git worktree against a repository pinned on first access, so concurrency is a property of the design instead of a discipline. Execution is sandboxed with Bubblewrap, which bounds the filesystem without requiring container privileges on the host. Model access sits behind one connection abstraction, so the provider and thinking level are a configuration choice rather than a rewrite. Publishing is restricted to draft pull requests behind an approval gate: the system has no path that pushes to a branch. Per-repository check workflows run as the evaluation harness, and the whole thing deploys through its own CI quality gates to a private server reachable only over a private network, with browser pairing for access.

Outcome

The control plane runs, and we run our own delivery on it — it is the system behind the engineering we do for clients, not a demonstration built to be shown. It ships through the same gates it enforces: quality checks, then deploy. Because it is internal infrastructure rather than a product with customers, we publish no throughput, adoption or productivity figures for it. What we will say is architectural, and it is the part that transfers: durable runs, isolated workspaces, bounded execution, and a publishing step a human has to agree to.

Stack

TypeScript on Node, with Fastify serving the versioned API and the production interface from one process, and a React and Vite front end. Bubblewrap for sandboxing, git worktrees for isolation, systemd for service management, private HTTPS over a mesh network, and GitHub Actions for the quality-gated deploy. Architecture decisions are recorded as ADRs in the repository.

We defined and built a dance-course platform end to end — product design, information architecture, mobile app, admin, API and infrastructure — replacing an earlier prototype entirely.

Context

Dance is one of the few things people genuinely learn from short video, and one of the worst things to learn from it: the format is built for watching, not for practising. The product idea was to take the pull of that world — teachers people already follow, choreography they already want — and put it on a structure that actually teaches, with courses, lessons, progress and a subscription behind it. An earlier prototype existed as four separate applications. It had proved the demand and roughly the shape, and it could not become the product; it was a sketch that had been asked to carry weight.

Challenge

The work was not a port. The product had to be defined before it could be built: what a course is, what a lesson is, how a teacher is credited when several of them appear in one course, what a subscriber is entitled to and when that entitlement is checked, what happens offline, and what an editor does all day to keep content flowing. Underneath that sat a hard engineering constraint. Nothing in the prototype could be trusted for the parts where being wrong is expensive — authentication, sessions, payment, entitlement, upload, transcoding, storage, tokens, API clients, state and the database schema all had to be built again rather than carried over, and that had to be a rule the team could not quietly break under deadline.

Approach

We started with the information architecture, because the prototype’s model was the thing most likely to be inherited by accident. Its vocabulary flattened teaching into a single level; we rebuilt it as courses containing lessons, with teachers credited many-to-many so a course can legitimately have more than one, and legacy identifiers preserved so existing content could migrate rather than be retyped. Then we built in numbered vertical slices, each carrying its own spec, plan, task list and review, and each ending in something usable rather than a layer: catalogue and publishing first, then reading surfaces, then authentication and onboarding, then billing and entitlement, then signed playback and the learning loop, then progress, saves and offline, then account lifecycle, then admin operations, analytics and release readiness. Video playback is signed only through the API, so signing credentials never reach a client. Both environments are defined in Terraform, and each platform has its own continuous integration.

Outcome

The client has the product defined and built end to end: a mobile app, an admin and account web application, an API and a worker service, infrastructure as code for staging and production, and test suites across all of it. The prohibition held — none of the prototype’s sensitive code survived into production. At handover the remaining launch items were external and commercial rather than technical: production cloud project, store accounts and the first content drops. We describe it as built and launch-ready, because that is what it is.

Stack

A pnpm monorepo: Flutter for mobile, Next.js for admin and account web, and two Cloud Run services for the API and background work. Terraform for staging and production, Mux for signed video playback, RevenueCat over Apple and Google in-app purchase for entitlement, product analytics, and continuous integration per platform including mobile release builds.

Femy is our own app for hormones, menopause and longevity. Its editorial standard is enforced by the build: an article without enough dated, resolvable sources does not compile.

Context

Consumer health content is mostly unsourced, and women’s health is where that costs the most. Hormones, cycles, menopause and longevity are the topics with the widest gap between what is established, what is promising and what is simply being sold — and the reader has no way to tell which one they are looking at. We build Femy ourselves, which meant we could decide what the standard was going to be before writing a line of content, rather than negotiating it later against a publishing deadline.

Challenge

An editorial standard that lives in a style guide decays. It survives the first month and then erodes under the ordinary pressure of shipping, because nothing stops anyone from skipping it. We wanted a floor that could not be skipped at all. The second problem pulls the other way: content that reads like a literature review does not get read. The prose had to stay plain and usable, which meant credibility could not come from stacking journal names into the sentences — it had to come from somewhere the reader could check without being made to wade through it.

Approach

We put the floor in the type system. Every library article validates against a content schema that requires a minimum number of references, and each reference must carry a title, a publisher, a resolvable URL and the date it was accessed. An article that does not meet this does not build. The access date is mandatory for a stated reason: an undated citation cannot be re-checked, which is the entire point of publishing the list. We put the rule in the build rather than in a linter because a lint step can be forgotten and a failing build cannot. Behind the published articles sit research briefs that grade each claim by strength of evidence, source article-level claims to PubMed with identifiers and DOIs, link guidance to its primary publication, and say plainly which popular supplements are marketing rather than medicine. Those briefs are also where retractions get caught: one 1993 case series was identified as retracted and deliberately excluded rather than quietly inherited from a secondary source. In-app lessons keep a credibility floor of their own — at least one named institution, never none.

Outcome

Femy is live on the App Store, and the content pipeline behind it fails the build rather than the reader. We are precise about what this is: evidence discipline, not clinical review. There is no physician sign-off behind the app, it does not integrate with platform health data, and it states in the product that it is educational and not medical advice. What it demonstrates is that an evidence standard can be made mechanical — and that once it is mechanical, it holds under deadline.

Stack

Flutter on iOS, with Firebase for authentication, data and messaging, a paywall and subscription layer, and error and product analytics. The public content site is built with Astro over schema-validated MDX, which is where the reference floor is enforced. Unit and widget tests cover the subscription, authentication, content-sync and onboarding-scoring paths.

We designed the venture concept for a computational drug-discovery service and trained the model underneath it — a repurposing pipeline that has to re-find known medicine before its novel output counts.

Context

There are thousands of rare diseases and very few programmes aimed at any one of them, because the economics of a new molecule do not work at that population size. Repurposing changes the arithmetic: a compound that already exists, and whose safety profile is already characterised, starts much further along. The question is which compound, and the space is far too large to search by reading. This was a venture concept in two halves, and both had to hold — whether the commercial opportunity was real, and whether the models could actually do the thing the opportunity depended on.

Challenge

A model that ranks plausible-looking molecules is worth nothing. It will always return something, the something will always look reasonable, and there is no way to tell from the output whether the system found signal or produced fluent noise. Two things have to be true before any novel candidate deserves attention. The pipeline has to re-find medicine that is already known to work, on diseases where the answer is established, as a grounding test it can fail. And something inside the pipeline has to be structurally adversarial — a step whose job is to reject candidates rather than to produce them, because a generator scoring its own output is not a check. Underneath both sits a duller constraint that decides whether any of it can be commercialised: public biomedical data carries wildly varying licence terms, and a result assembled from a source that forbids commercial use is not a result.

Approach

We built and trained the pipeline as staged phases, each recording its own metrics. Candidate generation runs graph machine learning over a knowledge graph assembled from public biomedical sources — targets, trials, variants, chemistry, genetics and their known relationships. Every source and every edge is tagged for licence risk, and a gate excludes restricted sources from production scoring, so provenance is enforced rather than remembered. Generated candidates then pass to an adversarial verification phase, followed by transcriptomic validation using a foundation model over expression signatures, and structural validation for the survivors. Each run writes a manifest — dataset version, configuration hash, model version, licence snapshot — so any figure can be traced to the run that produced it, and per-phase metrics record how many candidates entered, how many were filtered and what the step cost. For the grounding test we ran diseases with established treatment: on Crohn’s disease and on Gaucher disease the pipeline surfaced known first-line drugs well inside the thresholds set in advance, with Gaucher’s best-known treatment ranking first.

Outcome

What exists is a trained, reproducible pipeline with its run history intact, together with the venture concept it was built to test: scope, service model, commercial framing and a licence audit covering the open-source components the pipeline depends on. The negative results were kept rather than tidied away — in one recorded run the adversarial phase rejected every one of the twenty candidates it received, which is the verifier doing its job and the single most useful thing in the log. The scope is computational screening. There is no wet-lab work and no clinical validation behind any of it, and a ranked candidate is a hypothesis for someone with a laboratory, not a finding.

Stack

Python throughout. Graph machine learning for link prediction over the knowledge graph, a transcriptomic foundation model for signature validation, structure prediction and docking for the deep-validation phase, serverless GPU for the heavy steps, and local analytical storage for the graph and results. Licence ledger, run manifests and per-phase metrics are part of the pipeline rather than reporting bolted on afterwards.

A system that takes a technical problem and returns an invention brief whose every claim is cited — with a prior-art search and a critic loop standing between the idea and the output.

Context

Research and development teams do not have an idea shortage. They have a triage problem: ideas arrive faster than anyone can establish whether they are new, and engineering time gets spent on things that turn out to be patented, published or quietly abandoned by someone else a decade ago. The interesting question is whether that triage can be run as a process rather than as an afternoon of someone senior reading patents — and whether an agent can do the reading without producing confident nonsense.

Challenge

A language model asked to invent will invent, fluently and without hesitation, including things that already exist. Fluency is the failure mode, not a side effect: the output is most convincing exactly where the model is reconstructing something it has seen. So the system cannot be a prompt. It needs to reach real patent and literature sources rather than recall them, it needs somewhere to put evidence so a claim can be traced to a source instead of asserted, and it needs a step whose purpose is to attack the idea. A generator that also grades itself will pass itself every time.

Approach

The system runs as a pipeline with a supervisor over it. A problem brief produces candidate ideas; each candidate goes out to prior-art search against patent and research sources through real connectors; a critic and validator loop then attacks what came back, and only what survives becomes an invention brief with its claims cited. Structured inventive variation — the TRIZ method of applying known transformation patterns to a contradiction rather than freely associating — gives the generation step something better than blank-page brainstorming. We built it in phases, each with its own database migration and its own API test suite, in an order that put the memory before the reasoning: artifacts first, then a run event stream, then evidence sources as first-class records, then orchestrator runs, then the supervisor loop on top. Evidence being a record rather than inline text is what makes the final brief checkable — every claim can be walked back to the source that supports it.

Outcome

The system works end to end: a problem goes in, a cited invention brief comes out, with the prior-art searches and the critic’s rejections preserved in the run so the reasoning can be audited rather than trusted. It was built as internal research and development, and it has not been operated as a service — there is no deployment behind it and no user base to cite. What it demonstrates is a method: agentic research that has to ground itself in retrievable sources and survive something adversarial before its output is allowed to count.

Stack

Python and FastAPI with versioned Alembic migrations, a conversation orchestrator graph driving the phases, and a Next.js front end. Patent search and research connectors for prior art, a query planner over them, and test suites on both sides — pytest against the API phase by phase, and component tests on the web application.

A structured fourteen-day venture-validation sprint, redesigned so a conversational agent runs the method with the founder instead of handing them a workbook.

Context

Founders validate badly, and not because they lack frameworks. The frameworks exist, they are good, and they sit unfinished because a validation sprint is a fortnight of unglamorous work that competes with the far more appealing option of building the thing. Everyone who has run one knows the pattern: strong on day one, honest on day three, abandoned by day six with a half-filled canvas nobody reopens. The method is not the missing piece. Someone to run it with you is.

Challenge

Turning a method into software normally produces a workbook with a login, which fails for exactly the reason the paper version fails — it waits for the founder to supply the discipline. An agent-led version has to do the opposite and hold the structure itself: know which phase of the sprint it is in, reach for the right instrument at the right moment rather than offering a menu, and be willing to say that an answer is not good enough to move on yet. That last part is what makes it a validation sprint rather than a conversation. And it has to do all this with tools that produce checkable output, because a market size an agent improvises is worse than no market size at all.

Approach

We designed the product as a conversational agent over a catalogue of phase-specific tools, rather than as an interface of forms with assistance bolted on. The fourteen days are modelled as phases — discovery and research, ideation, validation, analysis — and each phase makes a specific set of tools available rather than exposing everything at once, so the structure of the method is carried by the orchestration instead of by the founder’s willpower. Each tool is defined with a typed parameter schema: market sizing that asks for industry and geography and returns addressable, serviceable and obtainable figures with its working shown; persona definition; competitive and positioning analysis; validation design. Typing the tools is what keeps the agent honest, because a call with missing or malformed parameters fails rather than being improvised around. We also wrote the migration path explicitly — how a form-first application becomes an agent-led one without throwing away the data model underneath it.

Outcome

The deliverable is the product defined end to end: the sprint method expressed as a phase model, a full tool catalogue with typed definitions and worked implementations for each instrument, an architecture for the orchestration, and the migration route from the existing form-based build to the agent-led one. It is the design half of a venture done properly — the part that decides whether the thing is worth building, written down at the level of detail where that question can actually be answered.

Stack

TypeScript throughout: a Next.js application over a Supabase backend for data and identity, background jobs for long-running research steps, and typed tool definitions for agent tool-calling, specified per instrument with parameter schemas.