Tasmania (TAS), Australia
AI development for Hobart teams, handed over in writing
One shop, Vancouver, British Columbia. Hobart 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
- Hobart, Australia
- your clock
- UTC+10:00 (Australia/Hobart)
- overlap
- none on the same date, written handoff instead
- presence
- remote only, no office in Hobart
No shared working day, so the loop is written
Hobart is 18 hours ahead of Vancouver. When we start at 09:00 it is 03:00 on the next day for you, and when we stop at 17:00 it is 11: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 11: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: 15:00 in Vancouver is 09:00 in Hobart on the next day. 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 Hobart buyers usually bring us
The record for Hobart lists two industries. Here is the part of each one that turns into an engagement, and the service line it lands under.
antarctic research
Station logs, instrument records and cruise reports are the corpus. Structure-aware ingestion beats one more shared drive with a naming convention nobody follows.
Answers cite the passage they came from. A retrieval system without span-level citation gets used twice and then quietly abandoned.
Closest service line: Knowledge bases and retrieval
tourism
Availability, pricing and local knowledge have to come from your systems, because a model that improvises an opening time creates a support ticket.
Model choice comes last. Tool boundaries, the data model and the failure path are settled before anybody argues about which provider to call.
Closest service line: AI products, built end to end
Contracts, currency and where the data sits
Invoices are in Australian or US dollars. The engagement crosses a border and a date line, so payment terms and delivery dates are written with the date offset spelled out.
Everything else is the same as it would be for a client down the street from us: scope, a thin slice in week one, then weekly increments you can stop at any time. The distance changes the schedule, not the contract.
The five lines we sell
Same five lines everywhere, Hobart 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 Australia
Each one has its own page, its own overlap arithmetic and its own industries.
Start a project
Send the problem rather than a job spec. You get an answer on scope, timeline and whether we are the right shop, written by the person who would do the work.