CrewLog

Inspiration

You pay a contractor $40,000 for a new kitchen, and on a Tuesday afternoon you have no idea whether anyone turned up. To find out, you can call and hope for a straight answer, or leave work and drive home. Weeks later the job runs late and nobody agrees on what happened, because all anyone has is memory.

The device that could settle this is often already on the front door. A Ring doorbell sees the van pull up, the crew ring the bell, and everyone leave at 3 PM. Nobody has time to scrub through that footage. We wanted the camera to keep the record for you, honestly and automatically, without turning into a surveillance tool.

What it does

CrewLog turns the Ring camera a homeowner already owns into a verified work log for contractors and home services.

• Automatic attendance: arrival, departure and hours on site for every work day. Nobody fills in a timesheet.
• Check-in and check-out alerts: "Crew arrived 8:05 AM" when the van arrives or the crew taps the doorbell, "Crew checked out, 6h 57m" when they leave, and a summary at the end of the day.
• No-show alerts: if nobody arrives by the expected start time plus a grace period, the homeowner gets an alert and a polite message to the contractor that is ready to send.
• Daily progress note: a morning still and an evening still of the work area are compared each evening with Amazon Bedrock vision.
• "Presence isn't progress": if the crew is on site but nothing visibly changes for two work days in a row, CrewLog suggests a friendly check-in question. It never accuses anyone.
• Crew, household or neighbour, with no face recognition: each visit is classified by its pattern (doorbell press, work vehicle, long stay during work hours). Only crew visits count toward hours.
• Shared weekly report: one link that the contractor sees too, showing days worked, hours and progress photos. It leaves out contact details, neighbours and the raw camera log.

How we built it

• Ring Partner API: HMAC-SHA256-signed webhooks (motion_detected, button_press) feed the backend. The REST API supplies devices, event history and image downloads. For development without hardware we used the ring-sandbox emulator, which speaks the same JSON:API shapes. In production the only change is RING_API_BASE.
• Backend: Python 3.11 with FastAPI. Incoming events are verified and deduplicated, then pass through a pipeline: a sessionizer (events become visits using a 4-hour gap rule), a classifier (crew, household, visitor or delivery), day summaries (worked, no-show, off or pending), and then the alerts, digests and the shared report.
• AI: Amazon Bedrock Converse API with Amazon Nova Lite. It compares two stills, returns a structured JSON progress note, and drafts polite messages. If Bedrock is unavailable, a fact-based offline fallback takes over.
• AWS: DynamoDB (one table, with conditional writes that deduplicate Ring's webhook retries), S3 for snapshots, SNS for email and SMS alerts, Lambda and API Gateway (via Mangum), and EventBridge Scheduler for checks every 5 minutes. Everything deploys with a single AWS SAM template.
• Frontend: React 18, Vite and Tailwind provide the Today view (live, refreshing every 3 seconds), the week view, settings and the public report.
• Zero-setup local mode: each AWS dependency has a local fallback selected by environment variables, so the same code runs on a laptop and on Lambda. One command plays all six demo scenes while the dashboard updates live.
• Tests: 33 pytest tests cover HMAC verification, dedupe, sessionizing, role classification, alerts, Bedrock parsing and fallback, and the privacy of the shared report.

Challenges we ran into

• Bedrock refused every call on our new AWS account. Every Nova Lite call returned ValidationException: Operation not allowed in every region we tried, from both the SDK and the console playground. Upgrading to the Paid plan didn't change it. Our IAM setup was correct; the block was at the account level and the error didn't explain why. We built a full offline fallback so the app never depends on the model, and we recorded the demo with that fallback.
• The Developer Playground doesn't send webhooks. CrewLog is built entirely on events, so we used the ring-sandbox emulator to deliver signed webhooks without a physical device.
• A doorbell can't tell you someone is still there. It sees arrivals, departures and quick trips to the truck. Our first 45-minute gap rule split real work days into pieces, and our tests caught it. A 4-hour gap rule, plus work-hour boundaries that visits can't cross, fixed it. That way a family coming home at 7 PM can't add to the crew's hours.
• Telling the crew apart from everyone else without faces. We chose to avoid face recognition on purpose, which left us with behavioural signals: doorbell presses, vehicles, how long someone stayed and what time it was. Ranking those signals well took several iterations.
• The simulator has one still per device, so before-and-after comparison was impossible. Demo mode maps each work day to a renovation-stage image instead.

Accomplishments that we're proud of

• An end-to-end product on the real Ring Partner API: signed webhooks come in, and verified alerts reach a phone.
• Privacy is part of the design. There's no continuous video and no face recognition, the AI is told never to describe people, and neighbours never show up on the shared report.
• The tone is polite. Every message to a contractor is phrased as a question, so the shared report is a neutral record that helps honest contractors as much as homeowners.
• The AI is optional. If Bedrock fails, CrewLog keeps working. That held up when our account was blocked.
• Derived data is always recomputed from stored events and never patched, so duplicate and retried webhooks cause no harm.
• 33 passing tests, a one-command deploy and a one-command demo.

What we learned

• Event-driven apps need ways to test events. The webhook path is the core of a Ring integration, and simulators matter as much as SDKs. We wrote everything up in a friction log for the Ring and AWS teams.
• Doorbell motion data is sparse. Building attendance from it takes careful session logic, and tests that model real work days.
• Patterns in behaviour can replace biometrics. You can tell the crew apart from the family without ever looking at a face.
• Build a fallback for every cloud dependency from the start. It saved our demo.
• "Present" doesn't mean "productive". Separating presence from progress is what makes the record useful in a dispute.

What's next for CrewLog

• Construction-loan draw verification: lenders release funds against verified attendance and progress.
• "Verified Pro" badges on contractor marketplaces.
• Milestone-based payments released when progress is verified.
• Recurring home services: cleaners, lawn crews, pool service, dog walkers and caregivers, wherever "did they come this week?" matters.
• "That was me" corrections in the UI (the data model already supports them).
• Alexa+ integration: "Alexa, did the crew show up today?"
• Turning on live Bedrock vision once our account is cleared, and deploying to production with Ring account linking.

Built With

• amazon-api-gateway
• amazon-bedrock
• amazon-dynamodb
• amazon-eventbridge
• amazon-nova
• amazon-sns
• amazon-web-services
• aws-lambda
• aws-sam
• fastapi
• httpx
• javascript
• mangum
• pydantic
• python
• react
• ring
• ring-partner-api
• tailwindcss
• vite