Building a Better Engine: The PF TECH Origin Story

PF TECH didn't start at a whiteboard. It started in a filing cabinet.

My first job in the non-profit sector was in 2013 — not the 1990s. A member of my team was printing every email he received, including every reply in the chain, every single time a new message arrived. He was filing the printouts physically, in cabinet after cabinet, row after row. This was not one eccentric person in one unusual organization. It was a pattern I would see, in one form or another, across every organization I worked with for the next two decades.

The tools weren't the problem. The culture around the tools was.

The further into senior leadership I went, the more the pattern compounded. I watched organizations spend six figures implementing new enterprise systems — not because the existing systems had been mastered, not because anyone had conducted a genuine needs assessment, but because the board had approved a budget line and a vendor had made a compelling slide deck. Two years later, with the new system live, the same core problems persisted. Different interface. Same dysfunction.

Across two decades inside non-profits, I saw the same operational decay repeated in every organization:

• Excel used as a glorified calculator, its analytical power entirely untouched
• Privacy officers who had never mapped the exposure surface of the freemium tools their teams were using daily
• Restricted fund compliance tracked in a binder someone updated quarterly, by hand
• Donation reconciliation done manually every month by a finance team member who had simply accepted it as part of the job description — because no one had ever told her it didn't have to be

None of this is a criticism of the people doing the work. The sector attracts extraordinarily capable, mission-driven professionals. The problem is structural. Non-profits have been excluded from purpose-built technology for so long that manual workarounds have been normalized as solutions. The overhead myth reinforces this by making investment in operational infrastructure feel like a betrayal of donors. The starvation cycle does the rest, ensuring that the organizations most in need of modern systems are the least able to invest in them.

The most damaging version of this pattern isn't the outdated system or the manual process. It's the frozen organization — the one that sees the problem clearly, knows there are better options, and still can't move. Because the risk of getting it wrong feels greater than the cost of staying stuck.

In the AI era, that calculus has completely inverted. The cost of inaction is now higher than the cost of any reasonable first step.

When you work inside a non-profit, infrastructure improvements happen under impossible conditions. You are not building on the ground. You are redesigning the aircraft while it is full of passengers, mid-flight, navigating a storm — and the passengers are people who depend on the organization's services, often with nowhere else to go.

The overhead myth does this. The starvation cycle does this. The expectation that every dollar must flow directly to programs — never to the systems that deliver them — does this. It creates an environment where operational investment is perpetually deferred, where the same $40,000 in annual labour cost reappears next year because there was no budget to eliminate it this year, and where the person who identifies the problem is rarely given the authority or the resources to solve it.

I navigated this paradox for years. I built what I could within the constraints I had: Power Automate workflows, advanced Excel models, purpose-built SQL queries feeding dashboards that gave executives the visibility they needed but could not get from their accounting software. These were real solutions to real problems — just constrained by the organizational context I was working in and the tools available at the time.

PF TECH was always the answer to that paradox. By building as a technical solutions company — not inside a non-profit structure — we gained the stability to engineer, test, and refine before deploying. We moved from constant reactive patching to deliberate, forward-looking infrastructure development. The problems are the same. The conditions for solving them are finally right.

When I founded Purpose Forward in 2021, building TERN — our non-profit back-office integration framework — was already in the business plan. But the honest version of that plan required capital. We estimated somewhere north of $300,000 just for initial product development. That number put the timeline in the "someday, if the non-profit achieves significant scale" category. A real plan, but a slow one.

What changed by 2025 was not the vision. The cost of execution collapsed.

I started building internal tools through AI-assisted development — not from a formal product roadmap, but out of curiosity and a need to take back control of my organization's data and stop paying for SaaS subscriptions that didn't quite fit. I was rebuilding in hours what had previously taken weeks. Replacing manual interfaces I used to maintain for each client with clean API configurations that let AI agents retrieve and process the same data inside existing interfaces.

