Field notes from the people who build

PrivacySeptember 22, 20266 min read

Privacy by design: a practical checklist for product teams

Modern privacy laws such as the EU’s GDPR, California’s CCPA and similar laws elsewhere share a common idea: privacy should be built into products, not added afterwards. Legal teams usually own the policies, but many of the obligations end up on the product backlog.

Here’s the checklist we work through with clients.

1. Privacy by default

Ship with the most privacy-protective settings switched on. Features that identify, locate or profile a person should be off until the user turns them on, and the user should be told what each one does.

• Audit every toggle, tracker and analytics SDK in onboarding.
• Make sure location, personalization and profiling start disabled.
• Make sure your cookie banner offers a real “decline” option, not just “accept”.

2. Privacy impact assessments

Run an impact assessment before building or overhauling any system that handles personal data, and before sending data to new vendors or regions. That includes most cloud and AI providers.

• Add an assessment step to your definition of ready for features that touch personal data.
• Keep an up-to-date inventory of where data flows, including LLM providers and their regions.

3. Automated decisions

If a decision about a person is made entirely by software, many regulations require you to tell them, explain the main factors behind it and offer a human review.

• Log the inputs and the model or rule version behind every automated decision.
• Design a clear path for users to request a human review.

4. Consent, portability and incidents

• Consent should be clear, informed and requested separately for each purpose. Bundled checkboxes rarely qualify.
• Data portability: users increasingly have the right to export their data in a structured, commonly used format. Build the export before someone asks for it.
• Incidents must be recorded and, if serious, reported to regulators and the people affected within strict deadlines. Make sure your logging can tell you who was affected.

Most privacy compliance work is good product hygiene: know your data, default to privacy and explain your decisions.

This article is general information, not legal advice. Work with qualified privacy counsel on your specific obligations.

AISeptember 9, 20267 min read

Agentic AI in production: five lessons from shipping real agents

Agents are LLM systems that plan, call tools and act for a user. They’ve moved from conference demos into real back-office workflows. Here’s what we’ve learned taking them to production for clients in insurance, logistics and the public sector.

1. Write the evaluations before the prompts

Before anything else, collect 50–200 real examples with your domain experts and agree on what a correct outcome looks like. That evaluation set becomes your spec, your regression suite and your answer when someone asks, “Is it good enough?”

2. Keep tools narrow and well described

A tool called run_sql invites trouble; get_open_claims_by_region doesn’t. Small, single-purpose tools with clear names, strict input schemas and least-privilege credentials are easier for models to use correctly and easier for you to audit. Exposing them through the Model Context Protocol (MCP) lets you reuse them across agents and model vendors.

3. Put a person in front of anything irreversible

Reading data is cheap; sending payments, emails or regulatory filings isn’t. We classify every tool as read-only, reversible or irreversible, and the irreversible ones need human approval. The agent drafts and the person signs off, which makes rollout much easier to approve.

4. Trace everything

Record every step: the plan, each tool call, its inputs, outputs, latency and cost. When a user reports a strange answer, you need to replay exactly what happened. Traces also show you where to cache, where a cheaper model is good enough and which tool descriptions confuse the model.

5. Budget for cost and latency from day one

Agents loop, and loops cost money. Set per-task limits on tokens, tool calls and wall-clock time. Route simple steps to smaller models. Our production agents typically cost cents per task, but only because we designed for that from the start.

The best agents we’ve shipped are the least impressive in a demo. They’re narrow, observable and boring in the best sense.

TeamsAugust 27, 20265 min read

Distributed engineering teams: the time-zone math

When companies compare engineering partners, the hourly rate tends to dominate the spreadsheet. The number that drives delivery speed is a different one: how many working hours your teams share.

Counting the overlap

Take a product team working a standard 9-to-5 day. Here’s how much of that day a partner team shares, depending on how far apart you are:

• Same time zone: all 8 hours.
• 3 hours apart: 5 hours.
• 6 hours apart: about 2 hours.
• 9 or more hours apart: little or no overlap during a standard day.

Why overlap matters more than rate

Software delivery is full of small questions: a clarification on acceptance criteria, a code review, a failing test that needs context. With shared hours, each question is answered in minutes. Without them, each one costs a full day.

Suppose a feature needs six such round-trips. With full overlap, that adds a few hours. With none, it can add six working days. Across a quarter of sprints, those delays easily outweigh a lower hourly rate.

Making distributed teams work

• Guarantee a core window: agree on at least four shared hours for standups, pairing and reviews.
• Write things down: clear tickets, decision records and recorded demos reduce the questions that need a live answer.
• Meet in person: a kickoff and regular on-sites build the trust that makes remote work smooth.
• Plan for holidays: share calendars early so releases don’t land on someone’s day off.

The cheapest hourly rate is rarely the cheapest way to ship. For product teams that need to move quickly, shared hours usually pay for themselves.