England, United Kingdom
AI development for Cambridge teams, handed over in writing
Magic Ship is an AI development agency in Vancouver, British Columbia. Cambridge and Vancouver share no working hours at all, and that is stated up front because it changes how the work runs: written handoff at the end of each side's day, a loop that turns once every twenty-four hours, and nobody waiting on a meeting.
- base
- vancouver, bc, canada (UTC-08:00)
- market
- Cambridge, United Kingdom
- your clock
- UTC+00:00 (Europe/London)
- overlap
- none on the same date, written handoff instead
- presence
- remote only, no office in Cambridge
No shared working day, so the loop is written
Cambridge is 8 hours ahead of Vancouver. When we start at 09:00 it is 17:00 on the same day for you, and when we stop at 17:00 it is 01:00 on the next day. On the same calendar date there is no hour where both sides are at work.
Removing the shared hour removes the interruptions with it. A full Vancouver day of uninterrupted build time, handed over in writing, tends to move a project further than a day punctuated by four calls.
- A handoff note goes out at the end of every Vancouver working day: what shipped, what broke, and what needs a decision from you.
- You read it at 01:00, or whenever your day starts, and review the pull requests it points at.
- Decisions are logged as they are made, in the repository, so neither side has to reconstruct why something was done.
- A blocking question arrives with a proposed answer attached, so the default outcome is progress rather than a stalled day.
One live call a week, and it is scheduled honestly: 09:00 in Vancouver is 17:00 in Cambridge. Neither side takes a bad hour for that one. The call simply lands on two different calendar dates, which is a scheduling detail rather than a hardship.
What Cambridge buyers usually bring us
The record for Cambridge lists two industries. Here is the part of each one that turns into an engagement, and the service line it lands under.
semiconductors
Verification and tooling repos are enormous and slow, so the first work is feedback speed and scoped rules, not a model upgrade.
Test generation is the usual first wedge: high value, low risk, and it shows exactly which parts of the codebase an agent cannot read.
Closest service line: Codebase and team optimization
biotech
Protocols, study reports and regulatory correspondence answer the same questions repeatedly. Structure-aware ingestion of the report format is most of the work.
Chunking follows the structure of the document instead of a character count, which is the whole difference between a useful index and an expensive one.
Closest service line: Knowledge bases and retrieval
Contracts, currency and where the data sits
Invoices are in pounds or US dollars, whichever your accounts payable prefers. UK GDPR applies to whatever we index, so storage region and log retention are agreed in writing before ingestion starts.
Everything downstream of that is deliberately unremarkable. Fixed acceptance criteria, weekly shipping, a written decision log, and a first reply that tells you if Cambridge work of this shape is not something we should take.
The five lines we sell
Same five lines everywhere, Cambridge included. Most engagements are one of them, sometimes two.
- AI products, built end to end
- Knowledge bases and retrieval
- Codebase and team optimization
- Training and enablement
- Forward-deployed engineering
The languages, models and infrastructure underneath all five are listed on the Magic Ship stack page, with what each one is good for and where it is the wrong choice.
Other markets in United Kingdom
Where else the same work happens in United Kingdom, with the numbers redone per market.
Start a project
Describe what is broken or what you want built. The reply comes from the engineer who would build it, and it covers scope, timeline and fit before anything else.