Whoami

I joined Sanity after implementing it for clients many times over. I’d used it enough to know where it shines, bends, and breaks, so they brought me onto their enterprise solutions team as a technical consultant covering pre-sales and post-sales. In post-sales, I met with enterprise teams of developers and content editors to teach the platform, troubleshoot bugs, talk through greenfield and brownfield implementations, and answer anything else that needed technical depth. I also spent time wearing a pre-sales hat, showing technical and non-technical audiences how a headless CMS works, usually with a demo built around their own content problems and their AI and human workflows. That beats a slide deck every time.

That stretch taught me more about content architecture than years of building my own projects had, because I watched dozens of teams hit the same walls from different directions. You start to see which problems are the team’s and which are the tool’s. I also became an internal advocate for the customers I supported.

After a year and a half, I took my talents to the developer education team to trailblaze the newly created role of Community Experience Engineer. My focus was building and maintaining tools that shorten the time to success for Sanity’s user base (aka the Community of developers). I built starter kits for frontend frameworks like Next.js, Astro, SvelteKit, and Nuxt, so developers could start from a working project instead of a blank repo. For the tough use cases that kept surfacing across the company, I built opinionated starter kits that handled them out of the box. I also helped launched the Functions Recipe Library, a collection of Sanity Functions (serverless functions) ready to copy and paste.

In both roles, I was really building the same thing from different angles: what developers reach for when the docs run out. These days that audience includes agents too (let’s be real), which changes what makes a good example more than you’d expect: less prose explaining the concept, more code that’s correct enough to copy.

A friend and I were both freelancing and hitting the same ceiling: projects too big for one person but too small for the bigger shops with more overhead. He ran sales and strategy while I designed and wrote the code. Between us, that covered most of what a project needed.

I ran projects from the first client meeting all the way through to deployment. I scoped the work and the budget, led the design and code, and trained clients to manage their own sites. Deadlines, bookkeeping, bank accounts, and cash flow kept me busy and gave me skills I’d never have picked up working for someone else. Managing contractors taught me how to lead.

Most of our clients weren’t technical and didn’t want to be, which made the job as much about understanding their business as building for it. What they were usually asking for, underneath the brief, was to stop being embarrassed by their website: a site that finally looked like the company behind it, the thing they’d been apologizing for turned into the thing they sent people to.

The thing running your own shop actually teaches you is that there is nobody to hand a problem to. Whatever it is, you learn it. We closed AllDay in 2023, as my co-founder and I both wanted to continue to grow our careers and try new things.