Archtech Nonprofit Technology Operations
I set up the collaboration foundation for a developing nonprofit, coordinate the contributors building its website, and own the hosting and deployment path that turns private team work into a stable release. The work combines account administration, access ownership, technical communication, release coordination, and hands-on implementation support.
Why the operational foundation comes first
Archtech is a developing nonprofit, so the technical problem is larger than producing a website that looks finished on one computer. The organization needs durable ownership of its accounts, a release path that another authorized person can understand, and a recovery route that does not depend on one contributor remembering an undocumented password.
I established the Google Workspace environment, coordinate the contributors building the private website, and own the hosting and deployment path. I also support implementation, but my central responsibility is continuity across people, accounts, source code, hosting, and the eventual public release.
How work moves toward a release
The working process separates contribution from publication. Contributors can develop and review changes without automatically receiving access to every organizational service. A release becomes ready only after ownership, source state, hosting configuration, and the public result agree.
- Confirm which organizational account owns each service.
- Keep recovery options associated with the organization rather than one personal inbox.
- Define who can contribute, who can review, and who can publish.
- Record the source revision and deployment destination for a release.
- Verify the deployed page directly instead of assuming a successful build means the public service works.
- Keep rollback information available before a change is treated as complete.
Access decisions and handoffs
Access is granted for a role and a task, not simply because someone is part of the project. That reduces accidental changes and makes offboarding easier. It also forces the team to identify the actual owner of a domain, repository, hosting project, or shared workspace before the project becomes urgent.
Handoffs should explain the service owner, authorized administrators, billing or renewal responsibility, recovery path, deployment steps, and current limitations. The goal is for another authorized contributor to continue the work without reconstructing the whole environment from chat history.
Evidence and boundaries
The website source and unfinished organizational material remain private. This portfolio documents my responsibilities, operating decisions, and verification approach without exposing credentials, internal discussions, or work that the organization has not released.
The strongest evidence is operational: organization-owned accounts exist, responsibilities are separated, the deployment path is documented, and the public result will be checked from outside the development environment. The project is still active, so I do not describe the website as publicly launched until that is true.
What this work is teaching me
The project makes the gap between building a page and operating a service concrete. A front end can be correct while account recovery is unclear, a domain renewal is tied to the wrong person, a deployment cannot be reproduced, or the public host serves an older revision.
My next documented milestones are the production launch, a verified release checklist, a recovery exercise, and a concise handoff guide for future administrators.