Every team has opinions about tooling. Here are ours β as of 2025, after five years of iteration, two full stack changes, and plenty of expensive mistakes.
**WordPress + Impreza (Core CMS)**
We build on WordPress for the majority of our client projects. Not because it’s perfect β it isn’t β but because it’s the most mature ecosystem in existence for teams that need to hand off a site and walk away. Clients can edit it. Developers can extend it. It’s boring in the best possible way. Impreza is our theme of choice: it gives us design flexibility without the overhead of building from scratch on every engagement.
**Figma (Design & Prototyping)**
Figma is the obvious choice and it’s obvious for good reasons. The collaboration model is genuinely better than anything that came before it. We use components extensively, and our shared library β built up over three years β means a new project can be at mid-fidelity prototype within hours rather than days.
**Cursor (AI-Assisted Development)**
This one is newer and more contested internally. Cursor is an AI-augmented code editor built on VS Code. We’ve been using it for six months on client projects and it has meaningfully accelerated our front-end development pace β particularly for repetitive structural work and quick iteration on CSS. It’s not replacing developer judgment. It’s removing the friction between intent and implementation.
**GitHub + Linear (Workflow)**
GitHub for version control β nothing surprising there. Linear for project management. We moved from Notion to Linear in 2024 and haven’t looked back. Linear’s opinionated structure actually fits how development projects run: cycles, priorities, clear ownership. Notion is better for documentation; Linear is better for shipping.
**Plausible (Analytics)**
We replaced Google Analytics with Plausible across all client projects in 2023. It’s privacy-respecting, lightweight, and β crucially β its dashboards show clients exactly what they need to see without requiring a two-hour onboarding session. Less data, more clarity.
**The Principle Behind the Stack**
Every tool we use has to earn its place by reducing cognitive load for someone β either us during the build or the client after handoff. If it creates more complexity than it removes, it doesn’t stay. That’s it. That’s the whole framework.