Systems that take the manual work out of how a small organization runs.

I'm Jacob Filer. I build automation — increasingly AI — that gets deployed, adopted, and left running, one system at a time. And I'll tell you which of the things on your list you shouldn't build at all.

a request pull the links paste it in fix what the paste broke chase the approval a scheduled draft

The approval step stays, on purpose — it just stops being a scavenger hunt.

How it's priced
Fixed price, paid spec first
Timeline
Weeks, not quarters
Capacity
One assessment, one build at a time
Where it runs
Your accounts, not mine

Where this usually starts

Most of this work begins with a sentence somebody says out loud in a meeting.

“The newsletter takes two days.”

Writing it doesn't take two days. Moving it does — pulling the links, pasting them into the template, fixing what the paste broke, chasing the approval.

What I build insteadA pipeline where the request goes in and a formatted, scheduled draft comes back in your email platform or on your site.

“We export from the CRM and re-key it into the website.”

Every export is a snapshot that starts going stale on the way to the spreadsheet, and re-keying is where the typos come from.

What I build insteadAn integration between the two systems, so there's nothing to re-key and one place to fix a bad record.

“Someone builds the board report by hand every month.”

The numbers already exist. They're sitting in three systems that don't know about each other, and the job is assembly.

What I build insteadThe assembly done on a schedule, so the person who used to rebuild the report reviews it instead.

“We pay for ChatGPT and nobody really uses it.”

This is the common one. 92% of nonprofits and associations report using AI somewhere; 7% have anything to show for it (TechSoup, 2025; n=346). A seat isn't a system.

What closes the gapOne narrow tool pointed at work people already do — not another login.

Very little of this is an AI problem. Most of it is plumbing.

How the work is done

The method matters more than the technology.

Every engagement is shaped the same way, so you always know what you're buying and when it ends.

  • A paid spec before any buildScope, price, and timeline written down and agreed before code starts. You own the document either way — if you take it somewhere else, it still works.
  • Fixed priceQuoted after the spec, not adjusted after the fact. If I estimated badly, that's mine to absorb.
  • One named deliverableNot a general engagement. A specific thing that either exists at the end or doesn't.
  • A hard end dateWeeks, not quarters. Projects that can't be finished in weeks get cut into pieces that can.
  • Your accounts, not mineYour hosting, your API keys, your repository, your data. I work inside them and hand back the keys, because a system that only runs on my logins isn't finished.
  • Documentation someone else could run fromWritten for the person who inherits it, not for me. If the only way to operate the thing is to call me, I built it wrong.
  • One assessment and one build at a timeScope gets protected rather than stacked. It's what keeps the end dates real.
  • Everything is handed overEvery build ships with documentation someone else could operate from. If we part ways, nothing breaks and nothing is held.

What I'll tell you not to build

Most organizations bring me a list. Usually a third of it shouldn't be built.

Some of it is a process problem wearing a software costume — the workflow is broken upstream, and automating it just makes the mess arrive faster. Some of it is a feature you already pay for in a tool nobody has finished setting up.

Some of it would save four hours a month and cost more than that to keep alive. And some of it is work that should keep a person in the loop on purpose, because the cost of being wrong in public is higher than the cost of the manual step.

I'd rather say that in week one than invoice for it in week six. Cutting the list is part of the job, and it's usually the part that pays for itself first.

What I build

Five kinds of work, all of it in production somewhere.

Workflow automation

The copy-paste-between-systems work, automated: CRM to website to email to reporting, with a human approving anything that goes outward.

Content and publishing pipelines

A request goes in one end; a formatted, scheduled draft comes out the other, with approval built into the last step rather than bolted on.

Document search and knowledge tools

Ask questions across your organization's documents in plain English, and get answers with the source cited — the part that makes people trust it.

System integration and custom tooling

APIs, data migrations and cleanup (membership and AMS databases a specialty), internal dashboards, secured behind your single sign-on. If it has an API — or even just an export button — it can usually be wired in.

AI adoption strategy and governance

What to automate, what to skip, and the usage policy most small organizations still don't have.

Not sure which one it is?

Describe the workflow. If it's none of these, or shouldn't be built, I'll say so.

Email me

For the technical person who'll askPython and FastAPI services · Postgres · Cloudflare Workers, D1, KV · WordPress and PHP at a senior level · Okta SSO · MCP for tool integration · multi-provider language-model orchestration with fallback, so one vendor's bad afternoon isn't your outage.

Running in production

Three systems, in daily use.

Clients stay unnamed, which is the same discretion you'd get.

A year-plus in daily production

A content pipeline at a 40-person national nonprofit. Staff post a request in the project tool they already use; a formatted, scheduled draft appears on the website with a reply back on the thread. Three sites, same pipeline.

Plain English in, citations out

Document search across years of organizational files — Word documents, PDFs, old project archives. Staff ask a question and get an answer with the source it came from.

Six integrations behind single sign-on

Wrapping everything from government data APIs to an applicant-tracking system, with personal information redacted at the boundary before it ever reaches a model.

Packages

Fixed price, named deliverable, hard end date.

Every build is gated by a paid spec, so nobody is guessing at scope when work starts, and the spec fee credits toward the build. The price comes back fixed, in writing, before you commit to anything.

AI and Automation Assessment

An inventory of your systems and the workflows that run on them, three to five automation opportunities scored by effort and payoff, a one-page AI governance policy, and a prioritized roadmap that says what to do first and what to leave alone. The fee credits toward any build it recommends, and it satisfies the spec requirement — there's no second spec fee.

2–3 weeks

Content and Publishing Pipeline

Request to published draft, wired into the tools your staff already open every morning, with human approval built into the last step rather than bolted on. The people using it don't have to learn a new system.

about 4 weeks

Data and API Integration

Two systems that don't talk, made to talk. CRM sync, membership data migration, feed automation. Cleanup of the data you inherited is usually part of it, and usually the part that takes the longest.

2–4 weeks

Document Search with Citations

Your own documents, searchable in plain English, with every answer cited back to the file it came from. Scoped to the shape of your document set during the spec.

4–6 weeks

Paid Specgates every build

Scope, fixed price, and timeline locked in writing before work starts, with the fee credited to the build. Paid beats free because you end up with a document you own either way, instead of a sales call.

before any build

Ops Retaineroptional, per system

Monitoring, model and API updates as vendors change them underneath you, small changes, and a one-page report each month. A build works without one — what you're buying is not having to track vendor changes yourself.

monthly

Who this is for

If you own a workflow that's eating your week, you're who I build for.

Nonprofits, associations, and services firms of roughly 10 to 75 people — and it helps if you can get to whoever signs the check. The title matters less than whether you can name the workflow.

Timing tends to matter more than size. The best moment is a growth spurt: the manual process that worked at twelve people stops working at thirty, and that's usually when someone finally goes looking.

What I don't do: brand, design systems, full-site strategy. If that's the actual need, I'll say so and point you somewhere better.

Working together

  • Typically able to start within two weeks.
  • Scoping questions answered the same business day.
  • One call before you pay for anything.

Notes

This is where occasional field notes from real builds will land — what worked, what I got wrong, what I'd skip next time.

Tell me what's costing you the most time.

Describe the workflow, and I'll tell you what I think it takes — or that it isn't worth doing. If it looks like a fit, we'll get on a call before you pay for anything.