PRODUCT LEADERSHIP / COMMERCIAL RESPONSIBILITY

Product judgment.
Technical depth.

I lead product and technology work where orders, revenue, and day-to-day operations meet. My experience spans P&L oversight, budgeting, systems integration, and hands-on delivery.

SELECTED WORK

01Restaurant delivery & operations

Turning delivery demand
into restaurant revenue.

Delivery integration & operating model

Delivery integration associated with a 25% net-sales increase and online ordering errors below 0.5%, as reported in my CV.

Delivery channels · Enterprise POS · Store operations

Marketing & technology leadership · P&L oversight

Implemented in professional practice

Explore the case

Problem: Delivery demand crosses transaction systems, store teams, customer service and finance. Growth depends on those handoffs working together.
Decision: Lead delivery integration alongside marketing, technology and chain-level P&L oversight, connecting acquisition, transactions, store execution and financial follow-up.
Tradeoff: Delivery success requires operational ownership and reconciliation as well as a working technical connection.

Illustrative operating model linking delivery channels to transaction records and restaurant execution, with customer service and finance handling exceptions and feeding operational review. — ILLUSTRATIVE ARCHITECTURE
How it’s built
An integration landscape connecting commercial demand with the systems and teams responsible for fulfilling it.
TransactionsEnterprise POS
Connect delivery orders to restaurant transaction records.
ExecutionStore operations
Coordinate preparation, customer follow-up and exception ownership.
Financial controlReconciliation
Follow the order through closing and financial review.

Explore the implementationDomain rules, recovery and acceptance

Architecture

Connect commercial ownership to operating responsibility.

Delivery integration sits within a wider responsibility for marketing, technology and chain-level P&L. The meaningful boundary is the complete transaction and its operational consequences.

Commercial decisions: Acquisition and channel growth remain connected to the restaurant’s ability to fulfil demand.
Cross-functional delivery: Operations, finance, accounting, supply chain and technology share consequential handoffs.

Failure & recovery

Transaction exceptions.

Rejected orders, failed closes, reopened or voided transactions, tender configuration and offline states require a traceable financial record and an identifiable team to resolve the exception.

Verification

Source of reported outcomes.

The figures come from my CV. Internal reporting, baselines and reporting periods are not reproduced here.

02Franchise menu publishing

From static artwork
to franchise menu automation.

Franchise menu publishing system

Saves days of repetitive menu preparation while handling different price points, product availability and screen layouts.

Google Sheets · Apps Script · HTML/CSS/JavaScript

Workflow design · Technical implementation

Implemented · Agentic publishing extension in development

Explore the case

Problem: Each price level and availability combination creates another menu variant. Editing and exporting artwork for every screen turns commercial updates into days of production.
Decision: Rebuild Illustrator designs as reusable HTML templates. Use spreadsheet-managed prices and availability to generate screen-specific publishing packages through Apps Script.
Tradeoff: Embed generated data in each package to match the signage player’s runtime constraints. Publishing still requires the package to reach its target screens.

ILLUSTRATIVE RECONSTRUCTION · SAMPLE DATA

How it’s built

Brand presentation stays in reusable templates; structured data controls commercial variants.

Source dataGoogle Sheets: Manage menu items, prices, images and availability flags.
GenerationGoogle Apps Script: Select screen variants and generate embedded JavaScript data.
PlaybackHTML/CSS/JavaScript: Package templates and assets for the existing signage system.

Explore the implementationDomain rules, recovery and acceptance

Architecture

Separate design from commercial variation.

Illustrator artwork was reconstructed in HTML/CSS/JavaScript. Apps Script reads structured sheets, applies screen and availability settings, and writes generated menu data into template packages.

Controlled variants: Price-level sheets, screen-specific exports and availability flags determine the generated menu.
Reusable presentation: Custom typography, imagery, subitems and upsells remain part of the screen template.

Failure & recovery

Build for the actual player.

Data fetching failed in the signage environment. Embedding the generated JavaScript data made playback compatible with its existing web-content package mechanism.

Verification

Keep each generated variant inspectable.

Generated JavaScript and dated exports make the selected prices and availability visible before the screen package is published.

03Restaurant commerce platform

One commerce system
across ordering channels.

Multi-tenant restaurant commerce platform

Shared customer, staff and kiosk ordering, backed by an owned order domain and independently configured transaction, payment and delivery integrations.

Next.js · Electron · NestJS · PostgreSQL

Product ownership · Architecture & integration delivery

