// about

Hi, I'm Adam.

Twenty years of leading web teams at scale — FinTech, zero-trust cybersecurity, marketing automation, enterprise planning, K-12 edtech. Now I run threesided as a small contract studio doing the parts your in-house team would rather not.

Based in Las Vegas. Pacific working hours. I keep my client list short on purpose — usually one engagement at a time, occasionally two when they don't overlap.

// the long version

From dial-up multimedia to graph databases.

I started in 1999 doing Flash and ColdFusion for a Department of Defense military-relocation research program. The cycle since: every ~2–4 years, jumping into a new industry as the person responsible for the web. Mortgage lending pre-2008. An indie music label. A digital agency running 300+ client sites. Freelance K-12 textbook production for the LAUSD iPad rollout, with Pearson and Apple.

Then a string of senior web-lead roles at enterprise SaaS — document automation in the Salesforce ecosystem, planning software with a global engineering team, cap-table fintech, marketing automation, zero-trust cybersecurity, graph databases. Pre-IPO sites. 55k+ URL architectures. +180% organic traffic over an engagement. Localized into seven languages with geo-routing.

The pattern: someone hires me because the existing site can't keep up with the company, I rebuild it on something modern, the team takes it from there. Three years later we both move on.

threesided.com is the version of that engagement I sell to teams who don't want to hire someone for three years. Same depth, scoped to a sprint. Same hand-built code, scoped to deliverables you can point at when I leave.

// how i work

Principles.

  • 01

    I write code I'd want to inherit.

    No "we'll clean it up later." If I wouldn't want to open the file in two years, you don't want it in your repo today.

  • 02

    I tell you what I don't know.

    Twenty years in and there's plenty I still haven't seen. The win is naming it early, not faking it. If the problem isn't my problem, I'll point you at someone whose problem it is.

  • 03

    I deliver in working order, not "almost there."

    "Almost there" means it doesn't work yet. The handoff includes a working build, a doc that explains the architectural choices, and a walkthrough video. Your next dev should be able to open the project cold.

  • 04

    Performance is a feature, not a polish step.

    I don't hand off a 4-second LCP and then offer to fix it. Perf budget gets set on day one and held to throughout.

  • 05

    Accessibility is non-negotiable.

    Keyboard, screen reader, reduced motion, contrast — all of it. WCAG AA at minimum, AAA where it costs me nothing. Not a checkbox. A floor.

// outside the day job

Hobbies that often become projects.

I run a long-form Twine adventure called DefyDestiny.com — 164 passages, six branching endings, a sentient toolbox.

I built SquishyMind because the mind-map tools I tried all felt brittle. I built Big Black Cards because party games on Zoom usually have terrible chat.

I host a long-running D&D campaign with friends; the kanban board that runs it became its own thing called DND Cards, with inline dice rolls and DM-only lists.

Most of what I build for myself ends up as case studies in the work grid. The grid is honest — most of those projects ship because I needed them to exist.

// say hi

Got a weird one?

Send a paragraph about the problem, not a brief.

Let's talk →