How We Work

First, we listen. Then, we build.

Most software engagements open with a pitch. Ours opens with a question, because the people who actually do the work know things the people who buy the software never will.

The Learner Frame

I build software systems for businesses, and the biggest mistake people in my industry make is they don't understand the businesses they're building for. I'm trying to fix that. Would you be willing to teach me how your industry works? No pitch, no agenda — I just genuinely want to learn.

The four-step methodology

Listen, Design, Build, Support — the whole engagement in plain language, with the detail that makes it credible.

  1. Listen

    Before a line of code, an observation morning and a Learner-Frame conversation. The owner is the expert on this business; our job is to understand it, not to prescribe.

  2. Design

    Options, always more than one, each with the trade-offs spelled out in business language — calls saved, clients retained, hours back — not dashboards for their own sake.

  3. Build

    AI-augmented, story-based delivery through the BMAD process: a 16-stage lifecycle from qualification through to a 3-month warranty, with a human reviewing every change.

  4. Support

    A 3-month warranty is included on every build, then optional support at the hourly rate, with quarterly check-ins on the systems we stay on to retain.

For the technical reader

For the technical reader

Everything above is written for the business owner. This section is for the engineer or technical evaluator who wants to see the stack, the architecture call, and the project process behind the claims. Skim it, or skip it.

Technology choices
Next.js, TypeScript, Tailwind, and Shadcn for the frontends; Python, FastAPI, and PostgreSQL for the backends; Authentik for single sign-on; Docker on self-hosted Proxmox for hosting. Boring, well-documented tools we can still maintain solo in five years.
Architecture approach
Compose best-in-class tools rather than forcing one vendor. Small, focused services behind clean APIs — we'd rather swap a component out than rewrite a monolith when a better tool arrives.
The BMAD project process
Every engagement runs through BMAD: a PRD becomes an architecture decision record, which breaks into stories with explicit acceptance criteria. Nothing is built until the story is written.
QA gates
Two layers. Objective build-time gates (build green, lint clean, invariants checked) run on every change. Visual verification runs against the running app for the things a build can't catch.
The AI-augmented pipeline
Stories in, code out — but every line is reviewed by a human before it lands. The AI is a force multiplier for one developer, not a replacement for engineering judgement.