An active-build, modular, multi-tenant operations platform for service-led SMEs. Tessera connects CRM, sales pipeline, project delivery, controlled service requests, and administration in one governed operating layer.
Executive summary
Status
Active pilot build
My role
Founder, product architect and hands-on builder
What shipped
CRM, pipeline, project delivery, governed service requests, and administration in one operating layer.
Evidence
Connected CRM → Pipeline → Projects workflow with organisation-scoped access controls.
Overview
The Problem
Growing service businesses often manage customer relationships, sales activity, project delivery, and support requests in separate tools or loosely connected spreadsheets. Sales context is lost at handover, accountability is unclear, and teams lack a reliable operational record.
The Opportunity
Create a practical operating layer across CRM, sales pipeline, delivery projects, controlled service requests, and administration—without turning the first release into an unfocused all-in-one suite.
My Role
Product architect and hands-on builder, shaping the pilot workflow, multi-tenant architecture, access model, domain boundaries, operational UX, and delivery sequencing.
Design Pressures
Architecture Decisions
Tessera is being built as an operational SaaS product rather than a collection of disconnected tools. The architecture keeps the pilot focused while protecting tenant boundaries and leaving room for validated automation and modules later.
Portal
Next.js, React, and MUI provide a dense operational SaaS interface built around summary metrics, scannable tables, filters, segmented views, and compact workflows.
API + Worker Foundation
Fastify provides the application boundary, while a separate worker foundation leaves room for background automation as validated workflows require it.
Data + Shared Contracts
PostgreSQL and Drizzle underpin tenant-owned data and migrations; shared packages keep validation contracts aligned across runtime boundaries.
Access + Operations
Clerk handles hosted identity, with Tessera owning organisation membership, roles, permissions, licences, module availability, configuration, and audit history.
Core Runtime Flow
Why These Decisions
Workspace monorepo with clear runtime boundaries
Why: The customer portal, API, worker foundation, database migrations, and shared validation contracts need to evolve together without becoming one tightly coupled application surface.
Architecture outcome: A maintainable foundation for operational workflows and background automation without retrofitting the core structure later.
Organisation-scoped data from the start
Why: CRM records, opportunities, projects, tickets, and audit activity must belong to a tenant by design, not through a UI convention.
Architecture outcome: PostgreSQL provides the source of truth while Drizzle brings schema definitions and migration discipline to customer-data boundaries.
Identity separate from product access
Why: Hosted authentication solves identity and session management, but Tessera still needs to govern organisations, memberships, roles, permissions, licences, modules, and business configuration.
Architecture outcome: Clerk can handle authentication without displacing the platform's tenant-specific access model.
Server-enforced module and permission checks
Why: Module availability and permissions cannot be treated as frontend concerns when users can reach an API outside the visible interface.
Architecture outcome: Each action can require the appropriate organisation context, module entitlement, and permission across CRM, Pipeline, Projects, Service Desk, and Admin.
Audit history as a platform capability
Why: Service teams need a dependable operational record of business changes, access changes, stage movement, and handoffs.
Architecture outcome: Meaningful actions are designed to create audit events, establishing a stronger foundation for future compliance, support, and operational review.
Core Pilot Workflow
The first proof workflow is deliberately tight: manage customer relationships and opportunities, make sales progress visible, turn won work into delivery projects, and keep the controls needed to run that workflow safely.
CRM is the source of customer context; Pipeline is an entitlement-backed sales workspace over the opportunity record rather than a separate sales product.
Projects is the operational destination for won work, designed to preserve the important context of the opportunity as delivery begins.
Service Desk is intentionally manual and gated during the pilot, prioritising governed support context over premature automation.
A structured collaboration area supports reviewed conversion into CRM and Projects without broadening the product into generic whiteboarding.
Admin and Operational Control
Administrative controls are not an afterthought. They make it possible to keep each tenant's data and workflows secure while supporting a focused pilot today and measured expansion later.
Access Management
Organisation memberships, invitations, roles, permissions, and module licences keep access tied to the right tenant and level of responsibility.
Entitlements
Module availability supports a focused pilot now and controlled commercial expansion later, without allowing packaging concerns to dominate the first user experience.
Audit History
Record changes, access changes, pipeline movement, and project handoffs are designed as auditable business events rather than incidental logs.
Organisation Settings
Business configuration remains a first-class administration concern, keeping the product adaptable to tenant needs while the core model stays governed.
Tradeoffs and Constraints
Tessera is deliberately sequenced around product validation as much as feature delivery. The active build favours a controlled, useful operating workflow over premature coverage of every adjacent need.
Focused workflow before a marketplace of modules
Rationale: The CRM → Pipeline → Projects path has to prove daily operational value before optional areas receive comparable investment.
Tradeoff: Some adjacent needs remain outside the primary pilot path even though the architecture can support them later.
Pipeline extends CRM rather than standing alone
Rationale: Sales visibility is most useful when it works on the same opportunity context that delivery will inherit.
Tradeoff: The product deliberately avoids positioning Pipeline as a broad, disconnected sales suite.
Manual, gated Service Desk before automation
Rationale: Support workflows need to prove their required context and controls before email intake, SLAs, and customer-facing portals increase complexity.
Tradeoff: The pilot does not yet offer the breadth of a mature help-desk platform.
Operational density over dashboard theatre
Rationale: Service teams benefit from compact workflows, filters, metrics, and tables that help them take the next action.
Tradeoff: The interface is intentionally less card-heavy and decorative than a marketing-led SaaS dashboard.
Outcomes and evidence
Tessera is an active build. The evidence today is the connected workflow, tenant-aware access model, and platform foundation already in place for controlled pilot validation.
Delivery evidence
What I'd Improve Next
The next focus is controlled validation with service-led teams: prove the end-to-end sales-to-delivery workflow, refine the details that matter most in daily use, and let feedback determine which modules should follow.
Validate the end-to-end CRM-to-Pipeline-to-Projects workflow with service-led pilot teams.
Refine the highest-value operational details from observed team behaviour and feedback.
Use evidence from pilot use to decide which optional modules should follow the core workflow.
Introduce background automation where validated workflows, rather than speculative scope, justify it.
Extend Service Desk only after its controlled, linked-ticket model has established the right operating patterns.
Contact
I can help shape the product boundaries, access model, and delivery architecture so a focused workflow becomes a reliable platform foundation.
