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.
Approving still happens. Chasing it doesn't.
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.
- Everything is handed overDocumentation written for the person who inherits it, not for me — plus your accounts and your keys. 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.
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 meFor 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.
Systems I built and still keep running. The organizations stay unnamed — the same discretion you'd get.
14 months, 3 sites, one pipeline
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.
6 integrations, 1 sign-on, PII stripped at the boundary
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.
Most people start here
AI and Automation Assessment
2–3 weeksYour systems and workflows inventoried, three to five automation opportunities scored by effort and payoff, a one-page AI governance policy, and a roadmap that says what to do first — and what to leave alone. The fee credits toward any build it recommends.
Content and Publishing Pipeline
about 4 weeksRequest to published draft, wired into the tools your staff already open every morning.
Data and API Integration
2–4 weeksTwo systems that don't talk, made to talk. CRM sync, membership migration, feed automation.
Document Search with Citations
4–6 weeksYour own documents, searchable in plain English, every answer cited back to its source file.
Paid Spec gates every build
Scope, fixed price, and timeline in writing before work starts, with the fee credited to the build. You own the document either way.
Ops Retainer optional, per system
Monitoring, vendor API changes, small changes, a one-page report each month. A build works without one.
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.
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.
Who you'd be working with
Filer Labs is one person: me, Jacob Filer, working out of Missouri. That's deliberate — the person who scopes your project is the person who builds it, and it's why there's only ever one assessment and one build in flight.
Every system on this page I built myself and still keep running. If you'd like to talk to someone I've built for before you commit to anything, ask and I'll arrange it.