I build the systems
businesses run on.

AI-assisted operational systems, workflow orchestration, and business automation, built to survive production, not the demo.

Builder & Founder
Sean Duncombe

Built & building

PodcastAINeuroframe
Engineering records

Production systems, documented end to end.

All projects →
Flagship record

Booking one call took three subscriptions.

It started as a replacement for Typeform, Calendly, and Zapier on this site. Today the same engine runs scheduling for neuroframe.com: live availability from Google Calendar, double-booking-proof event creation with Google Meet, and every lead recorded in Sheets.

The whole build is documented as an engineering record: the components, the decisions, and what broke on the way to production.

  1. 01A visitor picks a timethis site, or neuroframe.com
  2. 02Availability is read liveGoogle Calendar free/busy
  3. 03The event is created onceidempotent under retries
  4. 04The invite is the confirmationGoogle Meet · native RSVP
  5. 05The lead is on recordGoogle Sheets
Namegen

You find the perfect name. The domain is taken.

Namegen starts from the problem you are solving, not a keyword. Candidates come from curated lexicons or from the visitor's own AI key, then pass hard quality gates before they are scored, radio-tested, and checked against live domains and trademark risk.

What comes back is a shortlist worth building around, twelve to twenty-four names, never a dump. The whole pipeline is documented as an engineering record, and the AI bill belongs to the visitor, never the host.

  1. 01You describe the problementity + problem, not keywords
  2. 02Candidates are generatedcurated lexicons, or your AI key
  3. 03Hard gates cull the sludgefilter · ban · brand quality · score
  4. 04Every survivor is checkedradio · domains · trademark risk
  5. 05A shortlist comes back12 to 24 names worth owning
Knowledge Center

Every page depended on someone else's API.

Neuroframe's content ran on a headless CMS. Every render leaned on an external service: outages we did not cause, layouts the block model fought, and costs that scaled against a library meant to reach thousands of structured articles.

So we took ownership: content in Git, a typed knowledge tree, and a rendering pipeline on our own servers with no external API in the path. The record documents the decisions; the Knowledge Center shows the result.

  1. 01Content lives in Gitversioned and reviewed with the code
  2. 02A registry types every surfacetaxonomy + URL architecture
  3. 03The build validates the pagesgates before anything publishes
  4. 04Pages render on our serversSSR · no external API
  5. 05The library compoundsthree locales, one tree

Open-Source Applications

All apps →

Operational systems.
Not AI demos.

Anyone can wire prompts to a model. The engineering is deciding where AI belongs, where deterministic software belongs, and where people do, then building a system your business owns and can depend on.

  1. 1

    Start with the business problem.

    Not the technology. The workflow that eats hours, the process that breaks, the decision nobody owns.

  2. 2

    Design the system.

    The whole operation: where data lives, what talks to what, and what happens when something fails.

  3. 3

    Choose the right component.

    AI where judgment has to scale, deterministic code where correctness matters, people where they are irreplaceable.

  4. 4

    Build it to survive production.

    Owned by your business, boring to operate, and still running long after the demo would have fallen over.

Let's build something that lasts.

Book a call