Blog

Every nonprofit I’ve ever gotten a look inside has the same piece of furniture: a spreadsheet with forty-seven tabs that has become the real database, because the real database is a subscription nobody trusts and nobody has time to fix. The spreadsheet works. It’s horrible, but it works, and the people running it are already at capacity.

That’s the honest starting point for talking about automation at a nonprofit: the problem was never that the tools don’t exist. The problem is that every hour of a nonprofit’s day is already spoken for, and most automation advice arrives as one more thing to learn, one more subscription to justify, one more “digital transformation” to survive. Nonprofits don’t need transformation. They need the forty-seven tabs to stop being a full-time job.

So here’s what we’d automate, and what we wouldn’t.

Yes: the filing cabinet

Donor records with three spellings of the same name, because three different people entered them across five years. Grant deadlines that live in the executive director’s calendar and nowhere else. An intake inbox where a family’s request for help can sit for three days because everyone assumes someone else answered it. These aren’t glamorous problems. They’re the actual job, and they’re exactly what automation is for — quiet, structural, human-in-the-loop fixes that make the honest work easier to do.

The rule we use is the same one we use everywhere: if a task happens more than twice and doesn’t need judgment, it should run itself. If it needs judgment, a machine should draft it and a human should decide. Volunteers and staff get their hours back for the parts of the mission that need humans — which, for most nonprofits, is almost all of it.

No: the megaphone

There’s a certain kind of AI pitch that keeps circling the nonprofit sector, and it’s the same one circling small businesses (I wrote about one of its salesmen in The openclaw guy): AI-generated outreach, blasted at scale, to keep your name in front of people. For a nonprofit, this isn’t just ineffective — it’s a way to spend the one asset the sector runs on, which is trust. A supporter who feels like a lead is a supporter who’s halfway out the door.

We won’t build that. We also won’t build a chatbot that answers a desperate person’s message with a cheerful deflection, or a “strategy” that requires hiring someone to maintain it. If automation can’t make the work more human, it’s not automation — it’s overhead with a demo.

The boring offer

We’re a small shop that builds and operates software for a living, and we keep a standing offer for nonprofits: a half-day automation audit, then small fixed-scope projects at nonprofit pricing, and pro bono work for the right organizations. Details are on our for nonprofits page.

The spreadsheet with forty-seven tabs isn’t a moral failing. It’s a sign that nobody’s been allowed to fix the boring stuff. That’s the work we’d like to do — so the spreadsheet becomes one tab, the deadlines nag politely, and the humans get back to the mission.

A friend of mine runs businesses in a world where people sell AI services to other small businesses. Last week he told me about a guy. For five hundred dollars, the guy will introduce your small business to AI — “openclaw,” specifically, an open-source assistant project that is real, free, and genuinely interesting. The five hundred dollars buys the introduction.

I’ve known this guy since the 1980s, is the thing. Different toolbelt, same smile. Every wave of technology grows a crop of people who sell the wave itself instead of the things you can do with it — and they’re not always wrong. The tools are real. The enthusiasm is real. Some of them genuinely believe they’re helping.

What tells you which kind you’re dealing with isn’t the pitch. It’s the use case. Somewhere in the openclaw guy’s material there was a plan to use it for bulk email — small businesses marketing tax-season services to other small businesses, at scale, with AI doing the writing. That’s the moment the session stops being about teaching and starts being about spam with a certificate.

And look, I want to be fair. Five hundred dollars is a cheap education, and plenty of people have paid more to learn less from people who meant well. The grift, such as it is, is mostly a tax on hope — charged to people who are told the future is arriving faster than they can learn it, and that the way to keep up is to pay someone to unlock it for them.

Here’s the honest version: I don’t run openclaw — I run Hermes, a different assistant in the same space, and I chose it that way on purpose. My agents draft, triage, watch things, and — this is the part that matters — they mostly keep quiet when nothing is wrong. If you want to understand openclaw, Hermes, and the whole landscape around them, I’m glad to walk you through it. That conversation is free. The difference between running your own agents and the five-hundred-dollar version isn’t the software. It’s the assignment. Automate the things you’d otherwise do yourself, and you’ve bought back your time. Automate the things you’d otherwise ask strangers to read, and you’ve bought yourself a reputation.

So if you meet the openclaw guy, be kind. He’s probably teaching himself by teaching others, and there are worse ways to spend a life. But keep your wallet in your pocket until he shows you what it actually automates — and if the answer is “bulk email,” wish him well and walk away. Somebody’s small business is the product, and it isn’t his.

If you’ve got five hundred dollars burning a hole in your pocket, a local nonprofit could put it to work — or we could automate something real for them. That’s a nicer kind of introduction to AI.

Announcement: the standard we build Dart and Flutter software to is now public — github.com/taybiz/dart-flutter-bible.

To be clear about the name: it’s a bible the way a reference manual is a bible — we don’t do dogma, and the first rule in the repo says the standard changes by proposal, never by drift. If the toolchain or the team shows a better way, we update the document on purpose. We never let the codebase quietly diverge and pretend otherwise.

The repo is under taybiz, the company’s GitHub organization — which is also mine; there’s no corporate shell between the work and the person doing it. It collects what we’ve learned about structure and rules across Dart and Flutter projects, including CLI tools: one architecture, one error-handling style, one testing idiom, so that a developer who has seen one of our repos has seen them all. Onboarding gets faster and reviews get cheaper, while the business logic stays testable and portable.

Inside you’ll find numbered docs rather than vibes:

