Salesforce AppExchange

A trusted development partner to the same team since 2008 — who brought me into Salesforce with them in 2012, and still reach out today. Hundreds of pages, apps, and internal tools, and eventually the page-builder systems that let their marketing team ship without me.

• Role: Independent development contractor — frontend, backend, tooling, deployment, technical strategy
• Timeline: Relationship since 2008 · at Salesforce 2012–present
• Team: Embedded with Salesforce designers, project managers, and developers across multiple teams
• Stack: HTML, CSS, JavaScript, Vue, TypeScript, Laravel, GSAP, PHP, Heroku, Salesforce internal CMS
• Recognition: Work featured at multiple Dreamforce conferences

The relationship

The team I worked with at Salesforce’s AppExchange didn’t find me there. I’d been working with them since 2008, at the company they were with before Salesforce where my business partner and I created animated web banners, landing pages, and more. When that team moved to Salesforce in 2012, they brought us with them. Inside Salesforce, that single relationship opened up into work with many teams across the AppExchange organization. It started the way the best work does: not with a pitch, but with a team that already trusted us and wanted us along.

Over time, I became part of their day-to-day workflow. I was in their Slack channels, copied on planning emails, and brought into projects at the earliest stages — before designs were finalized, sometimes before scope was defined. For practical purposes I operated like a full-time team member, but as an independent contractor across their projects.

Working inside an organization like Salesforce meant operating within real constraints: brand guidelines, shared component libraries that still had to flex for different teams, an internal CMS workflow, and privacy and security review at enterprise scale. Part of the job was producing work that was creative and effective without ever stepping outside those lines.

From pages to page-builder tools

The most significant work I did for the AppExchange team wasn’t a single page or app — it was deciding to make myself less necessary. After building hundreds of individual pages on request, I proposed and built page-builder systems that let their marketing team create new page variations on their own, without routing every request through me. It was a deliberate choice that reduced my own hands-on involvement, and it was the right call for the team.

These apps were built with Vue and TypeScript. Page configurations were stored locally using IndexedDB, and could be downloaded, backed up, and shared among Salesforce employees. When the apps were upgraded, the system automatically migrated user data to the new version.

“What is AppExchange?” scroll animation

A scroll-driven animated explainer built to introduce AppExchange to newcomers, using GSAP for synchronized motion tied to scroll position.

Dreamforce kiosk

Interactive touchscreen content for Salesforce’s Dreamforce conference, designed to run reliably in a high-traffic event setting.

Dynamic anniversary pages

Templated, data-driven pages that celebrated AppExchange milestones, generated from a system rather than hand-built one at a time.

Privacy compliance at scale

Work to bring pages and apps into compliance with privacy requirements across a large catalog — the kind of unglamorous, high-stakes work that enterprise software demands.

Outcome

I built hundreds of web pages, apps, and tools for the AppExchange team across more than a decade. The page-builder tools I proposed shifted their workflow from requesting custom development for each page to creating new variations independently — which was the point.

In mid–2024, Salesforce made a company-wide shift toward in-house teams, and the intensive embedded work slowed. But the relationship didn’t end — by then the tools and systems I’d built were part of how the team operated, and they still reach out. A relationship that started in 2008 and survived a change of employer wasn’t going to stop at a change of staffing model.

Reflection

The work I’m most proud of is the page-builder tooling — precisely because I proposed it knowing it would reduce my own billable hours. The right thing for the client was to make their team self-sufficient, so that’s what I built. That instinct, putting the client’s long-term position ahead of my own short-term utilization, is a large part of why the relationship has lasted as long as it has.

The other lesson is about what long-term embedded work actually teaches you. Nearly two decades with the same people — through a company change and across countless projects — means you see how decisions age: which shortcuts create debt, which abstractions hold up, which communication patterns survive team turnover. That kind of judgment doesn’t come from any single project. It accumulates.