Georgia

1. Ran a discovery workshop with the customer to map their channels, feedback volume, and the product taxonomy the output had to match.
2. Configured the Spark AI workflow and wrote Python glue to pull and normalize feedback from their sources before processing.
3. Used LangChain for the multi-step conditional logic Spark didn't cover natively, then validated output quality against a labeled sample with the customer.
4. Took it to production, documented the config, and trained their team to run and extend it - a deliberate handoff, not a dependency.

This was the actual customer engagement: scoping, delivery, and enablement end to end. The reusable architecture pattern behind it lives in the Solutions Architecture section.

1. In VS Code, wrote a Python test script implementing the Haversine formula independently of the production code, as a ground-truth check.
2. Called the live API with the new radius parameter, then asserted every returned article actually fell within the declared radius using the independent calculation.
3. Built a Postman collection covering edge cases (boundary of radius, zero radius, antimeridian) for repeatable regression testing.
4. Wrote the client-facing API docs and ran release communication to the full enterprise client base.

Built at Perigon before shipping a geolocation filter to 150+ enterprise accounts. This is the validation discipline that makes a customer trust a feature enough to actually adopt it - not just ship it.

1. In VS Code, wrote a Python pipeline using pandas to ingest mixed CSV and Salesforce-export sources into one dataframe.
2. Normalized fields (names, dates, emails), then validated each row against the target JSON schema for the Productboard REST API.
3. Clean rows were batch-imported via the API; ambiguous rows were written to a review queue with the specific reason flagged.
4. Logged every insert and rejection so the customer had a full audit of what moved and what needed a human.

Built at Productboard to onboard enterprise customers faster without shipping data errors into their new environment.

1. In VS Code, stood up a Python webhook listener to receive Salesforce Opportunity events in real time.
2. On a flagged Opportunity, mapped the record's fields to a structured feature note and created it in Productboard via the Productboard REST API.
3. Built the reverse path: a sync job read roadmap status and priority changes and wrote them back onto the originating Salesforce record through the Salesforce API.
4. Added retry with exponential backoff and an error queue so a failed call never silently dropped a record - both teams could trust the data.

Built for a Productboard enterprise client whose sales and product teams were maintaining the same list twice. The kind of CRM-to-system-of-record bridge post-sales customers need across their whole stack.

1. Wrote one PosAdapter interface with two implementations, so a venue picks its POS in config rather than forking the codebase.
2. Built a business date rule into the domain model: the night runs 6pm to 6am, so a 1:30am check belongs to the prior calendar day. Getting this wrong silently splits a night in half.
3. The matcher scores each candidate on table, time window, party size, and whether the deposit shows up as a tender line, then assigns greedily so one check can never satisfy two reservations.
4. Every match stores its reasons, and the leftovers surface as no-show, walk-in, or possible split rather than being dropped.

Built for the two venues I co-own because the reports we needed did not exist in either vendor's product. It runs against the real APIs and against recorded fixtures, so the whole pipeline runs offline with no credentials.

1. Verified against a real night that check.amount is item sales plus the card surcharge, so the number the vendor UI labels subtotal is not pure product sales.
2. Found the double-count trap: one check carried a voided payment and a captured payment for the same amount, so naive summing inflates revenue.
3. Made the spend basis configurable across four definitions, because the answer to "what did they spend" legitimately differs depending on who is asking.
4. Wrote a reconciliation command that proves the pull is complete and the money identities hold, since the API exposes no sales summary to diff against.

The private version runs against a real venue account. This public repo is the same code against a synthetic fixture that reproduces every edge case that bit the original: table moves, split checks, voided payments, and an open check.

1. Hard rule enforced in code and asserted in tests: record presence flags only, read from filenames. No identification numbers or dates of birth are ever stored, and the scans are never opened.
2. Roster comes from the newest scheduling export minus a persistent inactive ledger, so an owner marking someone inactive overrides the export forever.
3. One config per venue describes that venue's folder layout and column set, so two structurally different venues run on one code path.
4. Certifications inside 30 days become a drafted email grouped by urgency, which a manager reviews and sends. The system never sends on its own.

