England, United Kingdom
AI development for Liverpool teams, handed over in writing
One shop, Vancouver, British Columbia. Liverpool sits on the other side of a full day, so nothing about this engagement runs on meetings. It runs on written handoffs, logged decisions and review that happens while the other side is asleep.
- base
- vancouver, bc, canada (UTC-08:00)
- market
- Liverpool, United Kingdom
- your clock
- UTC+00:00 (Europe/London)
- overlap
- none on the same date, written handoff instead
- presence
- remote only, no office in Liverpool
No shared working day, so the loop is written
Liverpool 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.
The honest version of this is a selling point. You get a full uninterrupted Vancouver day of work delivered as a written handoff, and we get your review waiting for us in the morning. Two shifts a day, no overtime.
- The Vancouver day ends with a written summary: shipped, broken, blocked, and the one thing we need you to decide.
- That summary is waiting at 01:00 your time, alongside the diffs it refers to.
- The decision log lives in the repository rather than in a chat thread, so it is still readable a year later.
- Anything that would block us gets asked as a proposal you can approve in a sentence, not as an open question.
One live call a week, and it is scheduled honestly: 09:00 in Vancouver is 17:00 in Liverpool. 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 Liverpool buyers usually bring us
The record for Liverpool lists two industries. Here is the part of each one that turns into an engagement, and the service line it lands under.
shipping
Vessel systems, port calls and documentation flows each need their own integration, built against live data and real timeouts.
Reconciliation and idempotency are designed in at the start, because retrofitting them after the first duplicate transaction is expensive.
Closest service line: Forward-deployed engineering
life sciences
Study documents, protocols and submissions have rigid structure, and honouring that structure at ingestion time is what makes retrieval accurate.
It starts with your documents and your own analysts writing the questions the system has to get right before anyone will trust it.
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.
Beyond that, the shape of an engagement does not change with distance: a scoping call, a thin end-to-end slice, then weekly increments against acceptance criteria fixed in advance. If we are not the right shop for Liverpool work, you get told that in the first reply rather than after a proposal.
The five lines we sell
Same five lines everywhere, Liverpool 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
Same treatment, different clocks, and in some cases a different answer.
Start a project
Send the problem. If it is a fit, you get scope and a timeline. If it is not, you get told that in the first reply instead of after a discovery process.