flagship field record
Attendance API & Product
I worked at TalkingPoints from 2022–2026. Each project lists its own dates, so some begin later within that span.
- Problem
- A new attendance product needed a stable data API while the product was still moving.
- My role
- Designed and built the API and its data contracts.
- Shipped
- A production FastAPI surface for attendance filtering, tardies, and interventions.
- Proof · 2026-07
- Enabled a new product vertical and held up under back-to-school traffic.
Public systems · Agent systems
A new attendance-product data surface built from scratch with typed contracts, streaming roster data, load testing, and an architecture that supported AI-assisted development.
Materials & technology
Links
Frequently Asked Questions
How do you design APIs for products that are still being defined?
Build for the known use cases, but design interfaces that can extend. The first version served dashboards and basic filtering. Later versions added tardy tracking and intervention cards. The architecture supported both because it was designed with change in mind.
How do you validate that an API is ready for production traffic?
Load testing with realistic scenarios. Not just 'can it handle N requests per second?' but 'can it handle the request patterns that back-to-school traffic actually generates?' Peak traffic isn't uniform—it spikes at certain times, certain endpoints get hammered.