I helped build the returns product a competitor bought.

Every retailer runs returns differently, with its own windows, fees, and outcomes. ReturnLogic’s portal had to fit each retailer’s policy instead of making the retailer bend to the software.

1. StartShopper portalWhere a shopper starts a return. Each retailer could customize all of it: design, text, flow, and step order.
2. PriceReturn calculationsWhat the shopper gets back after fees, accounting for discounts and promos, tax and shipping, and the price difference on exchanges. Bundles come back whole or item by item, as the retailer chooses.
3. ApproveAuto authorizationA return that meets the retailer’s rules is approved and gets its shipping label, through EasyPost or the retailer’s own carrier account.
4. CloseAutomated processingThe refund, gift card, or exchange item goes out and the return is closed, with no one touching it.

I built every step. Teammates built the return rules engine and return analytics; I contributed to analytics.

Everything in the portal was configurable per retailer, and the settings interacted, so there were far more combinations than anyone could test by hand.

I kept it manageable three ways: defaults plus overrides, so a retailer only set what differed; LaunchDarkly flags to roll changes out retailer by retailer; and Jest tests on the risky combinations.

In 2026 a major reverse-logistics competitor acquired ReturnLogic.

• 2M+Returns processed

ReturnLogic ran as a private Shopify app and took in each merchant’s data through webhooks. We had registered them without a version, which Shopify’s docs said meant “latest.”

In Christmas week 2022, right as peak returns season began, Shopify flagged that version as deprecated.

Lambda functions on a 30-minute schedule pulled products, orders, customers, collections, and inventory from Shopify’s REST API and fed them through SQS into our existing ETL, so nothing downstream changed.

Each poll asked for records updated since the last one for that store and resource, with a small overlap, throttled and backing off on Shopify’s 429 responses. Records were upserted by Shopify ID, so the overlap, and data arriving through both webhooks and polling, merged instead of duplicating. Thirty minutes was fresh enough: returns start days after an order.

Another engineer and I split it by layer: I built the Lambda pollers, and the other engineer handled the path through SQS into the ETL. We switched every store over at once.

No outage, and record counts matched Shopify’s through the peak returns week. The deprecation turned out to be a non-issue.

• <1wkFrom Shopify’s email to all stores polling

• Two sources of truthOne of the first external APIs on Actifai’s order framework where state lives on both sides: an order lives in Actifai and in the provider’s billing system, and the two have to agree. The provider calls back with each order’s status, which is how we catch a mismatch.
• Plan mappingSingle, double, and triple play orders (internet, TV, and phone, alone or bundled) have to map onto each provider’s billing products.
• Go-live coordinationEach launch lines up the provider and its integration partners, and I gather the requirements with them. A runbook covers each new provider’s credentials and config, plan mapping, and go-live checklist.

A failed submission goes into an exceptions queue in Actifai’s manager portal, where staff fix and resend it, and the provider gets an email when one of its orders is flagged.

A correlation ID on every submission ties logs, Datadog monitors, and the queue to one order, with personal data redacted first.

Each return (RMA) at that retailer’s own price, shipping labels for retailers on our managed shipping integration, and any add-on features they used.

Every posted charge was recorded in Postgres, so re-running a failed cycle skipped what had already posted instead of charging a retailer twice.

Retailers on ReturnLogic could authorize and process returns automatically, which is also the path a fraudulent return takes. Fraud leaves patterns in a shopper’s return history: the same item sent back again and again, the same return type or reason every time, a burst of returns in a short window.

1. ScoreRulesRules score the return’s fraud indicators. Clear-cut returns are settled here.
2. JudgeOpenAIWhen the rules can’t decide, OpenAI decides whether to flag the return and writes its reasoning.
3. HoldThe automationA flagged return is held back from automatic authorization and processing. It isn’t denied.
4. DecideStaffStaff see the flag and the reasoning on the return and make the final call.

A provider abstraction let us A/B test prompts and swap providers without a rewrite. The test picked the prompt we shipped and exposed three guardrail gaps, which we closed.

• Flagging on thin evidenceThe model flagged returns the rule scores didn’t support.
• Inconsistent verdictsThe same return history could get different answers.
• Shopper text steering the modelReturn reasons and notes that shoppers write could sway the verdict.

Each evaluation got cheaper three ways: a shorter prompt, varied reasoning effort on one primary model, and calling the model only when the rules can’t decide.

Retailer feedback said shoppers hated the old way, and our cart-abandonment data showed high-value carts left behind.

When a shopper picks an exchange, ReturnLogic generates a Shopify cart and a one-time discount code worth their return credit, minus return shipping, restocking, and any other retailer fees. They check out on the retailer’s own Shopify store, so taxes, inventory, and payment all stay in Shopify, and an embedded script sends them back to their return’s tracking in ReturnLogic.

Each code works once, only for that shopper, and expires. When the new item costs less than the credit, each retailer chooses what happens to the difference.

Warranty claims run through the same portal as returns and exchanges, but three things work differently.

Each retailer sets a separate workflow for each case.

• In stock: Exact replacementChecked against the store’s live inventory.
• Out of stock: A choiceA replacement from the full catalog, or a way to contact the retailer.

Mostly enterprise customers selling consumer products, who until then had handled warranty claims outside ReturnLogic.

Actifai’s door-to-door sales app puts addresses on a map for reps to work, but managers had no way to hand an area to a team.

With teammates, I built both sides of it: the drawing tools managers use to outline clusters of addresses, assigning each territory to reps by user group, and the view where reps see their own territory. Now each team gets its own area.

Rep positions jumped around on the map, and the app’s location permissions weren’t handled correctly. I fixed both. The app now asks for location at the right moment and handles a rep who says no.

Every service order in Actifai’s online shop needs an address. Google Places autocomplete gets customers to a valid service address with less typing, so fewer orders come in with bad addresses.

I’m an avid fisherman, and I wanted one place where my friends and I could log our catches, track the conditions we caught them in, and compete.

• JournalCatches, spots, and gear, with the temperature, wind, and moon phase saved for each catch.
• RegulationsSize and creel limits for 30 Maryland species, shown next to each one and imported automatically from Maryland DNR.
• LeaderboardBiggest fish per species, most catches, and most species, with filters.
• ProfilesA public profile for each angler.

React and React Leaflet over OpenStreetMap tiles on the front end; a Python API on AWS Chalice (Lambda and API Gateway) with MySQL on RDS.

The weather is saved with the catch, so the log never depends on a weather API later. Geocoding (OpenStreetMap’s Nominatim) and weather (Open-Meteo) need no API keys. Photos go from the browser straight to S3 through presigned URLs, so the API never streams image bytes, and iPhone HEIC photos are converted to JPEG in a Lambda.

Keeping the map, the catch list, and the filters in agreement. Change a filter or move the map, and all three have to update together.

No framework runtime and no third-party widgets: static Astro pages with one interactive island. The store’s state is a pure, unit-tested reducer in plain TypeScript, and the cart lives in the URL, so a cart can be shared as a link.

Checkout books a real call: a small Cloudflare Worker reads my Google Calendar free/busy and sends the invite with a Meet link. Everything renders as plain HTML first, so the site works without JavaScript and prints as a résumé.

The same markup carries two designs. A theme layer of design tokens and component rules switches the whole site to a 1990s version with a CRT-style transition, remembers the choice, and never prints.

Haven’t found it yet? Switch to the 1990s design

Lighthouse mobile scores 100 for accessibility and best practices on every page; performance is 96–97 on project pages and about 70 on the landing page. axe finds no WCAG 2.2 AA violations in any state.

• 100Lighthouse accessibility