Skip to content

Software engineering

Platforms, built from the data model up.

Most of my career has been building platforms: Menumill, a content management SaaS; Fluxx, which I helped build from its early years; and AI-native products. I design the architecture and the data model, build it, and stay accountable for how it runs.

What do I build?

  • Multi-tenant SaaS platforms: tenant isolation enforced by the database, records shared safely between organizations, and an audit trail of every change.
  • AI-native products: I've designed and built AI-native SaaS products from scratch, where natural language is part of the product, not a feature bolted on.
  • Internal tools and APIs: the pieces your off-the-shelf systems don't cover, built to connect to them.
  • Founding builder or fractional CTO: for philanthropy tech companies that need a senior architect before they need a team.

How do I build software now?

Every feature starts as a written spec, and its use cases become automated tests before the feature itself is built. AI agents write much of the code. I own the architecture, the data model and the final review. What that gives you:

  • Tested from day one. Test coverage is built in as the software is written, not added at the end.
  • Changes you can trust. The tests catch what a change breaks before it ships, and every change is small and separate, so it can be rolled back on its own.
  • Automated review on every change. AI agents check each change against the spec and the tests, often over several passes, before it reaches me.
  • Documentation that stays true. The spec is updated in the same change as the code, so it always matches what the software does.

It's how one architect can deliver what used to take a team, and how the next developer or agent can pick the work up and trust it.

Why do I put security in the database?

In a multi-tenant platform, the worst bug is one customer seeing another's data. My default is to enforce tenant isolation with PostgreSQL row-level security, so the database itself refuses to return rows a user isn't entitled to. Every screen, API, export and AI query goes through the same rules, and the rules are tested directly: each tenant sees its own data, shared records reach only the parties they're shared with, and everyone else sees nothing.

When two organizations share a record and one of them is evaluating the other, I go a step further. Anything the other party must never see lives in its own table, where their credentials can't reach it. The security decision is then made once, when a field is created, instead of in every query anyone writes afterward, including queries written by AI agents.

How do I keep AI features safe?

AI sits on top of the same data and security as the rest of the product, so it can only do what the user can do. Each request goes to a specialist agent that sees only the tools and data it needs. AI reporting never writes raw SQL: the AI fills in a structured request that's checked against an approved list of data and fields before it runs.

What have I built?

  • Fluxx: in 2010 I joined Fluxx's founders as the first engineering hire, and over more than seven years my work touched nearly every layer of the platform: user roles and permissions, reporting, Liquid templates, geographic data and mapping, integrations and infrastructure.
  • Menumill: a hosted content management platform I built with a two-person team, launched in 2009. It powered hundreds of websites and digital signage displays.
  • AI-native products: designed and built from scratch for philanthropy.

Who is it for?

Philanthropy tech companies building a product, foundations that need a tool their grants system can't provide, and teams in any sector that need a platform designed to last.

Need it connected to the systems you already run? See integrations.

Where is your team losing time?

Let's talk it through. A free 30-minute call to walk your process through six questions and size what discovery would take.

Book a 30-minute call