BarkBowl Should Be a Time-Commerce Dogfooding Product

Full report

On this page

After reviewing the project documents, the corrected reading is clear: BarkBowl is not a generic premium dog-food storefront with a novelty twist. The BarkBowl architecture memo frames the project as a time-based satirical commerce system whose central joke and mechanism is that engineers “burn time instead of spending money,” and it explicitly rejects “WooCommerce with the paint changed” as the honest solution. The dogfooding memo then raises the bar further: the site is supposed to behave like a real internal product program, with instrumentation, staged rollout, feedback loops, and measurable exit criteria. The enterprise architecture memo adds a final constraint: keep the frontend modular, typed, predictable, and operationally disciplined, but do not confuse that discipline with a requirement to ship Angular. I was not able to reliably fetch the live domain during research, so the “current-site audit” below is a concept-and-architecture audit grounded in the documents and platform evidence rather than a page-by-page crawl of the deployed HTML.

The premise the documents actually define

The point of BarkBowl, as your documents define it, is to turn software-team dogfooding into a satirical commerce system: the catalog is the narrative surface, but the real product is the time-priced cart, the session rules, the checkout semantics, and the internal observability around how people use it. In that framing, the dog-food branding is the wrapper; the actual premise is an internal product that dramatizes work consumption, measures usage, and creates a deliberately opinionated “Customer Zero” environment inside WordPress.

That changes what “good” looks like. A normal DTC pet-food site is primarily trying to maximize trust, appetite, quiz completion, box conversion, subscription retention, and operational fulfillment. BarkBowl should certainly borrow polished storytelling patterns from premium pet-food sites, but its core success criteria are different: users must understand that time is the price, the cart must feel intentionally temporal rather than monetary, checkout must create time-consumption records rather than conventional paid orders, and the whole system must be instrumented like an internal product undergoing structured dogfooding.

The enterprise-architecture memo matters here because it prevents another kind of drift. Its lesson is not “use Angular no matter what”; its lesson is to borrow enterprise frontend discipline: explicit boundaries, typed domain models, predictable state flow, clear API edges, observability, and lifecycle-safe UI code. In a WordPress theme/plugin build, that means enterprise-quality TypeScript modules embedded in the WordPress solution, not an unnecessary Angular runtime.

Where the work drifted off premise

The drift happened when the site was interpreted as a standard DTC dog-food brand first and only secondarily as a satire. That inversion is what flattened the concept. Once the primary lens becomes “premium pet-food e-commerce,” everything starts bending toward ordinary commerce conventions: money prices, standard catalog cards, generic dog-parent reassurance copy, normal conversion funnels, and analytics centered only on storefront performance. Your BarkBowl memo points in the opposite direction: the satire is not cosmetic; it is the architecture.

The cleanest way to see the miss is to compare the semantic models:

That table is a synthesis of the BarkBowl and dogfooding documents.

WooCommerce’s own documentation makes the mismatch even more concrete. Woo’s payment-gateway model is explicitly about payment methods, payment processing, order status changes, redirects to return URLs, and billing and shipping addresses; its Store API creates a checkout draft from the current cart and then processes payment and order data; and its core price-formatting function is built around currency symbols, decimal separators, thousands separators, and formatted monetary output. Those are not incidental implementation details. They show that WooCommerce’s worldview is standard paid commerce, which is exactly why your architecture doc says it is the wrong semantic center for a site where engineers spend time rather than money.

That does not mean BarkBowl should ignore all DTC best practices. It means those practices should be subordinate to the time-commerce joke. Ingredient storytelling, feeding guidance, appetizing product presentation, and clear product differentiation are still useful. But if those are allowed to overwrite the time-priced premise, the site ceases to be BarkBowl and becomes just another polished dog-food mock brand.

The benchmark lens that fits BarkBowl

The documents imply that BarkBowl needs a split benchmark, not a single benchmark set. The surface layer should benchmark against premium dog-food merchandising and editorial UX: strong visual hierarchy, ingredient provenance storytelling, believable nutritional framing, a discovery flow, rich product detail pages, and a brand voice that feels intentionally overcommitted. The mechanical layer should benchmark against enterprise commerce and internal-product operations: stateful carts, persistent sessions, robust API contracts, feature-flagged rollout, observability, and failure-safe release controls.

