Skip to content
Tenten

Shopify Partner / Commerce delivery

Build the operating rules before the Shopify theme.

Tenten is a Shopify Partner. We turn catalog, market, checkout, app, integration, measurement, and operations decisions into a reviewable build scope.

Contact usReview the operating system
Conceptual commerce workspace with unbranded products and a mobile storefront

INPUTCatalog + markets

DECISIONSCheckout + systems

RECEIPTSRelease + handoff

Concept image. The records below define scope; the portfolio shows inspectable work.

Commerce operating system

Seven records keep the build reviewable.

Each record turns an open commerce question into a decision rule, a review artifact, and a named owner. None is complete because a page section exists.

  1. 01

    Model

    Catalog + content model

    What is a product, a variant, a collection, and reusable product content?

    • Use a variant only when an option changes the sellable item or its operational data.
    • Store reusable editorial facts once, then reference them instead of copying them across products.
    Review artifact
    Field map, sample product, and migration transform
    Ownership
    Tenten drafts; merchant approves product semantics

  2. 02

    Markets

    Market + localization matrix

    Which commercial rule changes by country, region, language, or currency?

    • Create a market rule when price, tax, payment, delivery, availability, or legal copy changes.
    • A translation alone does not create a second product record unless operations require one.
    Review artifact
    Market matrix with URLs, currency, language, availability, and owner
    Ownership
    Merchant owns commercial policy; Tenten maps it to the storefront

  3. 03

    Checkout

    Checkout + app decision log

    Can the requirement stay native, or does it justify another dependency?

    • Start with Shopify and theme capabilities; add an app only against a named requirement.
    • Verify current plan eligibility before promising a checkout change, then record cost, data access, and an exit path.
    Review artifact
    Decision log with requirement, chosen path, trade-off, approver, and review date
    Ownership
    Tenten recommends; merchant approves recurring cost and vendor dependency

  4. 04

    Systems

    Integration inventory

    Which system writes each field, and what happens when an exchange fails?

    • Name one source of truth per field and document direction, trigger, identifier, retry, and exception handling.
    • Do not let two systems write the same value without a conflict rule and a human owner.
    Review artifact
    System inventory and sample payload or file for every integration in scope
    Ownership
    Each system has a business owner and a technical escalation owner

  5. 05

    Measurement

    Analytics event contract

    What user action creates each event, and how will the team prove it arrived?

    • Define the trigger, required commerce fields, consent condition, destination, and test method before tagging.
    • Accept purchase only when the test order carries a unique transaction ID and does not duplicate on reload.
    Review artifact
    Event map plus browser, analytics, and order read-back for the approved test path
    Ownership
    Growth owns meaning; Tenten owns implementation in scope

  6. 06

    Release

    Launch reconciliation

    What changed between the approved baseline and the release candidate?

    • Compare catalog, market, redirect, checkout, integration, and event records at the release boundary.
    • Log every variance with a disposition and owner before the go-live decision.
    Review artifact
    Dated reconciliation sheet tied to the release candidate
    Ownership
    Tenten runs the review; merchant accepts commercial exceptions

  7. 07

    Operations

    Editor + operations handoff

    Can the people running the store complete routine work and recognize an exception?

    • Train against real tasks: edit a product, publish content, change availability, inspect an order, and find an event receipt.
    • Separate routine changes, approval-only changes, and issues that require escalation.
    Review artifact
    Recorded scenarios, role map, runbook, and open-issue register
    Ownership
    Merchant names operators; Tenten transfers the agreed workflow

Decision workbench

Rules before screens.

Catalog, market, and checkout choices are easy to hide inside a theme build. We put them in records the merchant can challenge and approve.

Record 01 / Catalog model

One field map, four different jobs.

The merchant approves the meaning before migration or entry begins.

Product

One merchandising identity and shared product story

Split only when buyers, operations, or reporting need a separate item.

Variant

A sellable option with its own SKU, price, inventory, weight, or fulfilment rule

Do not use variants as a content-layout shortcut.

Collection

A merchandising or navigation set

Record whether membership is manual, rule-based, or market-specific.

Reusable content

Ingredients, materials, care, size guidance, campaign modules, or other shared facts

Model once and reference it; name the editor responsible for updates.

Record 02 / Market matrix

Localization follows the commercial rule.

01

Price, currency, tax, or payment changes

Create an explicit commercial rule for that market.

Acceptance evidence

Approved price source, tax owner, payment provider, and checkout test.

02

Language changes but the offer does not

Localize the shared record and keep one product identity.

Acceptance evidence

Locale field map, fallback behavior, and editor assignment.

03

Availability or fulfilment changes

Define where the product can be seen, bought, and delivered.

Acceptance evidence

Market-product matrix and shipping scenario receipt.

Record 03 / Checkout and app log

Every dependency needs a reason and an exit.

Merchandising or content change

Theme or admin configuration

No app unless the requirement cannot be met cleanly in the owned build.

Checkout behavior change

Current Shopify capability first