Production for two venues since August 2026. The public repo is the generalized, de-identified version: same code, same sheet layout, same scheduled prompt, with a synthetic roster.

1. Built on Claude with a saved, version-controlled internal prompt template that enforces the output structure - systems, trigger, data flow, field map, edge cases.
2. Wired in the Figma connector so the generated spec drops straight onto a shared design canvas the customer and engineers annotate together in the session.
3. Wrapped it in a lightweight web interface (input box, example chips, rendered spec sheet) so a non-technical stakeholder can drive it.
4. Hosted the interface on Vercel for a shareable internal URL - no local setup, always current.

Built at Productboard to speed up enterprise scoping calls. I was translating vague customer asks into integration specs constantly and wanted the first draft on screen, in a shared canvas, before the meeting ended.

1. In Python, pulled an account's live configuration via the Productboard REST API as structured input for the agent.
2. Gave a Claude API agent a tool to read config plus a rubric of best-practice checks, each weighted by severity.
3. The agent reasons over the config, identifies gaps, and returns structured findings - issue, severity, and the specific recommended fix.
4. Findings render as a ranked scorecard that becomes the agenda for the customer's architecture review.

Built at Productboard to make account reviews objective and scalable. Instead of a static checklist, the agent reasons about each unique config - the same review an SA would run, on every account.

1. Abstracted the workflow into five swappable stages - ingest, normalize, classify, summarize, deliver - so each could be reconfigured per customer.
2. In VS Code, wrote Python orchestration where the normalize and classify steps take config, not hardcoded rules.
3. Used LangChain for the conditional multi-step logic and standardized the LLM API calls so any stage's model or prompt could swap without touching the rest.
4. Documented it as an internal reference pattern so any engagement could start from the architecture instead of a blank file.

Built at Productboard as AI Technical Lead - the design abstraction that let one architecture serve many customers. The delivered version for a specific client lives in the Clients section.

1. Catalogued the recurring integration failures across the enterprise API accounts into a set of symptom categories.
2. For each symptom, mapped the branching questions a senior engineer actually asks to isolate the cause.
3. Encoded that logic as a decision tree in JavaScript, where each leaf resolves to a specific root cause and the exact fix.
4. Recorded the path taken on each run so resolutions were self-documenting for the next person.

Built from the escalation patterns I saw supporting Perigon's enterprise API accounts. A guided runbook like this cuts time-to-resolution and scales a support team's expertise across every integration a customer runs.

1. Defined the adoption signals that actually predicted retention (active usage, integration depth, admin engagement).
2. In Python, built a weighted scoring model combining those signals into one composite health score per account.
3. Pulled usage data through the platform's analytics/SQL layer and mapped each score band to a recommended intervention.
4. Surfaced it as a dashboard the CS and product teams reviewed to prioritize outreach.

Built as Product Operations Manager at Sentieo (acquired by AlphaSense) to get ahead of churn. Directly the "proactively identify risks and opportunities within accounts" work a post-sales SA owns.

1. In Python, modeled this customer's current-state monthly spend and integration count across their four overlapping tools.
2. Encoded the consolidation logic - which overlapping tools Productboard's platform absorbs, and the integration points that retire with them.
3. Output projected platform cost, monthly savings, and the number of integrations eliminated.
4. Walked the Account Manager through it live before the renewal call - the model became the leave-behind.

Built at Productboard after seeing this exact overlap on a real enterprise account. The "point solutions to a single platform" case a post-sales SA makes to grow an account, backed by numbers instead of enthusiasm.