That split matters because WordPress itself also separates these concerns. The WordPress Theme Handbook says themes control the presentation of content, while plugins control a site’s behaviors and features, and it explicitly warns against putting site-critical functionality in a theme because that functionality is lost when the theme changes. WordPress’s Plugin Handbook likewise positions plugins as the right place for custom post types, taxonomies, metadata, settings, privacy handling, JavaScript behavior, and other reusable feature logic. BarkBowl maps unusually well onto that guidance: the theme should perform the satire and brand experience; the plugin should perform the time-commerce mechanics.

The dogfooding memo also changes the benchmark for “launch readiness.” The right comparison is not “Would a DTC creative director like this homepage?” but “Is this instrumented enough, release-controlled enough, and governable enough to act like a real internal product?” That is why feature flags, rollbacks, telemetry, and internal feedback loops belong in the benchmark set alongside copy, layout, and merchandising. PostHog’s feature-flag documentation, for example, stresses phased rollouts, percentage rollouts, kill switches, targeting, experimentation, and early-access management—exactly the kind of controls that make a dogfooding program operational rather than theatrical.

The WordPress architecture that matches the joke and the job

The WordPress split should be strict. The theme should own the branded editorial surface: homepage, landing pages, narrative copy, ingredient pages, feeding guide, about/contact pages, blog, product display templates, satirical UI voice, and any highly presentational blocks or patterns. The plugin should own everything that would still need to exist if the theme changed tomorrow: the product model, taxonomies, metadata, cart, cart TTL, checkout record creation, session behavior, REST routes, admin screens, role/capability checks, seeders, and telemetry hooks. That is exactly how WordPress advises developers to separate presentation from site-critical functionality.

A faithful BarkBowl plugin should therefore register the product catalog as a custom post type and the classification layer as custom taxonomies, because WordPress explicitly recommends putting custom post types in a plugin so content remains portable if the theme changes. WordPress also points to custom taxonomies as the way to create distinct organizing systems and domain-specific admin interfaces. For BarkBowl, that means the product model belongs in the plugin even if the theme is doing almost all of the front-end storytelling.

The API boundary should also live in the plugin. WordPress’s REST API guidance recommends registering custom routes on rest_api_init, using register_rest_route, and explicitly supplying permission_callback methods. WordPress’s nonce guidance is equally clear that nonces help defend against CSRF but should not be treated as authorization; capability checks still need to be enforced. In practice, that means BarkBowl’s write endpoints should use a combination of nonce protection, capability or session checks, strict validation, and explicit controller methods for get/create/update/delete actions.

For the cart itself, WordPress transients are a reasonable fit for expiring server-side cart state because the Transients API is designed to store data temporarily with an expiration time. But WordPress also warns that transient expiration is a maximum, not a guaranteed minimum, and that transients can disappear before expiration. So if the BarkBowl cart uses transients for cart snapshots or session records, the plugin must treat cache misses as normal recovery scenarios and regenerate state safely rather than assuming the session store is always present.

For the client session identifier, the strongest fit is a narrow-scope cookie rather than fragile browser storage. MDN documents HttpOnly, Secure, and SameSite attributes on Set-Cookie; OWASP recommends that session cookies explicitly set Secure, HttpOnly, and SameSite=Strict or Lax, and it recommends host-only cookie scoping where possible. For BarkBowl on a same-origin WordPress install, a host-only cookie such as __Host-barkbowl-session with Secure; HttpOnly; SameSite=Lax; Path=/ is the cleanest default. If the UI ever moves to a different origin, MDN also notes that CORS requests ignore Set-Cookie unless credentials are included, which would require a deliberate cross-origin cookie strategy rather than an accidental one.

The data model the plugin should own

The BarkBowl memo does not hand you a full entity diagram, but it strongly implies one. The most faithful implementation is not a Woo-style order model with symbolic labels layered on top; it is a purpose-built time-commerce data model that happens to dress itself like pet-food merchandising. This is an inference from the BarkBowl document, supported by WordPress’s recommendation to implement domain-specific content types and taxonomies in plugins.

A minimum viable plugin-owned schema should look like this:

That schema is the one that preserves the premise instead of collapsing it into normal e-commerce.

Just as important, the seeded catalog should not be treated as placeholder content. In this project, seed data is part of the concept. The products need to carry both believable dog-food metadata and satirical time metadata so the catalog can exercise the plugin’s real mechanics during dogfooding. If seeded products are too generic, the team can test pages but cannot really test premise comprehension, time accumulation, TTL behavior, or cart narrative coherence. That is exactly the kind of false confidence the dogfooding memo warns against.