Implemented · Provider and hardware acceptance remain scoped

Explore the case

Problem: Customers, staff and kiosks need consistent ordering despite location prices, nested meal choices, payment devices and different transaction systems.
Decision: Own the order domain and share the web renderer. Configure transaction backends, payments and delivery independently, with inventory, purchasing and labor capabilities around the same restaurant operation.
Tradeoff: Reusable channels and provider choice require explicit domain contracts and separate integration acceptance.

Explore the implementationDomain rules, recovery and acceptance

Architecture

Own the domain; configure the integration boundaries.

A typed order interface supports native and enterprise transaction backends. Payment routing and delivery quoting have separate tenant configuration. Runtime location settings avoid a separate tenant build.

Menu and price semantics: Nested combos, submodifiers, location prices, discounts and server-side tax calculations use explicit representations and minor currency units.
Operational breadth: Ingredient inventory, purchasing, transfers and labor services extend the product beyond the checkout surface.

Failure & recovery

Treat device, transaction, and provider failures separately.

A local queue alone is not an exactly-once guarantee. Transaction and payment integrations retain their own reconciliation.

Persistent device work: Unsent payloads survive in a local queue and are marked synced only after the submit function reports success.
Bounded provider selection: Parallel delivery quotes are scored by configured fee and ETA weights; failed or timed-out responses are excluded.

Verification

Check the domain contract as well as the adapter.

The native-backend suite covers subtotal/tax calculation and modifier effects. Other source tests target admin permissions, payment-provider routing, menu sync, delivery selection and order behavior.

Normalized values: The shared contract expresses subtotal, tax, and total in minor currency units.

04Event business platform

The infrastructure
behind an event business.

Event commerce, operations & audience platform

Connects scarce ticket and seat inventory, sales, event-day access and the customer lifecycle in an organization-to-attendee model.

Next.js · Supabase · PostgreSQL · IndexedDB

Product ownership · Architecture & technical delivery

Implemented platform · Lifecycle automation is staged; wider release remains scoped

Explore the case

Problem: An event business must sell limited inventory, coordinate teams, admit customers and maintain relationships across recurring events.
Decision: Connect commerce, operations and audience management through one organization → event → attendee model, with guided decisions and direct controls for experienced organizers.
Tradeoff: Inventory, money, permissions and communications need distinct rules. Delivery proceeds in verifiable stages, including prepared offline admission and controlled lifecycle automation.

ILLUSTRATIVE ARCHITECTURE

How it’s built

One event model connects the commercial lifecycle; transactional records and scoped authority protect consequential actions.

ExperienceNext.js: Guide organizers through setup, growth, event day, retention and analysis.
Commerce & authoritySupabase / PostgreSQL: Coordinate inventory, seat holds, checkout, refunds and scoped team access.
Event-day continuityIndexedDB + signed passes: Prepare local admission evidence and reconcile it after reconnecting.

Explore the implementationDomain rules, recovery and acceptance

Architecture

Model the business across its lifecycle.

The product covers recurring occurrences, seating, ticket releases, checkout, refunds, team permissions, support and audience management. The organizer’s next consequential decision connects these capabilities.

Journeys: Versioned graphs express waits, branches, approvals, activation timing and completion. Native effect delivery has staged acceptance.
Transactional boundaries: Replay-safe commands, seat holds and scoped authority address inventory and operational contention.

Failure & recovery

Preserve authority when connectivity changes.

Prepared admission uses signed passes, encrypted IndexedDB packs and bounded device authority. Device evidence is retained and later settled against server state; disconnected scanners can still encounter cross-device conflicts.

Recovery: Retries retain command identity; late responses must not silently apply to a newer session or scope.

Verification

Accept consequential paths separately.

Commerce, access, communications and journey effects have distinct acceptance. Source implementation is not a claim that every automation or wider release is active.

Further product work3 additional cases

05Campaign production & learning

Learn which campaigns
generate qualified enquiries.

Campaign production & experimentation workbench

Connects seller knowledge, reviewed campaign publishing and controlled measurement to reproducible learning.

WordPress/PHP · Workers · PostgreSQL · Python

Product strategy · Marketing & technical delivery

In development · Public collection and activation are disabled

Explore the case

Problem: Producing campaign material and collecting leads is not enough to explain which message generates qualified demand.
Decision: Connect seller discovery to versioned content, reviewed publishing, assignment, exposure, enquiry and qualification records, then analyze complete observation windows against a frozen plan.
Tradeoff: Keep experimentation in the first version and reuse existing publishing infrastructure. Defer autonomous sales assistance while the measurement loop is established.

