This page describes how DomiDo measures, traces, monitors, and learns from what its platform does in production. DomiDo is built by Avvyland Limited (UK) and sells universal blocks and fasteners only; every construction shown on the platform is a user-generated design. Observability is what makes the platform debuggable, learnable, and recoverable, and what lets a small team operate the public beta with confidence. The diagram below shows the full stack at a glance — data sources at the top, the telemetry pipeline that shapes the signal, the storage and analysis layer that retains it, and the consumption layer where engineers and operators actually use it — and the rest of the page walks through each pillar in turn, including AI cost monitoring (because generation calls are an unbounded cost), business analytics, inventory analytics, and marketplace metrics for the designer side of the platform.
The diagram shows the four layers of the observability stack: data sources (the platform components that emit signal), the telemetry pipeline that shapes that signal, the storage and analysis layer that retains it, and the consumption layer where engineers and operators actually use it. Each layer is loosely coupled — components emit telemetry without knowing where it lands, and sinks accept telemetry without knowing where it came from — and that decoupling is what allows the stack to evolve toward a managed alternative without rewriting the application instrumentation.
Observability spans four working pillars. Product analytics captures behavioural events that explain what users do, what they convert on, and where they drop. Backend observability covers structured logs, metrics, and traces that explain what the system is doing. Error tracking and alerting surfaces issues and routes them to the right person at the right time. Performance monitoring covers frontend web vitals, mobile responsiveness, backend latency, synthetic uptime, and load capacity. The page treats AI cost monitoring as a separate concern because generation costs scale differently from infrastructure costs, and it ends with the business, inventory, and marketplace analytics that turn the same instrumentation into business signal.
Product analytics centres on a single design-to-purchase funnel that the founder dashboard watches at every transition.
Conversion rates are tracked at each transition, and the bottleneck is taken to be the lowest conversion rate, so the weekly review focuses on that bottleneck before adding features. Around the funnel itself, engagement metrics cover time-on-site, depth-of-session, gallery scroll-depth, listing-detail dwell time, save-and-share rate, return-visit rate, and conversation participation in support and feedback, while generation metrics cover start-to-result time, success rate by mode and stage, retry rate, cancel rate, cost per generation, and provider-mix share. Product analytics runs on a single provider with a European-Union data-residency option, feature flags, session recording, and funnel analysis; a backend-owned event dictionary defines the canonical event names and properties served at GET /api/config/product-events; events are dispatched server-side and client-side with consent gating; and failures fall back to a local mirror for replay.
Backend observability uses the standard three pillars plus profiles for hot-path investigation. Logs are structured records of what the system did at a specific time. Metrics are numeric time-series for performance, throughput, and queue depth. Traces are the shape of a single request or job as it moves across services. Profiles are sampled CPU and memory snapshots for hot-path optimisation. Logging is structured throughout: every log line carries a request id or job id, a user or session reference when permitted, a route or worker name, a stage, a duration, a status, a safe error code, and provider-call references. Personally identifying details never appear in logs, frontend crashes and session errors flow into the same correlation space as backend errors, retention is short and access is controlled, and redaction tests run on every release candidate.
Metrics use Prometheus-style time-series labels. Key metrics include API success rate and latency by route, job queue depth and lease age, dead-letter rate, provider-call outcomes, search timeout rate, and admin mutation throughput; dashboards group metrics by capability so a single screen tells the story for one part of the platform. Tracing uses OpenTelemetry, with a request id flowing from the frontend through the application programming interface (API) into the worker and out to providers, so a trace makes it possible to follow a single user action from the click to the database call to the provider response and back. The instrumentation strategy concentrates on the routes, the long-running jobs, the provider integrations, and the queue, and adds custom traces where the platform spends meaningful time on its own work — the dd-mesher pipeline, the AI generation orchestration, the translation queue. A managed observability stack remains an option as scale grows; the architecture keeps the door open without committing to a managed contract at launch.
A single error tracker collects crashes and unhandled errors from the frontend, the backend, and the workers. Releases are tagged so an error can be associated with the version that introduced it, source maps are uploaded so the frontend stack traces are readable, and sensitive fields are redacted before transmission. Alerts are a small table with thresholds, owners, and runbook actions, and a short summary of the active alert set lives on the Support and telemetry page. The principle is that an alert wakes someone only if they are expected to act, and never wakes them for a problem that resolves itself in the next pull cycle.
Performance monitoring covers four surfaces. Frontend performance tracks Core Web Vitals (largest contentful paint, interaction to next paint, cumulative layout shift), first input delay, time to first byte, route-level render times, the three-dimensional viewer initialisation budget, and image decode metrics; performance regressions are reviewed at release. Mobile performance tracks startup time, scroll smoothness, navigation transitions, frame drops in the viewer, and battery and memory budgets, with the active mobile target being mobile-width browsers because the launch surface is the Web/PWA, while the budgets are set to be compatible with native targets later. Backend performance uses Prometheus histograms for latency by route, by worker, and by provider; the ninety-fifth-percentile latency is the working signal and the median is interpreted alongside it, and database query latency, queue lease age, and external provider response time are first-class. Synthetic monitoring runs a small set of recurring scripted journeys (home, gallery, listing, create, reserve interest) and reports availability and time-to-success, and a failed synthetic check raises an alert. Load testing uses an open-source load-test framework, runs against staging on the release candidate, and is exported to the same metrics store as production, stressing the heaviest endpoints, the queue, and the worker pool.
AI generation calls have variable, sometimes unpredictable cost, and without cost monitoring a runaway loop, a quality regression, or a malicious prompt pattern can produce a meaningful bill in a short time. AI cost monitoring is therefore not optional. Each generation call records the provider, the model, the input size, the output size, the billed amount, the user or session, the request id, and the resulting artefact id, and the data store supports per-user, per-tier, and per-cohort cost queries. Budget controls operate at three layers: per-request budgets that cap the work a single call is allowed to consume, per-user budgets that align with the user's AI design-credit tier, and per-system budgets that protect the operator from a runaway across all users; when a budget is exceeded the system fails closed for the affected user and surfaces a clear safe error. Rate limits live at the application layer and use a Redis-backed sliding window, and common prompt patterns are cached where the contract allows, with cached responses clearly marked as such for observability.
Business analytics sit on the same instrumentation but answer commercial questions rather than operational ones. Revenue metrics include gross merchandise volume (GMV), subscription revenue, kit revenue, AI design credit revenue, marketplace commission revenue, and uniqueness-fee revenue; Phase A has no revenue from kits or the marketplace and produces only an indicative reservation signal and, when activated, AI design credit subscriptions. Unit economics include the variable cost per generation, the cost per kit, the gross margin per order, the customer acquisition cost (CAC), the lifetime value (LTV), and the payback period. Cohort analysis tracks users by sign-up week, and the active cohorts answer how retention, activation, and repeat behaviour change as the product and the messaging change. A simple business-intelligence tool sits on top of the analytics store for ad-hoc questions that go beyond the dashboard.
Inventory analytics are part of observability because they shape stock decisions long before they show up in a profit-and-loss statement. Core metrics include stock-keeping-unit (SKU) inventory, days of cover, sell-through rate, returns rate, defect rate, and dead-stock value. A unique advantage of the DomiDo model is forward demand visibility: a design that has not yet been built, but that has reservations or pre-orders, is a leading indicator for the SKUs in its bill of materials, and the analytics layer surfaces aggregate demand for each SKU before manufacturing begins. Third-party-logistics integration analytics include pick accuracy, pack accuracy, cycle time, shipment exceptions, and per-order cost.
Once the designer marketplace opens, supply-side and demand-side metrics matter alongside marketplace health. Supply-side metrics cover active designers, new designs per week, designer retention, designer share of marketplace gross merchandise volume, and designer satisfaction. Demand-side metrics cover buyers per week, listings per buyer, conversion from listing view to order, repeat buyers, and time-from-discovery to order. Marketplace-health metrics cover liquidity (does most demand match most supply), concentration (how skewed designer share is), and quality (defect-and-return rate by designer). Take-rate benchmarking compares DomiDo's commission share against comparable creator marketplaces to keep the marketplace economics fair.
The implementation runs in five phases. Phase 0, pre-launch, instruments logs, metrics, traces, error tracking, basic analytics, the event dictionary, and the alert table. Phase 1, launch and month one, tunes alert thresholds based on production data, adds missing dashboards, and closes the support-feedback loop. Phase 2, month two, expands business intelligence, tightens AI cost monitoring, and adds the inventory analytics the operations team needs. Phase 3, month three, brings full analytics coverage of acquisition, activation, conversion, retention, and revenue. Phase 4, month four and beyond, scales and optimises, with the option to move to a managed observability provider if the operational cost-benefit shifts. Each month the operating team reviews the funnel and the cohort retention curves, the top errors and their resolution status, the alert table for noise and missed coverage, the AI cost trend and the per-user distribution, the inventory trend and the forward demand visibility, and the support reason clusters and the recurring confusions in copy.