• Architecture — the “bulls-eye,” the four laws, and why we never let the UI talk to a database.
• Toolchain & topology — how repos are laid out, one-workspace vs. split repos, and why melos is a smell.
• Functional core — fpdart, typed failures, no exceptions inside the domain.
• Persistence — Drift for SQLite, sembast for file stores, and contract suites so swaps don’t lie.
• Testing — the “should be” idiom, Given/When/Then, and a layer matrix that says what each layer may mock.
• Builders & codegen — mostly “don’t,” with the exceptions named.

Why make an internal standard public? A standard that can’t be read is just a habit with better marketing — publishing forces us to mean it. The teams we work with can read ahead, so when we train or mentor your engineers, we’re teaching from a document rather than tribal memory. And public standards get argued with, which is how they get better. If a rule in there conflicts with your gut, file an issue — that’s the proposal mechanism working.

It’s also a promise about the code we ship: every Dart repository you’ll find on this site’s work page follows the same doctrine. We practice what we publish.

Read it, use it, fork it. And if you’d like this standard — and the person who maintains it — working inside your team, let’s talk.

Nobody ever got promoted for keeping the lights on. That’s a shame, because keeping the lights on is most of what infrastructure is for — and the better you do it, the less anyone notices.

I’ve spent a long career learning to make systems boring, and I mean that as the highest compliment. A boring system is one where the backups run without anyone thinking about them and the deploy is a button instead of a ceremony. The monitoring page is so quiet you forget it exists. The interesting stuff — the incidents, the postmortems, the heroics at 2am — is almost always the tax you pay for infrastructure that stopped being boring somewhere along the way.

The discipline is in the quiet. Alerts should fire only when a human can actually act, which means most alerts should be deleted, not tuned. Cron jobs should say nothing when nothing is wrong — silence is a feature, not a bug. And when something does break, the fix shouldn’t be a faster hero; it should be a structural change that makes that particular heroics unnecessary forever.

This website is a small working example. Its content pipeline runs on a schedule and a REST API: an agent checks in, pushes changes as drafts, verifies them, and only then publishes. On a good day it produces zero notifications, because a good day in operations is one where nothing needed a human. The owner — me — doesn’t babysit it. The structure does.

That’s the offer, in miniature: software and infrastructure engineered so that the interesting parts are the product you asked for, and the boring parts stay boring. If your systems are currently providing you with plenty of 2am excitement, you know exactly what I’m talking about — and you know what the fix looks like.

Taybridge is small. It didn’t used to be — there was a version of this company with more people, more process, and more meetings whose only purpose was to schedule other meetings. That version is gone, and I want to be plain about it: going small wasn’t a retreat. It was an edit.

Here’s what a small senior shop actually sells: judgment, not hours. When you hire me, the person who scoped the problem is the person who writes the code, and the person who writes the code is the person who answers the email at 11pm when the deploy goes sideways. There is no telephone game between sales, delivery, and support, because there is no telephone — I’m all three.

That comes with a trade, and I won’t pretend otherwise. A shop this small has a bus factor. It can’t staff a death-march sprint with warm bodies. If you need a ten-person delivery team next quarter, hire a ten-person firm — seriously, that’s the right answer, and I’ll tell you so. But most companies don’t need a team. They need one senior person who actually gives a damn, and they need them on the hard 20% of the work, not supervising the other 80%.

Big firms sell certainty — process, headcount, a logo on the proposal. Small firms sell something rarer: the absence of friction between what you asked for and what gets built. Every dollar you spend with me goes to the work, because there is no bench, no office, and no middle layer to amortize.

A few ground rules I’ve earned the right to state plainly: small projects are welcome if they’re interesting, because interesting work keeps the judgment sharp. Fixed bids happen when the scope is clear, and not before — “we’ll figure it out” is how fixed bids become change orders. And if a job needs more hands than I have, you’ll hear that on day one, not month six.

There’s a line I keep coming back to: the goal is never to be clever, the goal is to be finished. Small is how I stay able to finish things. If you’ve got something that needs finishing — properly, once, with the structure in place so it stays finished — that’s the conversation I’m good at.

The contact page on this site used to offer visitors the chance to reschedule their event, provided they gave 45 days’ notice and paid in full for any perishable items.

We are not an event company. We do not have perishable items. That page was the moment I understood what we’d been handed: a wedding-vendor template wearing my company’s name — and nobody had noticed, because nobody important was looking.

Which is fair. This is a small company’s website. Almost nobody visits it. But almost nobody visiting is not the same as nobody caring, and a website that lies about you is worse than no website at all. So we replaced it.

Not with another template, and not through the dashboard — this site doesn’t really have one, at least not for me. Every page you’re reading was written as plain files and pushed into WordPress through its REST API with an application password, by an AI agent I direct from Slack. I have not logged into wp-admin in weeks. I’m not sure I remember the URL.

The stack is boring on purpose. WordPress because it’s what the hosting plan offers and it works; REST because it’s the standard interface; an application password because it’s revocable and can’t log in. The interesting part is the pipeline: content lives as code in a project folder, every change is pushed as a draft first, verified, and only then published — never blind — and a snapshot makes rollback a single call. Deletes go to the trash.

It’s the same pattern we’d build for your company’s operations. If a website can be run this way — no dashboard, no vendor lock-in, no third-party cloud relaying your data — most business software can.

Which brings me back to the wedding template. The reason it survived is the same reason bad software survives anywhere: nobody was looking, and nothing enforced the truth. The fix wasn’t discipline. The fix was structure — a pipeline where content comes from code, and a human with standards reviews what ships. This site is that fix, running in public.

And yes: an AI agent wrote most of this, in my voice, from notes I actually believe. If that bothers you, good. It’s exactly the kind of thing you should have questions about. Ask them.