The most striking part was not the speed. It was the realization that I had already built all the underlying logic — in Power Automate, in Excel, in custom SQL scripts — across years of solving sector-specific problems inside real organizations. The AI was the new, far more capable wrapper. And that wrapper was collapsing toward negligible cost. The $300,000 product development estimate did not become $150,000. It essentially disappeared.

The sector has not yet fully internalized what this means.

Twenty years of it, accumulated inside real organizations, solving problems that no general-purpose tool was ever designed to address.

The tools I am now engineering into TERN are not new ideas. They are translations of solutions I built, again and again, across different organizations, in the tools that were available at the time:

• Donation reconciliation workflows — built in Power Automate, manually maintained, rebuilt for each new client — are the foundation of TERN's gift processing capability
• Restricted fund tracking spreadsheets — sophisticated enough to embarrass some accounting software — are the foundation of TERN's fund and grant management capability
• Multi-departmental budget models — version-controlled by hand across email threads — are the foundation of TERN's collaborative budgeting capability

We are currently building a conversational budget agent that does something no general-purpose tool will ever do: it engages the right stakeholders at the right moments — the Executive Director for strategic context, the Finance Committee Chair for governance priorities, the fundraising director for revenue targets, department heads for operating expenses, HR for staffing projections. It coordinates their inputs, resolves conflicts, and once the designated financial authority approves the consolidated plan, publishes the final budget directly to QuickBooks Online.

This is not a form-filling workflow. It is an agent that understands non-profit budget structures, fund accounting logic, and the governance relationships that determine how decisions get made inside a charitable organization. No general-purpose AI platform will build this, because no general-purpose AI platform has been in the budget meetings we have been in.

The CPA Ontario Not-for-Profit Conference in November 2025 was a turning point — not because of any single insight, but because of what the aggregate conversation revealed about where the sector actually stands.

The room was populated by exactly the professionals who need this infrastructure most: finance leaders, executive directors, board members. The conversation about AI was not theoretical. It was immediate, practical, and, most revealingly, anxiety-laden. The question was not whether AI would change their organizations. The question was whether they would have any say in how.

What crystallized for me that day was that the opportunity is not primarily technical. The tools exist. The question is whether organizations have the frameworks, the policies, and the leadership context to use them responsibly and effectively. The barrier is not capability — it is informed confidence.

That realization is why the Mission Multiplier Program exists. Why the AI Governance Advisory exists. Why every element of PF TECH is structured around building capacity in the sector — not just deploying technology into it. The infrastructure only matters if the people using it know what to do with it.

The structure that makes all of this work is not just a product roadmap. It is a model for how every element of PF TECH compounds on the others.

Strategic Partners are Stage 1. Their real operational challenges surface what is worth building. Their workflows validate whether what we have built actually works. Their results generate the proof points that demonstrate the approach to the broader sector.

The Mission Multiplier Program is Stage 5 — the point where tools pressure-tested with partners become available to a wider cohort of practitioners. Every MMP participant is a future product validator, a future referral source, and a future potential partner.

The AI Governance Advisory is the throughline that keeps all of it honest — ensuring that as the technology evolves, the governance frameworks evolve with it.

None of these are separate offerings. They compound. Each stage makes the next one stronger. That compounding is the business model, the product strategy, and the theory of change, all at once.

The most important design decision we made early was to not build in isolation.

PF TECH's Strategic Partnership program is a deliberate co-creation model. A small, boutique portfolio of Canadian non-profits work with us in an embedded capacity — their real operational challenges directly shape what we build, how we prioritize, and how the tools evolve. Partners are not clients testing a finished product. They are co-authors of the system, and their operational reality is the best R&D environment we could design.

The space is intentionally limited to five to seven organizations at a time — not because of capacity, but because the depth of the co-creation relationship requires it.

If your organization is spending operational capacity on problems that should be automated — and you want your specific challenges to shape the infrastructure that could serve the entire sector — the conversation starts here.