CuroWork

Context

CuroWork sells workload visibility to finance and back-office teams: where a team's time actually goes, who is at capacity, how planned work compares to what got done, and how much of the week disappeared into ad-hoc requests. I joined as founding engineer and owned the platform end to end: architecture, delivery, third-party integrations, and the LLM feature work that shipped into production.

What I built

• Multi-tenant architecture on PostgreSQL and Supabase with row-level isolation, and tenant configuration modeled as data
• Bidirectional calendar sync against Google Calendar and Microsoft Graph: read/write, per-tenant OAuth, full recurring-event handling
• A recurring task scheduling engine
• LLM features in production: structured work summaries generated from activity data, and embedding-based task suggestions using semantic retrieval over the tenant's own historical records

The hard part

A separate schema per tenant makes isolation explicit, but adds migration work as the tenant count grows. I chose a shared schema with row-level isolation to keep migrations centralized. That tradeoff requires ongoing discipline in queries, access policies, and test coverage as the product evolves.

Calendar integrations were also challenging. Google and Microsoft disagree about recurrence rules, timezone handling, and what should happen when a user edits a single instance of a recurring series. Doing bidirectional sync across both, per tenant, with OAuth token lifecycles that expire at inconvenient moments, is substantially harder than it looks from the outside.

A workflow in practice

A finance and accounting team modeled its month-end close checklist in CuroWork, assigned owners and estimated hours, then used the workflow snapshot to see where delays were hiding. In the three months covered by this walkthrough, the team's close time fell from 20 days to 12, with less month-end strain and more capacity for strategic work.