Confirm plan eligibility and test boundary before scope approval.

Third-party app

Named requirement and owner

Record recurring cost, permissions, data path, support owner, and replacement path.

Custom service

Use only when business logic cannot live safely in the storefront

Document hosting, monitoring, failure behavior, and maintenance ownership.

Records 04 + 05

Name the source of truth. Then name the receipt.

An integration inventory prevents ownership from disappearing between vendors. An event contract prevents a tag firing from being mistaken for trustworthy measurement.

Integration inventory

One owner per exchange boundary

Product source

Failure owner: Merchandising operations

Owns
Product IDs, variants, approved copy, and media
Exchange
Approved publish or migration transform into Shopify

ERP / fulfilment

Failure owner: Operations plus integration owner

Owns
Inventory, order, shipment, and cancellation fields named in scope
Exchange
API, webhook, or batch with identifiers and retry rules

CRM / lifecycle messaging

Failure owner: Marketing operations

Owns
Consented customer and order signals approved for activation
Exchange
Event or batch, with field-level consent and deletion rules

Analytics

Failure owner: Growth owner plus implementation owner

Owns
Event meaning, commerce parameters, and destination mapping
Exchange
Browser or server path recorded per event

Analytics event contract

Trigger, fields, destination, proof

  1. 01

    view_item

    A product detail view resolves with the agreed stable product or variant ID.

    Receipt: Debug payload matches the visible item and market.

  2. 02

    add_to_cart

    The cart accepts the selected item and quantity.

    Receipt: Payload and cart state agree on item ID, quantity, price, and currency.

  3. 03

    begin_checkout

    The buyer leaves the cart for checkout, not when the cart merely opens.

    Receipt: One event for the tested transition with the agreed cart fields.

  4. 04

    purchase

    The approved order confirmation is available.

    Receipt: Unique transaction ID, value, currency, items, and a reload deduplication check.

  5. 05

    search

    The storefront returns results for a non-sensitive query.

    Receipt: Query and result state are readable without collecting personal data.

Records 06 + 07

Launch is a reconciliation. Handoff is a working session.

The release candidate is checked against the approved baseline. Operators then complete real store tasks and leave with a runbook and escalation path.

Launch reconciliation

Catalog

  • Product and variant counts
  • Collection membership
  • Media and reusable fields

Markets

  • Language and currency
  • Availability and delivery
  • Market URLs and fallbacks

Checkout

  • Payment test
  • Tax and shipping scenarios
  • Discount, refund, and cancellation path

Continuity

  • Redirect map
  • Metadata and indexability
  • Analytics event and test-order receipts

Integrations

  • Sent and received IDs
  • Exception log
  • Retry and escalation owner

Operations

  • Editor scenarios
  • Permissions
  • Runbook and open-issue register

Editor and operations handoff

The operator does the work

  1. 01

    Create or update a product with variants, media, reusable content, and search fields.

  2. 02

    Publish a collection or campaign change using the approved review path.

  3. 03

    Apply a market-specific availability or content change without altering another market.

  4. 04

    Find an order, identify its integration status, and follow the exception path.

  5. 05

    Run an analytics test and locate the event and order receipts.

  6. 06

    Revert or escalate a change using the runbook instead of relying on one developer's memory.

Inspectable commerce work

Read what was built, not an invented result.

These cases document commerce work that can be inspected. They are not used as proof of platform status or as a promise about commercial performance.

Wahuda Tools direct commerce storefront

Direct e-commerce store

Wahuda Tools

The case records product-detail work, accounting integration, automated tax calculation, and shipping rules.

Inspect the case →

Fit, trade-off, ownership

The platform decision is part of scope, not a foregone conclusion.

Good fit when

  • The catalog, variants, markets, and fulfilment rules can be made explicit.
  • The merchant team wants Shopify admin to be a primary operating surface.
  • App and integration dependencies can have named budgets, owners, and exit paths.
  • Checkout requirements can be accepted only after current capability and plan checks.

Trade-offs to accept

  • A specialized configurator, marketplace, or back-office workflow may need a separate service and maintenance boundary.
  • Every app adds recurring cost, permissions, data movement, vendor support, and upgrade work.
  • Each additional market multiplies policy decisions and release scenarios; localization is not only a copy task.
  • A migration needs explicit URL, content, event, and order checks; platform movement alone does not preserve them.

Ownership boundary

A clear build has no invisible owner

Tenten

Decision artifacts, implementation from the approved backlog, QA, launch reconciliation, and handoff

Presents evidence and records unresolved exceptions

Merchant team

Products, price, tax, shipping, legal policy, provider contracts, access, and day-to-day operation

Approves commercial rules, recurring costs, release exceptions, and go-live

Shopify and app vendors

Their platform, product behavior, service terms, and vendor support

External dependencies remain visible in the inventory and escalation plan

Start with the operating questions

Bring the catalog, market list, and current app stack.

We will identify the decisions, evidence, owners, and trade-offs needed for a reviewable Shopify scope.

Contact us