Oklahoma (OK), United States
AI development for Tulsa teams, on your working day
Vancouver, British Columbia is where the work gets done, and Tulsa is one of the markets it gets done for. Nobody from this shop sits in Tulsa. The 6-hour daily overlap is what makes that a detail rather than a problem.
- base
- vancouver, bc, canada (UTC-08:00)
- market
- Tulsa, United States
- your clock
- UTC-06:00 (America/Chicago)
- overlap
- 6 hours a day, 09:00-15:00 in Vancouver
- presence
- remote only, no office in Tulsa
6 hours of your day, every working day
Tulsa runs 2 hours ahead of Vancouver. On a normal working day the two calendars overlap from 09:00 to 15:00 Vancouver time, which is 11:00 to 17:00 where you are.
With a window like that, most decisions never become documents. We review together, we cut scope together, and the written record exists for the archive rather than as the only channel.
The parts that still get written down are written down anyway: acceptance criteria, the decision log, and what changed in each weekly increment. A shared clock is not an excuse for an undocumented project.
What Tulsa buyers usually bring us
The record for Tulsa lists two industries. Here is the part of each one that turns into an engagement, and the service line it lands under.
energy
Operational data is high volume and low tolerance for a wrong answer, so the eval harness and the fallback behaviour get built before the interface.
We ship something narrow early and widen it, because scope found in production costs less than scope argued about in a document.
Closest service line: AI products, built end to end
aviation
Operational systems are old, strict, and unforgiving about rate limits and retries, which is precisely where embedded engineering earns its rate.
Integrations are validated against live traffic: auth, pagination, rate limits, retries, and the failure modes that only surface under real load.
Closest service line: Forward-deployed engineering
Contracts, currency and where the data sits
Invoices are in US dollars. A US buyer engaging a Canadian company is routine, and the form your accounts team will ask for is a W-8BEN-E, which we have ready before the first invoice.
Everything downstream of that is deliberately unremarkable. Fixed acceptance criteria, weekly shipping, a written decision log, and a first reply that tells you if Tulsa work of this shape is not something we should take.
The five lines we sell
Same five lines everywhere, Tulsa 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 States
Where else the same work happens in United States, 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.