Engagement Lifecycle

Companion to time-tracking-and-billing.md. This doc covers how engagements begin, run, and end. Time tracking applies once an engagement is live; this doc covers everything around it.

Concepts

Client vs. engagement

A client is a long-term relationship. An engagement is a scoped piece of work for that client. One client can have multiple engagements, often running in parallel.

Example: Xenter is a client. Cloud Platform is one engagement. IT is a second engagement. A future Confidential AKS Migration might be a third. Each engagement has its own SOW, lead, Toggl project, and line items on the invoice. They share an MSA, share a client relationship manager, and aggregate up to the same Mercury customer.

Why this matters: trust grows at the client level, scope is managed at the engagement level. Multiple engagements per client is a healthy signal — usually means trust is high.

Contract structure

Meseta defaults to MSA + SOW:

• Master Service Agreement (MSA) — the relationship-level contract. IP terms, IP carve-outs (Meseta frameworks), confidentiality, indemnification, term, termination rights, governing law, dispute resolution. Negotiated once per client. Long-lived.
• Statement of Work (SOW) — the engagement-level contract. Scope, deliverables or success criteria, engagement model (T&M / retainer / fixed / equity), rate card, term, billing rhythm. Negotiated per engagement. Can be amended without touching the MSA.

This structure lets us:

• Add new engagements without renegotiating IP terms each time
• Swap engineers without contract amendments
• Wind down one engagement while preserving the client relationship

Single-document combined contracts are an anti-pattern unless the client is small, one-shot, and unwilling to negotiate two documents.

Engagement models

Model	When to use	Risk profile
T&M monthly arrears	Default. Open-ended technical work.	Low — client pays for actual hours, monthly cash flow.
Retainer (pre-paid)	Client wants priority access; predictable monthly relationship.	Medium — must track burn-down, manage rollover, refund obligations.
Fixed-price project	Tightly scoped deliverable, mature requirements.	High — Meseta eats overruns. Rare.
Equity-included	Strategic partnership, early-stage client.	Highest — illiquid compensation, alignment risk.
Strategic conversion	Hybrid: pre-paid retainer converts to equity at a defined event.	Highest — combines retainer and equity risk. The original Xenter contract was this shape.

Default is T&M monthly arrears. Anything else is a deliberate choice with founder approval.

The phases

1. Lead / Discovery

Before there's a contract. Conversations to understand what the prospective client needs and whether Meseta can help.

Owner: Founder.

Key questions:

• Is the work in scope for Meseta (cloud, platform, AI, socio-technical systems)?
• Is the client a fit (compliance-aware, technical leadership, willing to pay boutique rates)?
• Rough sizing — is this a 40-hour engagement or a 400-hour one?
• IP risk — is there anything here that conflicts with Meseta frameworks or the founder's other commitments (Upbound)?
• Existing client? If yes, much of this is already known and discovery is fast.

Output: one-page engagement brief, internal only, in engagements/{client}/{engagement}/brief.md. Captures the founder's read of the opportunity. Lives in the Meseta vault, not shared with the client.

2. Proposal / SOW

Translating discovery into a written agreement.

Owner: Founder.

Components:

• Scope (what's in, what's out — explicit on both)
• Engagement model
• Rate card (engineer assignments and rates for this engagement)
• Deliverables (fixed-price) or success criteria (T&M)
• Term and termination
• Billing rhythm (monthly arrears default)
• Engagement-level non-billable allowances (e.g. kickoff hours, included monthly office hours)
• Reference to MSA for IP, confidentiality, indemnification

Output: signed SOW. Stored in engagements/{client}/{engagement}/sow.pdf and any negotiation drafts in engagements/{client}/{engagement}/sow-drafts/.

3. Kickoff

The first one to two weeks of the engagement. Engagement infrastructure gets stood up.

Owner: Founder + assigned Lead.

Checklist:

• [ ] Toggl project created, billable defaults set, rate overrides applied
• [ ] Toggl project mapped in rates.yaml (ops repo)
• [ ] Mercury customer record created (or verified existing)
• [ ] Client Slack channel or shared workspace
• [ ] Engineers introduced to client team
• [ ] First milestone or sprint goal set
• [ ] Communication cadence agreed (weekly sync, async-only, etc.)
• [ ] Compliance/security onboarding if needed (BAAs, SDLC docs, access provisioning)
• [ ] Engagement brief updated with final terms (in vault)
• [ ] Kickoff complete — engagement marked live in vault

On kickoff billing: kickoff time is often partially non-billable. Either written into the SOW as included onboarding, or capped at a number of hours. Generosity here builds trust and gets the engagement to productive work faster. Make this explicit in the SOW so engineers know how to track it.

Output: engagement is live. First time entries can be tracked.

4. Execution

The bulk of the engagement. Time tracking and reconciliation handbook applies as written.

Roles

Role	Owner	Cadence	Scope
Strategic	Founder	As-needed; quarterly minimum	Direction, escalations, contract questions, expansion conversations
Weekly client comms	PM	Weekly	Status updates, schedule, deliverable visibility, calendar
Day-to-day engagement lead	Lead engineer (one per track)	Daily as needed	Technical decisions, sprint execution, day-to-day client requests within scope

For Xenter currently: founder plays Platform Lead until handoff. Once a Lead is in place, the founder steps back to Strategic.

The Lead handoff is itself an event worth marking. The doc should be updated to reflect the new Lead, and there should be a brief introduction to the client identifying the new Lead's authority.

