We build with AI.

What we build

1. Custom connectors.A connector for a system that doesn't have one yet. The ones we've built and run are on Connectors.For Icelandic Glacial we built two, which put Vividly and Kuebix inside Claude for the finance and logistics teams.

   ClaudeCustom connectorKuebix

   Two Kuebix lookups through the custom connector, then Claude's answer.

   Where's shipment SAMPLE-1042, and can you pull its bill of lading?

   Kuebix · shipment lookup Kuebix · bill of lading

   SAMPLE-1042 is in transit and on schedule.

   Carrier

   Example Freight Co.

   Picked up

   Warehouse A, Tuesday

   Delivery

   Customer DC, Thursday (estimated)

   Bill of lading

   BOL-000123, attached

   Ask about a shipment

2. Apps and tools.A working app where a manual routine is slowing the team down.For Lone Star Attorney Service, an onboarding app that files the paperwork and creates the ServeManager and Ramp records.

   New application Example Process Serving LLC · Sam Sample Harris County · W-9 attached

   Onboarding app Done

   • Files the application and W-9Drive
   • Logs the applicantTracking sheet
   • Sends the welcome emailGmail
   • Sends the Harris County Ramp instructionsGmail
   • Alerts the intake mailboxGmail
   • Creates the company recordServeManager
   • Creates the vendor recordRamp

   Left for the team: about a minute of review.

What we build with

The developer tools we build with, picked by where the system has to run.

• Claude Code. Where we write and test the code. Lone Star's onboarding app was built in it.
• MCP. The open standard Claude uses to reach other systems. Each custom connector is a remote MCP server; Icelandic Glacial's two run on Google Cloud.
• Claude Agent SDK. Claude Code's tools and agent loop as a Python or TypeScript library, for an agent that runs inside an application you operate.
• Client SDK. Direct calls to the Claude API, for a step inside your own software.
• Managed Agents. An agent Anthropic hosts, in its cloud sandbox or one on your own infrastructure.

How a build runs

1. Scope it on the first call. One workflow or one team, and what "working" means for it, agreed before we build anything.
2. Start on site. We set up inside your own accounts with your IT, and watch the work before we build. At Lone Star the first day on site went to shadowing the team.
3. Build on your real inputs. Your documents, your data, your edge cases, in a handful of long working sessions with a short check-in each week, so you see it running well before it's finished.
4. Train your team before it goes live. Every build includes the training.
5. Keep building. The first system usually shows you the next one. We keep improving it with your team.

What "tested on your real work" means

Not sample data. At Icelandic Glacial, the Kuebix connector went live on July 31 for freight quotes, shipment lookups, bills of lading and tracking, and within a week the finance team was using it alongside NetSuite and Vividly. Lone Star's onboarding app went live in late June on real applications, and by mid-July Soha Jivani put her time per server at "a minute per job, max." If it doesn't hold up on your data, it isn't done.

What you hold

Terms for custom connectors and apps are set in the proposal. The skill libraries, prompt libraries and user guides that come with them are yours outright. Your team is trained on what we build before it goes live, and we keep building from there.

Built so far

A bottled-water company went from scattered Claude accounts to one company-wide workspace, with NetSuite, Vividly and Kuebix connected. Case study

A Houston process-serving firm retired a 12-step manual onboarding routine for an app built with Claude. Case study

Questions