LeadOps Portal
A multi-tenant operating surface for qualification, approval, automation, incidents, and reporting.
I independently defined the product, designed the architecture and data boundaries, planned and reviewed implementation, designed acceptance, and owned final delivery.
- Role
- Independent product owner and engineer
- Capability proof
- Shows end-to-end product ownership across multi-tenancy, human approval, workflow operations, incident handling, reporting, and a bounded public-demo target.
- Technology
- TypeScript · Next.js · Node.js · PostgreSQL
Context
An automation agency can receive leads from several sources, qualify them with a provider, request a human decision, continue a workflow, and still need to explain incidents and outcomes to each client. These are not separate screens. They form one operating loop in which tenancy, authority, retries, and reporting have to agree.
LeadOps is a portfolio product snapshot for that loop. I independently defined the product, designed the architecture and data boundaries, planned and reviewed implementation, designed the acceptance strategy, and owned final delivery.
Problem
The fragile version of this workflow treats tenant selection as a visual filter, lets an automation provider become the final decision-maker, and reports only happy-path activity. That makes cross-tenant mistakes, expired approvals, callback storms, and missing outcomes difficult to see and recover.
The product instead carries tenant context through request and persistence boundaries, records approval as a durable human decision, and turns exhausted background work into visible incidents. A separate public-demo target is prepared to show Dashboard, Leads, Automations, Approvals, Incidents, Reports, Clients, and Settings using synthetic data only. In that target, /approve/demo-token changes browser state, every /api/* route returns 404, the sign-in page returns to the demo workspace, and no worker or production provider is deployed.
What this case proves
- Product ownership can connect a business workflow to data, interface, reliability, and release boundaries.
- Multi-tenancy and approval are system properties, not labels added after implementation.
- A useful demo can be designed with no production data or external side effects.
Constraints
Constraints that shape the system
- Tenant isolation must survive request handling, persistence, background work, and reporting—not only the visible workspace selector.
- Qualification and automation can recommend or continue work, but they must not overwrite consequential human approval.
- A public product demo must be useful without exposing customer data, provider credentials, or a live API surface.
Key decisions
Choices, alternatives, and trade-offs
Carry tenant context through the stack
- Context
- A UI-only tenant filter can still allow cross-tenant access in API, persistence, worker, or report paths.
- Choice
- Make tenant identity part of request handling and tenant-scoped data access, with RLS-oriented persistence boundaries.
- Alternatives
- Filter only in the interface; Use one database per demo tenant before the product model is stable
- Trade-off
- Every data path needs explicit scope, but isolation becomes an architectural invariant rather than a presentation convention.
Model approval as a durable record
- Context
- A boolean in workflow memory cannot explain who decided, whether a token expired, or whether a callback is allowed to continue.
- Choice
- Use explicit approval records, one-time tokens, immutable decision history, and callback gates.
- Alternatives
- Pause only inside n8n; Treat an email click as sufficient without recording the decision boundary
- Trade-off
- The workflow contains more states, but human authority remains inspectable and testable.
Architecture and failure behavior
Responsibility, input, output, and failure
- 01
Lead intake
Accept signed, idempotent lead events into a tenant context.
- Input
- Lead source event
- Output
- Tenant-scoped lead and ingestion record
- Failure
- Invalid signatures, replay, or conflicts fail before qualification.
- 02
Qualification
Normalize scoring while keeping providers replaceable and advisory.
- Input
- Lead facts and provider configuration
- Output
- Normalized recommendation
- Failure
- Provider failure is visible and never becomes a confirmed decision.
- 03
Human approval
Persist the consequential decision before workflow continuation.
- Input
- Recommendation and one-time approval token
- Output
- Immutable decision record
- Failure
- Expired or reused tokens cannot silently continue automation.
- 04
Workflow operations
Run callbacks and durable jobs with retries and incident creation.
- Input
- Approved work and outbox jobs
- Output
- Delivery, callback, and incident state
- Failure
- Exhausted work becomes an incident instead of disappearing.
- 05
Reporting
Present outcomes and health inside the same tenant boundary.
- Input
- Product and operational records
- Output
- Auditable reports and attention queues
- Failure
- Missing outcomes stay visible as incomplete rather than inferred success.
Failure modes
How failure is detected, bounded, and escalated
| Trigger | Detection and response | Side effects and human boundary | Assurance |
|---|---|---|---|
| A signed intake event is replayed. | Signature, replay, and idempotency checks identify the duplicate. Return the existing result or reject a conflicting payload. | Qualification and workflow work are not duplicated. Conflicts become an operational review item. | Verified |
| An approval token is expired, reused, or opposed by an earlier decision. | Token and immutable decision-state checks reject the transition. Keep the recorded decision and stop the callback. | Automation cannot override the human record. An authorized operator must create a new review path. | Verified |
| A provider or callback remains unavailable after bounded retries. | Durable job attempts reach the configured limit. Create an incident with structured failure context. | Outbox identity and attempt records limit duplicate delivery. Operations can inspect, pause, or retry from the incident workflow. | Verified |
| A public-demo visitor attempts an API request. | The demo middleware matches every /api/* route. Return 404 at the boundary. | No worker, database, email, AI, n8n, or telemetry service is deployed. None; the visitor remains on the synthetic product surface. | Designed |
Project evidence
Evidence and its verification scope
Architecture
LeadOps carries tenant context through request handling and persistence rather than treating tenancy as a UI-only filter.
Portfolio implementation with synthetic data.LeadOps README — system highlightsApproval records and tokens gate automation callbacks so workflows cannot silently bypass human decisions.
Portfolio implementation and acceptance strategy.LeadOps README — system highlightsVerification
The repository documents local verification for the product, persistence, workflow, and operational boundaries.
Local verification; not evidence of live production traffic.LeadOps README — local verificationSecurity
The repository separates portfolio source terms from third-party package licenses.
Repository-level licensing disclosure.LeadOps README — source termsHonest status
Implemented, not claimed, and still required
- Running status
- Portfolio snapshot
- Data
- All screenshots and the prepared demo target use deterministic synthetic data.
- External integrations
- The repository defines provider and workflow boundaries; the public demo target disables APIs and does not deploy the worker.
- Revenue claim
- No production customer traffic or customer revenue is claimed.
- Source
- Public source
- Before production
- A verified public URL, independent security/compliance review, provider configuration, and operational ownership remain required.
Portfolio snapshot: The included data is synthetic. The repository does not claim a live production deployment, real customer traffic, or customer revenue.
Reflection and next priorities
What worked
Treating approval and incident handling as product surfaces made reliability legible to both operators and reviewers.
What I would change
I would define the public-demo isolation target earlier so every feature is designed with a safe evidence mode from the start.
Next priorities
- Deploy the web-only target and complete the anonymous API-off smoke test.
- Add an independently reviewed tenant-isolation threat model.
- Validate one real provider integration in staging before broader automation.
Not worth doing yet: A large integration marketplace is not worth building before one agency workflow proves the operating and support model.