Engagements that moved a number the client could point to.
A selection of our engagements to date. Client references on request.
We don't recommend and leave.
Most of these engagements began the way a rescue begins: an investment already made, a number it was supposed to move, and a gap between the two that nobody could explain. We diagnosed where the system actually stood, rebuilt it around the team that had to run it, and stayed until it held without us. The results below come from systems in live use.
Start where the value stalled
The first weeks go into the outcome you own and the process that produces it: who touches each step, where it leaks, what has been tried. That work decides every technical choice that follows — the tool comes last.
Stay until it moves the number
Deployment is the start of the hard part. We stay embedded through the first live cycles, when real data, real users, and real pressure expose what the pilot didn't, and don't call it done until the metric has actually moved.
Hand off a system the team can run
Every engagement ends with your team owning what was built. We design the improvement loop and the rhythm to maintain it before we leave, so the gain compounds after we're gone, with as little disruption to the wider team as the change allows.
One consistent pattern.
Five sectors with different problem statements. In every one, the model held up. What was missing was verification no one had built, adoption no one had designed, and information locked inside documents no software could read.
What our engagements delivered.
A selection of engagements across the practice — rescues, rebuilds, and systems built right the first time. Confidentiality is part of the service, so clients are anonymised.
"AI-native field service platform deployed, and quietly underused after configuration."
Pricing, onboarding, and customer success were built for traditional SaaS, and the AI features paid the price: features that improve through calibration cycles, sold as if they were one-off configuration.
AI-native field service software company · $12M ARR · 35 enterprise operators across telecoms, utilities, and infrastructure globally. The platform shipped with full AI capability. After 90 days, customers ran the basics and ignored the rest. The product worked. What was built for traditional SaaS (the pricing tiers, the onboarding, the customer-success motion) was throttling adoption and retention.
We rebuilt the pricing and retention motion around how the AI actually delivered value: calibration cycles, not configuration milestones. New packaging that paid for ongoing improvement, a customer-success motion mapped to those cycles, and engineering hours priced into the tier. The product evolved, as did the delivery around it.
We started in customer-success calls. The product team already had a working AI feature set; the retention motion around it was the constraint. Pricing, packaging, onboarding. That's where the work was.
"Each pharma RFP required three weeks and four people to respond to."
Win rate per bid was already strong; throughput was the ceiling. Four years of winning content existed but sat scattered across filings with inconsistent naming, so every tender rebuilt it from scratch.
Life sciences supplier · €160M revenue · 5-person BD team · 12 pharma procurement tenders per quarter. Responding to pharmaceutical procurement tenders was the highest-value commercial activity, and the most exhausting. The BD team spent weeks manually assembling proposal sections, hunting for quality documentation, and aligning regulatory language across submissions. The win rate per submission was strong; the throughput was the bottleneck.
We indexed four years of submissions, quality agreements, and regulatory filings into a knowledge base. When a new RFP arrives, an AI agent drafts compliant response sections (methodology, QA framework, compliance narrative) for the BD team to edit, not write. We stayed through two months of retrieval-quality calibration before the team trusted it without us.
The knowledge base was harder than the agent. Four years of regulatory filings with inconsistent naming. Data structure first, retrieval layer second, agent third, and two months of post-launch retrieval-quality calibration with the BD team.
"The most financially complex professionals have the least financial visibility."
Aggregation tools already handled the accounts that could be connected directly. The complex assets — equity plans, trust documents, private investments — lived in documents no tool read, and any AI reading them wrong would return a net-worth figure that looked exactly as trustworthy as a correct one.
A cross-border wealth platform engaged Raining Code to address a problem increasingly common among globally mobile professionals and affluent families: wealth held across multiple countries, currencies, and institutions: equity plans, real estate, retirement accounts, insurance policies, private investments, with no single tool that reflected the full picture. Research and user interviews identified where existing platforms fell short. Bank-integration tools handled liquid assets well. Everything else lived in documents, grant agreements, K-1 statements, property deeds, insurance schedules, trust documents, private investment reports: unstructured, heterogeneous, dispersed across inboxes and file systems. No existing tool read them. And a tool that reads them with AI carries a specific risk: a misread statement produces a net worth figure that looks exactly as trustworthy as a correct one.
The approachWe advised the founding team on an AI-native architecture where intelligence begins at extraction, before the point where conventional aggregation models hit their ceiling. Documents forwarded to a dedicated inbox, parsed across six document classes, feeding a unified portfolio view that conventional wealth tools cannot produce. Because every figure the platform shows sits downstream of that reading, extraction runs inside a harness. The AI reads a statement into holdings and does nothing else; plain arithmetic then checks the result against the totals the statement prints on itself, which the AI never sees. When the two disagree, the size of the gap says what went wrong — a missed holding, a flipped sign, a currency line — and sends that one line back to be re-read rather than the whole document. What still fails the check reaches a person with the gap already located. Privacy architecture was specified before any code: PII and financial data separated at the storage layer, the AI operating only against the financial side — identity-blind by design, not policy. No bank credentials. No custody model. No user data trains any model.
Research before architecture. Interviews established which document classes mattered and how they varied by jurisdiction and issuer before any system design began. The key finding — that existing tools were bank-integration limited, not AI-limited — reframed the problem from aggregation to extraction. Privacy architecture preceded the intelligence layer. Sequence: define the constraint, design the data foundation, then build the AI on top of it.
"Five-day quote turnaround losing deals to faster competitors."
The constraint wasn't effort or headcount. It was a quoting process that made a senior engineer redo the same SKU-matching, safety-data lookups, and pricing by hand on every one of ~120 monthly RFQs.
€120M specialty chemicals manufacturer · 8-person commercial team · ~120 RFQs per month. The commercial team produced quotes entirely by hand: matching product SKUs, pulling safety data sheets, applying pricing logic, formatting documents. A senior sales engineer averaged 4.5 hours per RFQ. The brand promised "applied chemistry expertise". The quote experience told buyers a different story.
We re-framed how the company sold, then built into it. An AI agent embedded in the sales motion, integrated into email and ERP, that parses inbound RFQs, matches product codes, applies customer-specific pricing rules, and drafts a complete technical quote with safety data and compliance references for KAM review. The narrative the brand was telling now matched what the buyer experienced.
Two weeks mapping the quote workflow before a line of code. The first working version ran alongside the manual process for three weeks. We stayed embedded until the team was confident enough to turn the manual process off.
"OEM volumes declining. Zero pipeline in new verticals. Brand stuck in automotive identity."
Brand, pitch, and BD motion still described an automotive supplier, while the buyers who mattered now were in medtech and aerospace. The capability to serve them already existed.
Tier-2 precision manufacturer · €75M revenue · family-owned · 3-person BD team. A Tier-2 automotive supplier was watching volume forecasts drop as EV transition reshaped procurement. They needed to diversify into medtech and industrial sectors, but the brand, the commercial motion, and the technical narrative were all built around being an automotive supplier. The capability was there. The market story wasn't.
We re-narrated the company around precision capability rather than the automotive sector, then built into the new story. AI-powered BD identifies companies in medtech, aerospace, and industrial sectors whose technical specs match the client's capabilities, drafts personalized outreach in German and English, and pre-qualifies inbound before it reaches the sales team. Brand work and commercial automation, shipped together.
Started as a CRM project. Shadowing the BD team, we learned most of their time went to qualification, not outreach. That insight rewrote the system. Three prospecting cycles of calibration got the precision to the threshold the team trusted.
"The model was confident enough to fill the gaps. In safety-critical equipment selection, that confidence is the problem."
The failure mode was invisible by design. Without structured catalog data, the model filled certification gaps with confident, plausible answers that looked identical to correct ones.
AI product recommendation demonstration — ATEX-certified industrial vacuum selection. General-purpose AI carries broad industrial knowledge. It knows what ATEX Zone 22 means, what Group IIIC conductive dust classification implies, and what an inert wet separator is for. What it cannot retrieve, without access to structured catalog data, is the certification status, engineering constraints, and configuration limits for a specific manufacturer's product line. In environments where an incorrect recommendation has safety and liability consequences, the gap between plausible and correct is the entire problem. Three test scenarios: flour dust in a bakery under ATEX Zone 22 continuous-duty conditions, titanium powder from an SLS 3D printer, a configuration comparison for two high-pressure vacuum units. Without catalog access, the model gave confident, broadly accurate answers that would have been wrong in ways no generalist would catch.
What we builtWe built a remote MCP server that exposes the product catalog to Claude as a live, structured knowledge base: specifications, certifications, engineering constraints, and configuration options, all machine-readable and queryable on demand. The model retrieves what it needs per query, cross-references certification requirements, and identifies what information is missing before committing to a recommendation. The behavioral shift was more significant than the accuracy improvement. With live catalog access, the model stopped filling gaps with plausible fabrication. For the titanium powder query it retrieved the Group IIIC conductive classification, identified material reactivity, and routed to an inert wet separator without prompt engineering directing it. For the bakery scenario it queried zone-certified continuous-duty units and asked for additional parameters before answering. The data structure did the reasoning work. The catalog is the harness here: a source of facts the model cannot invent, standing between a plausible recommendation and a shipped one.
Two earlier approaches used retrieval-augmented generation on unstructured product documentation. Neither produced reliable constraint reasoning — the model was reading prose descriptions of specifications, not typed fields it could reason over. The MCP server, built around a properly structured catalog with explicit certification and constraint fields, was the prerequisite. The behavioral change (fewer hallucinations, more questions) came from the data structure; no prompt instruction asked for it.
Every engagement starts with a diagnostic conversation.
Not a sales process. We'll ask where you are, tell you whether what you're trying to do matches what we do. If it doesn't, we'll say so before you engage on paperwork.
Schedule a callWe take a limited number of engagements, but only with executives who own the outcome.