1. Designed a dimensional schema (fact + dimension tables) joining product usage, account tier, and renewal outcomes - the three metrics the business actually needed together.
2. Built an ETL job in Python to extract from all three operational systems incrementally and transform them into that schema.
3. Loaded into a Snowflake-style warehouse and wrote the SQL views the analytics layer sat on.
4. Exposed it so product and CS teams could self-serve usage-vs-renewal questions without a data engineer in the loop.

Built at Sentieo (acquired by AlphaSense) to answer the one question leadership kept asking that nobody could answer quickly. The exact data-flow work behind advising a customer on getting their data into Snowflake or Databricks.

1. Catalogued the 5-6 question types the team asked repeatedly, then wrote a versioned Python prompt template for each.
2. Wired each template to the actual data source it needed - Productboard API for feature status, CRM export for account activity.
3. Called the Claude / GPT-4 API with the matched template so answers stayed grounded instead of generic.
4. Shared it as one internal tool with version-controlled prompts, instead of everyone maintaining their own ChatGPT thread.

Built at Productboard so the team stopped re-solving the same prompt-engineering problem individually. Same pattern behind any "internal Slack bot that actually knows your data" a Rippling customer would want.

1. In VS Code, wrote a Python script using ReportLab to generate PDFs programmatically instead of editing Word docs by hand.
2. Separated content (policy text, comp tables) from styling (logo, color, typography) into a single structured source file.
3. Built the layout template once - headers, section breaks, legal footer - so any content change regenerates a fully branded document instantly.
4. Reused the same pipeline across both venues by swapping the branding inputs, not rebuilding the template.

Built to solve my own operational pain running two venues - the same instinct that made me build backend tooling instead of doing repetitive work by hand at every company I've worked at.

1. Designed a scheduled job to pull the same 5-8 metrics leadership already tracks weekly from wherever they live.
2. Drop them into a structured template, then call the Claude API to draft the narrative summary paragraph.
3. Flag anything that moved more than one standard deviation from trend so the exec knows what actually needs a story.
4. The exec edits and adds color - the system drafts, it never sends anything on its own.

A direct application of the same ingest-classify-summarize orchestration pattern built at Productboard, aimed at a different audience - executive reporting instead of customer feedback.

1. Take raw meeting notes as input - paste, or auto-pulled from a notes tool.
2. Run them through an LLM prompt tuned specifically to identify action-bearing sentences vs. general discussion.
3. Assign an owner where one's named in the text; flag sentences with no clear owner for manual assignment.
4. Push confirmed items to Slack/email with a nudge scheduled at the stated due date.

The instant version below uses simple keyword matching to demonstrate the extraction logic. The live button calls a real Claude prompt tuned for this exact task.

1. Maintain one structured record per contract - vendor, renewal date, notice-period length, monthly cost.
2. A scheduled Python job checks days-remaining against the notice period daily.
3. Escalating alerts fire at 45/14/3 days out, color-coded by urgency, so nothing is a surprise.
4. A single dashboard view replaces checking each vendor's portal manually.

Directly inspired by running vendor and lease contracts for two venues by hand - the exact kind of preventable miss a Chief of Staff or Solutions Architect is trusted to catch before it costs money.

1. In VS Code, designed the Supabase schema - users, profiles, filters, jobs, a scoring junction table, and an application log.
2. Built resume upload that triggers Claude API parsing into structured JSON (skills, experience, target roles).
3. Wrote a batched scoring pipeline in LangChain / LangGraph that matches candidates against live postings in groups of 10.
4. Built the React swipe UI where actions write to state, and a daily cron refills each user's queue automatically.

Built to solve my own job search problem while job hunting - full-stack, end to end, not a tutorial project.

1. In VS Code, wrote a Python script that polls each consulate's appointment API/page on a cron schedule.
2. Parsed each response for open slots and diffed against the last known state to detect new availability.
3. On a new slot, called the Telegram Bot API to push an instant alert to my phone.
4. Stored credentials in environment variables, never hardcoded, and ran it unattended on a schedule.

Built to solve a real, personal logistics problem during my own visa process - small in scope, but it runs unattended and does its job every day.