Pathway to Hope.

I came to Canada from Pakistan in 1999, as a kid. Pathway to Hope started as a way to return some of what this country gave my family.

The specific reason was my brother. Watching him struggle with his mental health taught me how much of the available help doesn't actually fit the person needing it. What my family found rarely accounted for our culture or our faith, and we went through most of it feeling unsupported. Later my co-founder, Jessica Qubrossi, told me about a youth services program that shut down with a few weeks' notice, leaving vulnerable young people to find somewhere else to go. We built the organisation around both of those gaps.

I built the first version of everything and still handle much of the technical side, now alongside the team. In practice that has meant being the whole IT function for an organisation that could never have afforded one.

• Set up the identity and collaboration stack the team works in: Google Workspace, Slack, and Notion, with access rules that suit an organisation staffed largely by volunteers
• Manage the device fleet through Mosyle, which is all MacBooks
• Automated volunteer offboarding. Access ends either when someone tells us they're done, or on inactivity: two weeks idle prompts them to sign back in, and after a month without activity access is revoked automatically. I still follow up by hand, because some people simply stop answering
• Built the sensitivity analyzer that reviews every lesson in the course library. A model scores the content against a weighted rubric I wrote with the team: certain topics escalate a lesson to the highest level on a single hit, others add to a running score, and the result is written back so readers see a content advisory before they open it. Material for young people dealing with difficult subjects should warn them what is inside, and no one should have to re-read the whole library by hand to keep those warnings honest
• Handle vendor selection, negotiation, and procurement on a nonprofit budget, where the difference between two tools is often whether one has a nonprofit tier
• Built AI review into our content process: it flags language that could be hard on a young reader, keeps the voice consistent across writers who each have their own style, and checks that required terminology is present

No budget. Everything was self-funded at the start, and that decides a lot of your architecture for you. Google's nonprofit program is the reason we got moving quickly. Without free tiers aimed at organisations like ours, most of what we run wouldn't exist.

Access, with volunteers coming and going. This was the piece that mattered most, and the piece I would do the same way again. We split our information three ways: public, volunteer, and private. Public is public. Volunteers get what their work requires and nothing beyond it. Private is for employees, subdivided by role so a person's access matches what they actually do. That meant building a real permissions table and arguing through what belonged where, which was worth doing once instead of deciding it fresh every time someone joined or left.

We also put a notice on every page showing when it was last updated and how long the information stays valid. In an organisation where the people rotate, that turned out to matter nearly as much as the permissions did.

Deciding once where information lives is what stops it leaking out through everyday choices. The timer does the part people forget.

Writing policy with no HR function. We did it in house at the beginning because there was no alternative. Later we brought in an HR company to take it over properly. The rules themselves started simple and grew, because each new problem we hit was one nobody had thought to write down yet. I'd rather that than a policy binder written up front by someone guessing at what might happen.

Privacy obligations with no compliance team. The same three-tier split did most of that work.

Course content is free and openly licensed at pathwaytohope.ca.