Harsh Parmar

Toddle now acts as an identity provider for third-party and internal applications. I built the SAML side: signed assertions, metadata exchange, certificate handling, per-relying-party configuration.

Sign-on is IdP-initiated. The user authenticates with us, picks an application, and we check they belong to the organisation that relying party is configured for before signing anything. For OIDC I did the scoping, wrote the design spec, and I’m guiding the implementation.

Impact — SAML is shipped. OIDC is in development against the spec I wrote.

What I’d redo — I scoped the first cut to meet a deadline. A couple of the deferred pieces belonged in the initial design, and I’d push for them earlier next time.

SSO meant Google and Microsoft OAuth, hardcoded. Schools were turning up on Okta, Azure AD, ADFS and in-house IdPs, and each one was a bespoke project. Everyone shared a single login page, so enabling a provider for one school still meant a database flag and sometimes a small backend change: a ticket and a deploy sitting on the path to going live.

I built generic SAML and OAuth integrations that work against any compliant provider, plus per-org login pages that admins configure themselves. Allowlisting is enforced server-side, so a method disabled for a school is disabled on the shared page too.

Impact — Any standards-compliant IdP, configured without engineering. Cut ~15 engineer-hours/month of manual enablement across 500+ organisations.

What I’d redo — The SAML library has leaky abstractions and thin documentation, though nothing better was available at the time. The admin setup flow also leans on documentation more than it should.

Syncs, bulk exports and migrations ran on a homegrown system that predated the load we were putting through it. Retries were ad hoc, partial failures left inconsistent state, and every team rebuilt the same scaffolding.

I built an orchestration framework on Temporal with progress tracking, retries and graceful degradation. Several teams now use it for long-running jobs across regions.

Impact — Now the standard path for long-running work at Toddle.

What I’d redo — The framework is more general than it needs to be. Teams can express almost any workflow shape, so it can’t warn them when a design is wrong. I’d trade some flexibility for guardrails.

Onboarding a school meant moving student, staff, parent and class data out of its SIS: PowerSchool, Clever, Veracross, iSAMS, or something in-house. An engineer did it by hand, usually over several rounds of fixing data shape with the school.

I built the self-serve rostering module. Schools configure their own migration, watch it run, and opt into recurring sync. I wrote the PRD and did the UX alongside the implementation, and later cut Lambda invocations by rescheduling the cron behind it.

Impact — Removed engineering from the standard onboarding path for 200+ schools.