This is also where the line between “brochure” and “product” becomes concrete. A brochure can get away with fake catalog cards. A dogfooding system cannot. The seeded BarkBowl catalog should be rich enough that the team can actually use it repeatedly, compare cohorts, observe failure modes, and retire or revise products based on measured interaction rather than taste alone.

The frontend standard without Angular

Your enterprise architecture document should be read as a discipline document, not a framework mandate. Its useful lessons are modularity, typed contracts, clear layering, reactive state boundaries, lifecycle safety, and operational instrumentation. In a WordPress build, that translates into a TypeScript frontend organized by domain, not by a pile of jQuery snippets or page-local inline scripts. The right shape is something like domain/, api/, state/, ui/, and telemetry/, with small feature modules for catalog, cart, checkout, and analytics.

For BarkBowl, that means browser code such as: typed DTOs for products and cart state; a thin API client around the plugin routes; a cart store with explicit events and derived state; abortable requests for cart mutations; a central error-normalization layer; and view adapters that bind DOM nodes to store updates without smearing business rules across templates. The point is not to mimic Angular syntax in WordPress; the point is to preserve enterprise-grade boundary discipline inside a much lighter runtime.

The same memo’s lifecycle mindset matters too. One of the common failure patterns in ad hoc WordPress front ends is that event handlers, timers, retries, and fetches pile up without consistent cleanup or ownership. The corrected BarkBowl frontend should instead have a predictable event model: user interaction emits domain events, stores update deterministically, UI bindings rerender targeted regions, telemetry records success or failure, and failure states are visible rather than swallowed. That is the “borrow the discipline, not Angular itself” reading of your document.

Instrumentation belongs in that frontend layer from the start. OpenTelemetry’s browser guidance shows that JavaScript browser apps can emit traces and can be set up in TypeScript, while its observability primer defines proper instrumentation as emitting traces, metrics, and logs so developers do not have to keep patching in extra instrumentation after the fact. BarkBowl does not need maximal tracing everywhere, but it absolutely needs structured frontend telemetry around catalog loads, add-to-cart, cart refresh, TTL expiry, checkout attempts, and UI exceptions.

Performance telemetry matters as well because this site’s satire still has to feel premium. Google’s Web Vitals guidance defines LCP, INP, and CLS as critical user-experience metrics and explicitly recommends that sites run their own real-user monitoring because aggregate public data does not provide pageview-level diagnostic detail. For BarkBowl, that means the theme/plugin bundle should capture field performance for the 75th percentile, especially on key routes like homepage, product listing, product detail, and cart.

The rollout and observability model the site actually needs

The dogfooding memo is the document that most decisively rules out a generic storefront audit. It frames dogfooding as a structured internal product operation with staged rollout, representative cohorts, instrumentation before launch, issue ownership, and measurable exit criteria. In other words, BarkBowl should be deployed more like a serious internal beta than like a funny branded microsite.

That means the release plan should be ring-based. Start with a very small internal cohort, then widen exposure only if feature-flagged metrics are healthy. Feature flags are valuable here not because BarkBowl is large, but because the premise itself is unusual: you want the ability to turn the time-cart on for a subset of users, compare satirical variants, isolate seed-catalog experiments, and kill broken flows immediately. PostHog’s documentation is directly relevant: it highlights phased rollouts, percentage rollouts, kill switches, targeting, A/B testing, and early-access management as core feature-flag use cases.

The measurement stack should also be different from a normal DTC site. In addition to storefront basics, BarkBowl needs product-program metrics that reflect the time-commerce premise:

This metric model is a synthesis of your dogfooding memo, OpenTelemetry’s traces/metrics/logs framing, PostHog’s feature-flag-and-experiment tooling, and Google’s Web Vitals guidance.

The most important implication is cultural, not technical. BarkBowl should be run as an internal product with owners, dashboards, rollout gates, and closeout criteria. If the team treats it like a brochure with a clever cart, it will drift back into generic DTC every time a design decision becomes ambiguous. If the team treats it like a dogfooded product whose satire is implemented in the cart model, the session model, and the telemetry model, the concept holds.

In that sense, the corrected north star is simple: BarkBowl should look like a premium dog-food brand, but behave like a custom internal time-commerce system under disciplined dogfooding. The theme sells the fiction; the plugin enforces the premise; the telemetry proves whether the satire is actually working.