What we've shipped.

The situation

• Practice-management data arrived a day late, and integrations moved records without saying what had happened or why.
• Kafka was being used to store state, not to carry events, so nothing downstream could rely on it.
• Pet-owner PII and payment data moved through pipelines in clear text, with no data contracts and no tokenization.
• Four different ingestion methods, and no single place to see what was flowing where.

What we built, with their engineers in the code

1. 1

   Governed event spine

   One reliable stream of events, with contracts every producer and consumer has to follow: Confluent Kafka, Schema Registry, Avro, and a reference pipeline into Snowflake.

2. 2

   Tokenization at the source

   Pet-owner PII, veterinarian identifiers, and clinical fields become tokens before they leave the source system, using Google Cloud DLP with per-field methods and keys in Cloud KMS.

3. 3

   AI-enhanced SDLC

   A delivery process built for AI-assisted coding: machine-readable specs, generated tests and docs, and pre-commit guardrails. The client's engineers used it to build the second data product themselves.

4. 4

   Two data products

   A record-matching service (ours) and a recommendations writeback (theirs, built with that same process).

5. 5

   The use case on top

   Vets get each visit summary drafted for them, inside the system they already use. Built in ten weeks: four models evaluated for clinical accuracy, with role-based access and audit logging, on a foundation the security team had already approved.

The challenge

• Customers describe thread in their own words: a color, a weight, a material, what it's for. Matching that to the right product in the catalog was done by hand.
• Every quote meant someone searching a database of thousands of SKUs, so quotes were slow.
• The existing search only worked if you already knew the exact thread code or specification.
• The only way to handle more requests was to hire more support staff.

What we did

1. 1

   Learned how customers ask

   We studied the catalog, the sales process, and the words customers actually use: color names, end uses, and vague descriptions.

2. 2

   Turned plain English into a search

   We built a system that reads a customer's request and turns it into a precise database query, with the color and material matching rules built in.

3. 3

   Built the screens

   We built search and quoting screens for customers and for the internal sales team.

4. 4

   Tuned it and shipped it

   We tuned the ranking against past sales, checked precision on real customer requests, and launched it with a feedback loop so results keep improving.

The challenge

• The client ran its quarterly business review in several breakout rooms at once.
• They wanted each room's discussion captured and summarized while it happened.
• They wanted one plan for the whole group by the end of the session, not a week later.

What we built

1. 1

   Listens and transcribes

   The agent listens to each breakout room live and transcribes the discussion.

2. 2

   Summarizes each room

   When a room pauses, it pulls out the key themes and summarizes them, checked against the client's own documents.

3. 3

   Answers facilitators

   Facilitators can ask it how a room is going, by voice or by typing.

4. 4

   Builds one plan

   Before the session ends, it combines every room into a single set of headlines and recommendations. A facilitator reviews and edits everything before it's shared.