Morphism Google Workspace Startup Setup

Source: morphism-google-workspace-startup-setup.md (ingested 2026-03-28)

For a startup like Morphism (technical SaaS + OSS + AI tooling), Google Workspace should mainly support four things: identity, collaboration, operations, and security. Below is what you should enable and structure from day one.

Core Google Workspace apps to enable

Identity / account backbone

Gmail — primary identity for all services and GitHub accounts
Google Admin — user + domain + security management
Groups — role-based mailing lists and permissions
Directory — internal user directory for teams

Collaboration

Google Drive — shared docs, investor materials, design docs
Docs — writing specs, partnership agreements, proposals
Sheets — finance, runway, metrics, hiring pipeline
Slides — pitch deck, technical presentations
Meet — investor calls, engineering sync
Calendar — team scheduling

Operations

Google Chat — async team communication (lightweight alternative to Slack early)
Google Tasks — lightweight task tracking
Forms — intake forms (beta signups, hiring)
Sites (optional) — internal wiki if not using repo docs

Security and reliability

Admin Security Center
Endpoint management
2‑factor authentication enforcement
Vault (email retention / legal compliance)

For a small founding team, Workspace Business Standard is enough.

Google Workspace configuration to do immediately

Domain

Primary domain: kohyr.com

Security baseline

Enforce 2FA for all users
Require hardware keys for admins if possible
Enable phishing and malware protections
Disable external auto-forwarding initially

User groups Create groups early. They become your access control layer.

Examples:

founders@kohyr.com
engineering@kohyr.com
research@kohyr.com
ops@kohyr.com
security@kohyr.com
legal@kohyr.com
finance@kohyr.com
team@kohyr.com

Groups should be used instead of individual emails for permissions.

Recommended email address structure

Founders / humans

first@kohyr.com
first.last@kohyr.com

Operational addresses

hello@kohyr.com — public contact
founders@kohyr.com — internal leadership
team@kohyr.com — all employees
support@kohyr.com — customer support
security@kohyr.com — vulnerability reports
legal@kohyr.com — contracts and notices
finance@kohyr.com — billing and accounting
press@kohyr.com — media inquiries

Engineering / product

dev@kohyr.com
engineering@kohyr.com
infra@kohyr.com
research@kohyr.com

System / automated

noreply@kohyr.com
notifications@kohyr.com
ci@kohyr.com
builds@kohyr.com

These usually route to groups or ticket systems.

Domain aliases vs email aliases

Domain aliases Example:

kohyr.com (primary)
morphism.ai
morphism.dev

If you add a domain alias, every user automatically gets the same address on that domain.

Example: meshal@kohyr.com
meshal@morphism.ai

Use cases

brand protection
product segmentation
regional presence

Email aliases Aliases are alternate addresses for a single mailbox.

Example meshal@kohyr.com
alias: meshal.alawein@kohyr.com
alias: ceo@kohyr.com

Use cases

role addresses
simplified public emails
transitions when names change

Suggested domain strategy for Morphism

Primary domain

kohyr.com

Likely future aliases

morphism.ai
morphism.dev
morphism.cloud

Recommended policy

humans use kohyr.com
marketing domains redirect to website
aliases only used for identity compatibility

Google Groups to create early

Operational groups

founders@
engineering@
research@
ops@
security@
finance@
legal@
team@

External-facing groups

hello@
support@
press@
partnerships@

System groups

alerts@
infra@
ci@

Use groups for:

GitHub organization ownership
cloud IAM access
billing notifications
incident alerts

How to document this in the repository

Create a dedicated operations document.

docs/ops/google-workspace.md

Suggested structure

Sections:

Workspace overview
Domain configuration
Email address conventions
Google Groups
Security policies
Onboarding process
Offboarding process

Example structure

docs/ops/google-workspace.md

Purpose
Primary domain
Domain aliases
Email naming conventions
Standard operational addresses
Google Groups and responsibilities
Admin security policies
Account provisioning workflow

Reference it in governance docs

Add references in:

SSOT.md Add section: Identity and Communication Infrastructure

AGENTS.md Mention that operational communications must use official domains.

CONTRIBUTING.md Add onboarding instructions.

Example:

CONTRIBUTING.md Development onboarding

Request Google Workspace account
Join engineering@kohyr.com group
Link GitHub account to Workspace email

Email naming conventions to document

Rule examples

Humans first@kohyr.com

Service accounts service-name@kohyr.com

Groups plural-role@kohyr.com

Automation system-purpose@kohyr.com

Examples ci@kohyr.com
alerts@kohyr.com
infra@kohyr.com

Other integrations you should plan for

Workspace identity will be used for:

GitHub

organization owners
commit signatures

Vercel

deployment access

Cloud provider

GCP / AWS IAM federation

Domain registrar

DNS management

Analytics

GA4 / Search Console

Payments

Stripe / billing

Investor communication

shared Drive folders

Small but important admin settings

Enable

DKIM
SPF
DMARC

Turn on

Advanced phishing protection
Login alerts
Admin audit logs

Restrict

third-party app access (initially)

Internal documentation locations

Good structure in your repo:

docs/ ops/ google-workspace.md identity.md access-control.md governance/ architecture/ product/

The Workspace doc should live in ops because it’s operational infrastructure.

If you'd like, I can also show you a clean production-grade google-workspace.md template specifically tailored for Morphism’s repo structure and governance model.