My titles are accurate.
They just aren't the whole story.

THE BIGGER PICTURE

I've done the work that doesn't fit neatly inside one box.

At Local Projects, I started in studio operations. As the business changed, I took on more of the functions that kept it moving: employee services, hiring & developing Operations staff, freelancers, vendors, technology, procurement, licensing, support, budgets & the decisions that connect them. Today I work directly with the CEO & COO, with significant independence over operating decisions & commercial relationships.

In a larger organization, that work might be divided among IT, People Operations, product, procurement & transformation teams. In a lean one, the handoffs still have to happen. Someone has to know enough about the whole process to stop the parts from contradicting one another. Quite often, that's been me.

I can make the business case, then open the tools.

I've negotiated technology contracts, changed licensing models & delivered more than $110K in SaaS savings. I've also been the person configuring the system, testing the approval path, training employees, writing the instructions & handling the call when a real user discovers the edge case nobody planned for. I don't mistake a completed purchase for a completed implementation.

I've owned technology relationships across more than 100 applications. Sometimes the right answer was another platform. Sometimes it was an existing feature we'd never used, a better agreement, an automation or a process that didn't need software at all.

I've built across businesses because the problem comes first.

LP Switchboard began as a better way to communicate with Operations. It expanded into an employee-facing operating platform. I built Ask A Local beyond the vendor setup, including interface customization, permissions & 112 of its 120 published guides. Independently, I built connected customer & owner experiences for Aaron's On It, founded Closet Sauce & designed MundiHQ around different organizational environments.

Those aren't the same industry, the same user or the same budget. They're different versions of the same challenge: understand the work, decide what belongs together & make the result practical for whoever has to use it next.

I don't just scale systems up. I build them to scale to need.

Scaling isn't only adding users. It's accommodating new responsibilities, permissions, services, locations, workflows & administrative realities without making the operation harder to run. I've designed for a single business owner, teams of employees, extended vendor workflows & multi-tenant organizations. Different scales require different engineering & governance resources, but the questions that make the design responsible don't change.

I'm not dazzled by AI. I'm interested in what it can actually do.

I championed formal AI adoption at Local Projects, then built the policy, training & practical support behind it. I use AI-assisted development to build products independently, & my paid AI evaluation work means I spend time assessing model outputs against actual instructions, evidence & quality criteria. I know the difference between an impressive-looking result & a dependable one. There's a reason I wrote a case study called When “Passed” Wasn't Proof ↗.

I build for the people who inherit the system, too.

A system isn't done when it launches. It's done when the person running it understands the rules, the exceptions, what has to be checked & who owns the next step. That's why I write the training, build the admin paths, document the limitations & keep improving the experience. Aaron's On It has a 43-page owner guide. Closet Sauce has a 56-page operating Recipe Book. That's not extra paperwork. That's how you stop the original builder from becoming a permanent bottleneck.