Ten systems, picked for the story. Most were operations I had to learn cold before I could ship. Unfamiliar is not the same as hard.

Florida’s nurse registries run non-medical home care. They match caregivers to clients, then handle the schedules, the visits, and the money that follows each visit. I co-founded Omassist to build the software they run on, and I was its primary architect and developer.

The platform is multi-tenant, on web and mobile: onboarding, matching, scheduling, visit verification, billing and payouts. A vision model reads IDs and compliance PDFs into records. Money moves through Stripe Connect, behind a ledger and checks that make a retried webhook harmless, so nobody gets paid twice.

The first registry went live in December 2025, under a year from the start. A business runs on it today, with money moving through it.

Matching and care-plan logic are deterministic code, not a model, and so is anything that moves money. I’ve kept that split on everything since.

The platform holds everything an agency knows: clients, caregivers, credentials, schedules, visits, invoices. I wanted an assistant that could work over that data for real, not in a demo.

The assistant is several agents, one per part of the business. Each has tools that reach one agency’s live data and nobody else’s. It runs on either OpenAI or Anthropic models. Next to it I built a harness: a bank of graded test questions and a second model marking the answers against a rubric.

It’s in production today. When a user gives an answer a thumbs-down, that answer becomes a candidate test case, and a dashboard shows whether the answers are getting better or worse.

I don’t ship an assistant without a harness now, and the gates around what agents may touch are the first thing I write.

In 2001 I co-founded Accrisoft, before WordPress took over, and I ran its technology for twenty-two years.

I designed Accrisoft Freedom: a platform that deployed a site quickly and let its owner manage it. Then it grew with the customers: CRM, digital marketing, e-commerce, events, member directories, billing. Then the in-person side of membership organizations: access control, check-in, program registration, fitness, payments, accounting. The customers were YMCAs, Jewish Community Centers, chambers of commerce, and associations. It moved through several generations of infrastructure, from rented servers to AWS to serverless, with thousands of live installations on a common codebase.

It was bootstrapped, with no institutional money. More than $3M a year in revenue and more than 5,000 installations. It was acquired in 2023 and became part of Teamfront, a Mainsail Partners portfolio company.

Twenty-two years on one product showed me the two early decisions that mattered most: the data model, and how one customer’s data is kept apart from another’s. Those get settled before the first feature now.

A European aerial-survey program needed high-resolution photographs of land for agricultural measurement, before web maps existed. Flying a survey means holding exact lines over the ground and triggering the camera at exact points.

What I built was Argus, in C++ on Sun workstations. It read GPS data, optimized the flight route over the survey area, and transferred the plan to an onboard computer. Around it I built software that traced the aerial photographs into map lines automatically, a program for the data cards that flew in the aircraft, and a program that managed a CD-R jukebox. I designed the whole thing front to back, through my own company, Vectrix, and worked on location in Germany.

In the air, differential GPS guided the aircraft along the plan and the system fired the camera at each planned position.

Since Argus, output that someone is going to act on gets checked by code before it goes out.

Quest Solutions sold a DOS earthwork program to contractors, and a contract to rewrite it had gone wrong. I helped rescue it, then joined as a partner and CTO.

I rebuilt the program for Windows, with a 3D model of the site that showed how much dirt had to move. Then I built a product line: Estimator, which priced a job from a blueprint traced on a digitizer; Roadwork, Trenchwork, and Cross Sections; and Visual Assemblies, where a tilt-up wall or a culvert carried its own pricing rules. For ABB in Ludvika, Sweden, I adapted the estimating model to price high-voltage DC converter and transmission facilities. For a commercial contractor, I built bid-day software to compare subcontractor pricing and assemble the final bid.

The company went from shrinking to five years of growth, through four product generations, and the team grew about tenfold. Quest was later acquired.

Since Quest, anything I build that produces a number also shows the model the number came from.

Pleasanton, California, in the first internet boom. PurpleTie picked up your dry cleaning at home and brought it back, with a fleet of drivers to run and a launch date already promised.

I led the whole platform as CTO: online ordering, scheduling, order tracking, and card billing on the customer side; financial reporting, customer service, garment lifecycle tracking, driver dispatch, routing, and scheduling in the back office; and handheld devices. I ran the internal developers, the IT staff, and three outsourced teams, one of them a large shop in India.

It launched on the date promised to investors.

Three outsourced teams and one launch date taught me to write a spec precisely enough that people I’d never met could build from it. I write specs for agents the same way now.

Ericsson’s AXE digital switches are configured in MML, Man-Machine Language, a command language for telecom equipment. Configuring one means producing long runs of those commands, correctly, and Ericsson had teams in Texas and Sweden doing it.

I was a founding technical employee and chief architect at Daleen, and this was my project: a Windows application for those teams. The command generator sat in the middle. It took the configuration data and produced the MML the switch expected. Next to it I built a form generator, a report generator, and a parser for a scripting language. I presented the work to Ericsson in Copenhagen and spent project time in Sweden.

It was one of four multi-million-dollar C++ projects I led there. Daleen later went public.

I still build a generator when I find a team producing the same commands or forms by hand.

A regional home builder tracked every house it had built in one enormous table, with hundreds of columns for costs, permits, contracts, and dates. It needed a system the office could run the business from, and a public site its buyers already knew how to use.

Every home now has one record that follows it from a parcel of land to a warranty call. Construction runs on a milestone checklist, about a hundred steps from permit to closing, so anyone in the office can see where a house stands. Contracts, options, permits, window and shutter orders, insurance policies, and the fee schedule sit beside it. Leads and inquiries from the public site land in the same console. Photos and floor plans publish to the site straight from the record, and the database itself decides who can see what.

Close to nine hundred homes came across from the old table, sold and unsold, with their history intact. The owner has worked through it in rounds of feedback, and it goes live shortly.

This site is the product. A founder or an engineering leader reads it to decide whether a call with me is worth their time, so it is mostly words, set large, around one photograph of the Pando grove.

Behind it is a small publishing system. Every story and paragraph on these pages is a row in Postgres, and I edit them in a private console that previews each block in the site’s own type. The pages are prerendered, so a reader gets plain HTML fast, and a save in the console refreshes only what changed. Each save is checked against my writing rules: no banned words, and a story held between 120 and 200 words. The contact form delivers to my inbox and to the console, behind a rate limit. Drafts are invisible to the public at the database itself, not only in the page code.

It went to production on its second day. It has since moved to a different database and sign-in provider without a reader noticing.

A site that is mostly words needs its rules about words enforced like any other rule, so they run on every save and every build.

Wurzelbuch is German for a book of roots. It is a private place for a family to keep its tree together, with calm, plainly worded screens an older reader can use without help.

Each family gets its own tree, and one person can belong to several and switch between them. People are searchable, with life details, sources, and a note on how sure each record is. Parent and partner links can’t form a loop. The tree draws itself and can be panned, zoomed, and collapsed by branch. Around it sit shared stories, a timeline of memories, and a feed of recent changes.

Owners invite editors and viewers, and a tree can never lose its last owner. GEDCOM files come in behind a preview, the original source files are kept with the records they support, and everything exports again as GEDCOM or JSON, so a family is never locked in. The database keeps one family’s records apart from another’s.

There’s no model inside it. A person enters every link and code checks it. The one research feature assembles a prompt from a person’s evidence in plain code, in English or German, and the reader decides where to paste it.