North Holland (NH), Netherlands
AI development for Amsterdam teams, handed over in writing
One shop, Vancouver, British Columbia. Amsterdam 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
- Amsterdam, Netherlands
- your clock
- UTC+01:00 (Europe/Amsterdam)
- overlap
- none on the same date, written handoff instead
- presence
- remote only, no office in Amsterdam
No shared working day, so the loop is written
Amsterdam is 9 hours ahead of Vancouver. When we start at 09:00 it is 18:00 on the same day for you, and when we stop at 17:00 it is 02: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.
- 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 02: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: 08:00 in Vancouver is 17:00 in Amsterdam. That hour is outside our working day and inside yours. We take the awkward end of it, because it is our job to be reachable.
What Amsterdam buyers usually bring us
The record for Amsterdam lists two industries. Here is the part of each one that turns into an engagement, and the service line it lands under.
financial technology
Core systems, ledgers and payment rails each carry their own auth, pagination and rate limits, and none of it survives being described in a prompt.
Progress is counted in deployments rather than features, which is the only honest way to measure this kind of work.
Closest service line: Forward-deployed engineering
logistics
Carrier APIs, warehouse systems and customer portals all break differently under load, which is why the integration work is the project.
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
Contracts, currency and where the data sits
Invoices are in euros. GDPR makes storage location a design question rather than a footnote, so the index, the logs and the model calls get pinned to European regions where your provider offers them, and that is settled in week one.
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 Amsterdam work, you get told that in the first reply rather than after a proposal.
The five lines we sell
Same five lines everywhere, Amsterdam 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 Europe
Each one has its own page, its own overlap arithmetic and its own industries.
Start a project
Write down the problem in whatever form you have it. You get a straight answer about scope, timeline and whether this is work we should be doing at all.