Cadences

• Daily: engineers track time, async client Slack as needed
• Weekly: PM publishes status update to client (format negotiated at kickoff). Engineers submit Toggl week (per time-tracking-and-billing.md).
• Monthly: founder reviews engagement P&L. Pre-invoice check-in with client (asynchronous is fine) so the invoice is never a surprise. Invoice goes out per the reconciliation flow.
• Quarterly: founder + client strategic review. Are we delivering value? What's next quarter? Any scope drift to address? This is also the moment to surface expansion opportunities or wind-down signals.

Scope change protocol

When the client asks for something outside SOW:

1. Engineer flags it in Slack or in the engagement channel: "Heads up — this is outside our SOW. Tagging founder."
2. Written scope-change note added to engagements/{client}/{engagement}/scope-changes.md with date, requestor, what was asked, who flagged.
3. Founder decides within 48 hours:
   • In scope — minor, absorbed, no SOW change. Note marked resolved.
   • In scope but noted — at the boundary, doing it as a one-time accommodation. Note marked resolved with a caveat.
   • Out of scope, SOW amendment needed — pause the work, draft amendment, get client sign-off, resume.
4. Client is communicated with by the appropriate role (PM if it's a small clarification, founder if it's an amendment).

The written note matters even when the answer is "in scope, do it." Pattern recognition over time across engagements is more valuable than the disposition of any single request.

Engineer rotation

If an engineer leaves the engagement (rolling off, taking other work, performance):

• Client is informed by the founder, in advance when possible
• Knowledge transfer to remaining engineers, documented in the engagement vault
• Toggl project membership updated
• Access credentials transitioned

Some clients have approval rights over engineer changes (Xenter likely will, given compliance posture). Document this in the SOW.

5. Wind-down / Close

Engagements end three ways:

• Natural completion — fixed-price delivered, T&M work concluded, retainer expired without renewal
• Client-initiated termination — budget, strategy change, dissatisfaction
• Meseta-initiated termination — rare. Bad client, unmanageable scope creep, ethical issues, non-payment.

Owner: Founder.

Checklist:

• [ ] Final invoice sent (with any retainer reconciliation if applicable)
• [ ] Knowledge transfer artifacts delivered (runbooks, docs, repo handoffs)
• [ ] Meseta engineer access to client systems revoked
• [ ] Client testimonial or case study request (with permission, when appropriate)
• [ ] Light retro: written notes only if the engagement was difficult or learning-rich. Stored in engagements/{client}/{engagement}/retro.md.
• [ ] Engineer rolloff — what's next for them? (See "Engineer bench" below.)
• [ ] Engagement archived in vault — moved to engagements/{client}/_archive/{engagement}/ or marked status: closed in frontmatter

Output: closed engagement, archived. Client relationship may continue or end; engagement is over either way.

Engineer bench

Meseta engineers are 1099 with no guaranteed hours. When an engagement ends or hours dry up, the engineer is "between engagements" — not a payroll problem, but a relationship problem if you want to keep them.

Three patterns for retention:

• Pipeline visibility — share loosely what's in the funnel so they can plan their other work around expected Meseta hours
• First-look agreement — informal handshake to bring them new work first when it lands
• Bench retainer — small monthly retainer to keep a proven engineer warm during dry spells. Use sparingly, only for engineers we strongly want to retain.

This is a "later" problem but worth surfacing during the wind-down checklist so the engineer doesn't go silent.

Vault structure

projects/meseta/
├── handbook/
│   ├── time-tracking-and-billing.md
│   ├── engagement-lifecycle.md          ← this doc
│   ├── engineer-onboarding.md           (TODO)
│   └── ...
├── engagements/
│   ├── xenter/
│   │   ├── msa.pdf
│   │   ├── client-context.md
│   │   ├── platform/
│   │   │   ├── brief.md
│   │   │   ├── sow.pdf
│   │   │   ├── scope-changes.md
│   │   │   ├── notes/
│   │   │   └── retro.md (if applicable)
│   │   └── it/
│   │       ├── brief.md
│   │       ├── sow.pdf
│   │       ├── scope-changes.md
│   │       └── notes/
│   └── _archive/
└── ...

engagements/ becomes the canonical place to find anything about a specific engagement. The handbook describes how things work in general; engagements/ holds the specifics for any given case.

Operating principles

• MSA is sacred, SOW is flexible. Renegotiate scope freely, never IP terms.
• Engagements end. Relationships continue. Wind-down is about closing the engagement well so the relationship can produce another engagement later.
• Written scope changes, even for "yes." The trail is more valuable than any single decision.
• Founder owns strategic, PM owns weekly, Lead owns daily. This is what scales past one engagement.
• Multiple engagements per client is a success signal. Look for natural expansion at quarterly reviews.
• Generosity at kickoff, discipline in execution. Free hours upfront buy goodwill that compounds; sloppy hours during execution erode it.

Open items

• [ ] Draft Meseta MSA template (with founder's lawyer)
• [ ] Draft Meseta SOW template — T&M variant
• [ ] Draft Meseta SOW template — retainer variant
• [ ] Define engagement-brief template
• [ ] Define scope-change note template
• [ ] Migrate existing Xenter engagement materials into the engagements/xenter/ structure once new contract is signed
• [ ] Add Lead handoff protocol once first handoff is imminent

Related docs

• time-tracking-and-billing.md — applies during execution phase
• branding.md — brand
• engineer-onboarding.md — TODO