ILLUSTRATIVE ARCHITECTURE

How it’s built

A traceable evidence chain connects what was published, who encountered it and which enquiries qualified.

PublishingWordPress / PHP: Use the existing CMS with reviewable, versioned campaign material.
MeasurementWorkers + PostgreSQL: Keep assignment, exposure and qualification histories distinct.
LearningPython: Analyze saved snapshots against a predefined statistical plan.

Explore the implementationDomain rules, recovery and acceptance

Architecture

Keep production and learning connected.

Python release tools and PHP templates work with an existing CMS. Edge services and PostgreSQL retain measurement contracts; the management interface exposes protected seller records.

Scope judgment: Recurring seller discovery informs production without becoming a prerequisite for every increment.
Experiment design: A frozen external plan, immutable snapshots and defined readiness precede final comparisons.

Failure & recovery

Uncertainty must remain visible.

An uncertain enquiry submission can retain its original in-memory retry identity until its outcome is known.

Submission: Contact details and tokens stay out of URLs and analytics.
Outcome history: Append corrections against the mistaken root while preserving genuine earlier events.

Verification

Verify the pipeline, not a preferred answer.

The repository includes PostgreSQL authorization/concurrency tests, synthetic browser/edge journeys, and numerical fixtures. The comparison implementation fixes methods in advance, including Newcombe/Wilson intervals and a score-versus-Fisher sparse-data rule; it does not choose a method because it produces a favorable result.

Integrity: Cross-check evaluated units against aggregates and bind reports to snapshot, specification, code, and cutoff.
Interpretation: Distinguish descriptive progress, incomplete readiness, measurement issues, and analyzable comparisons.

06Adaptive wellbeing

Useful guidance
for an interrupted day.

Local-first adaptive wellbeing app

Turns a brief check-in and the time actually available into a bounded activity the user can accept, change or decline.

Expo / React Native · TypeScript · SQLite

Product direction · Experience & technical delivery

In development · Device validation is scoped; public release is separate

Explore the case

Problem: A useful routine has to fit changing time, intention and context, and survive interruption without rewriting what the user actually did.
Decision: Select eligible activities from a versioned catalog, let the user confirm, and keep selection, execution, recovery and local history consistent.
Tradeoff: Breathing, grounding, quiet pauses, walking and outdoor breaks have different suitability and execution rules. Catalog breadth advances through scoped implementation and device validation.

Explore the implementationDomain rules, recovery and acceptance

Architecture

Give selection and execution a shared contract.

Eligibility is evaluated before preference. Explicit requests, available duration and supported activity protocols constrain proposals. The accepted activity and protocol version remain pinned.

User authority: A proposal can be accepted, changed or declined. Completion and helpfulness remain separate observations.
Catalog breadth: Five activity families have implemented content; the wider approved catalog is being developed in stages.

Failure & recovery

Restore the actual attempt, not a newly generated one.

Recovery serializes storage work, rejects stale saves that would replace newer or terminal work, and preserves unsupported data. If exact content is unavailable or current eligibility changes, progress is retained without inventing a Stop or a Completed event.

Interruption: Background time and no-timer informational states follow their declared protocol; they are not interchangeable.
Data preservation: Unknown historical facts stay unknown; later feedback edits keep their observation identity and revision.

Verification

Verify transitions and preservation independently.

Focused activity/device checkpoints sit alongside automated domain, storage, compatibility and recovery checks.

Control: Accept/Start separation, direct Stop, explicit ending, and guarded final completion.
Durability: Stale save rejection, terminal record protection, exact historical rows, and content/version compatibility.

07Structured knowledge explorer

Explore complex knowledge.
Keep its source intact.

Structured knowledge reader & graph explorer

Turns hierarchical source material into a searchable catalog with library, outline, 2D and 3D views of the same records.

Python · React / TypeScript · Canvas · Vite

Product design · Data modeling & implementation

Local prototype · Deployment remains pending

Explore the case

Problem: Repeated names, nested notes and cross-references make rich source material difficult to explore without losing its original meaning.
Decision: Build a tested importer and one authoritative catalog. Share records and navigation across reading, filters, comparison, contextual references and four visual views.
Tradeoff: Preserve distinct identities and unresolved references. Use a static application and custom Canvas projection, with a readable alternative to spatial navigation.

