Skip to content
ale@portfolio:~/portfolio$ cat README.md

portfolio

Every case study here answers one question: measurable outcome.

events-salad-bar.mdZapier · 2021

Events Salad Bar

ShippedTeam: Data + Eng2 weeks
TL;DR

A no-code, drag-and-drop tool for creating event schemas, turning a confusing, engineer-dependent process into something any team member could do in minutes.

Outcome

  • 2wkhackathon to shipped v1
  • ↓CI/CD failures from malformed schemas
Saw It
  • A major events migration introduced declared-schema rules for the first time, but there was no tooling to follow them.
  • Every schema change routed through an engineer, creating a bottleneck and a real risk that teams would route around the rules under deadline pressure.
↓
Figured It Out
  • Tested the feasibility bet cheaply as a hackathon prototype before committing real build time.
  • Ran it past actual users before productizing, confirming both that non-engineers could use it and that engineers trusted the output.
↓
Did It
  • Built a drag-and-drop UI for assembling event schemas that auto-applied mandatory fields, surfaced human-readable errors, and submitted a PR in one click.
  • One engineer called it "everything I dreamed of for creating events" during the demo.

My Role

Spotted the bottleneck, scoped the hackathon prototype, and made the call to productize based on user validation rather than assumption. Owned the taxonomy rules the tool enforces.

Engineering Collaboration

Worked with the engineer who built the CI/CD checks to make sure the UI's auto-applied defaults matched the pipeline's actual validation rules, avoiding a rebuild by aligning early on what "mandatory field" meant on both sides.

Full breakdown

Problem & Risk

Feasibility RiskUsability Risk

A major events migration introduced declared-schema rules for the first time, but there was no tooling to follow them. Every schema change routed through an engineer, creating a bottleneck and a real risk that teams would route around the rules under deadline pressure.

Customer Discovery & Validation

Evidence

Tested the feasibility bet cheaply as a hackathon prototype before committing real build time, then ran it past actual users before productizing, confirming both that non-engineers could use it and that engineers trusted the output, before investing further.

Context

The process existed on paper but not in practice: confusing, slow, and effectively gated by engineering availability.

Timeline

git log --oneline⏱ 2 weeks, hackathon to shipped
kickoff: hackathon prototype to test feasibilityDay 1
validate: user research confirms demand + usabilityDay 4
ship v1: productized drag-and-drop schema builderWeek 2
next: GitHub/GitLab PR integration requestedBacklog

What We Did

Built a drag-and-drop UI for assembling event schemas (name, namespace, properties) that auto-applied mandatory fields, surfaced human-readable errors, and submitted a PR in one click. One engineer called it "everything I dreamed of for creating events" during the demo.

~ rough sketch, not an actual screenshot ~

available fields

drag from here...

event schema

...drop to build

✓ required fields auto-filled

error: human-readable

submit PR →

Who Benefits

Product managers can now participate directly in event creation instead of waiting on engineering. Engineers spend less time on repetitive schema requests. Taxonomy adoption became automatic instead of enforced after the fact, reducing the business risk of inconsistent, unusable event data downstream.

Next Steps

Integrate directly with GitHub/GitLab for one-click PR submission, and connect to the Data Catalog for reuse of existing properties.