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

Schema-per-tenant is easier to reason about for isolation, but migration cost scales linearly with client count. On a small team that's the thing that kills you at thirty clients, not at five. Row-level pushed the complexity into query discipline and test coverage, a cost paid once rather than on every deploy.

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.