ILLUSTRATIVE ARCHITECTURE

How it’s built

The importer establishes meaning once; every reader and graph view works from the same catalog.

ImportPython: Parse hierarchy, preserve identities and resolve source references.
ReaderReact + TypeScript: Share search, facets, comparison and URL state across views.
Spatial viewCanvas + static Vite app: Project 3D coordinates with custom camera and depth ordering.

Explore the implementationDomain rules, recovery and acceptance

Architecture

Make source interpretation explicit.

A Python importer and owner-defined rules produce the catalog and filter projections. References are resolved before browser filtering or reordering. Unknown targets remain visible rather than becoming fabricated links.

Spatial implementation: Canvas 2D draws projected 3D coordinates with perspective, yaw/pitch, depth ordering and a deterministic layout.
Small operating footprint: The intended deployment is a static reader without an application server, database or runtime AI dependency.

Failure & recovery

Filtering must not change a source reference.

A selected record remains readable when a later filter excludes it. Source-order navigation and resolved context targets do not become relative to the filtered list. Traversal is bounded and cycle-guarded; ambiguous links stay unresolved instead of becoming an invented lesson.

Navigation: URL state carries selection, filters, view, comparison, and grouping with recoverable warnings for unsupported values.
Graph meaning: Membership, context, and unambiguous mentions are typed edges—not inferred similarity, mastery, or prerequisites.

Verification

Test data meaning before visual polish.

Source fidelity: Preserve all source records, unknown fields, exact reference targets, and owner-authorized normalization.
Interaction: Verify selection outside filters, query-aware counts, comparison, graph focus, and stable URL restoration.

Client and product identities are withheld.

HOW I WORK

How I drive product and delivery

I connect customer needs, commercial objectives and operational constraints. Discovery, positioning, acquisition and retention inform the product together; working assumptions remain visible and are revised through use and experiments.

I turn direction into explicit behavior: what counts as a paid order, when a campaign result can support a conclusion, and what a user has actually completed. Those definitions shape the experience, data model and integration boundaries.

I use AI-assisted research, prototyping and development with technical review and testable acceptance criteria. I retain ownership of priorities, scope, tradeoffs and release decisions while implementation moves through small, reviewable increments.

Existing infrastructure, operating costs and verification effort are part of the decision. Checks scale with risk, validated work is reused, and new evidence can change the plan.

EXPERIENCE & RESPONSIBILITY

13+ years across restaurant operations, healthcare, and advertising technology. My restaurant leadership role combines national marketing and technology with chain-level P&L oversight, working across operations, finance, accounting, and supply chain.

Earlier product and commercial roles included budgeting, technology acquisition and development, and sales/account teams responsible for more than US$4M in annual revenue.

Let’s talk

Let’s figure out
what needs to work better.

For product leadership and technical delivery roles with commercial responsibility.

josezam.dr@gmail.com

Product judgment.Technical depth.

SELECTED WORK

Turning delivery demand into restaurant revenue.

How it’s built

Connect commercial ownership to operating responsibility.

Transaction exceptions.

Source of reported outcomes.

From static artwork to franchise menu automation.

How it’s built

Separate design from commercial variation.

Build for the actual player.

Keep each generated variant inspectable.

One commerce system across ordering channels.

How it’s built

Own the domain; configure the integration boundaries.

Treat device, transaction, and provider failures separately.

Check the domain contract as well as the adapter.

The infrastructure behind an event business.

How it’s built

Model the business across its lifecycle.

Preserve authority when connectivity changes.

Accept consequential paths separately.

Learn which campaigns generate qualified enquiries.

How it’s built

Keep production and learning connected.

Uncertainty must remain visible.

Verify the pipeline, not a preferred answer.

Useful guidance for an interrupted day.

How it’s built

Give selection and execution a shared contract.

Restore the actual attempt, not a newly generated one.

Verify transitions and preservation independently.

Explore complex knowledge. Keep its source intact.

How it’s built

Make source interpretation explicit.

Filtering must not change a source reference.

Test data meaning before visual polish.

How I drive product and delivery

Let’s figure out what needs to work better.

Product judgment.
Technical depth.

Turning delivery demand
into restaurant revenue.

From static artwork
to franchise menu automation.

One commerce system
across ordering channels.

The infrastructure
behind an event business.

Learn which campaigns
generate qualified enquiries.

Useful guidance
for an interrupted day.

Explore complex knowledge.
Keep its source intact.

Let’s figure out
what needs to work better.