{"title":"Choose a pattern with a tested operating range","description":"The business-template promise and the evidence behind recommendations","section":"project","version":"v2","path":"project/business-templates","canonical_url":"https://amberframework.org/docs/v2/project/business-templates","markdown_url":"https://amberframework.org/docs/v2/project/business-templates.md","inherited":false,"content_markdown":"# Choose a pattern with a tested operating range\n\nWe want you to choose a familiar business pattern and deployment profile before building. Every recommendation should explain the problem it solves, why we chose it, how to migrate, and what we measured. Maintainers supply the working reference app and reusable checks; you and your assistant choose a profile and verify your app's assumptions.\n\nThe intended promise is specific: this version of this template meets these correctness and performance targets under this published workload and environment. A wider range requires another measurement and review.\n\n| App idea | First pattern to evaluate | First useful proof |\n| --- | --- | --- |\n| Organization client portal | Shared tables with row-scoped tenancy; preserve PostgreSQL schemas when that fits an existing Apartment app | Two organizations create, list, edit and restart; authorization and jobs preserve ownership |\n| Inventory tracker | Typed forms, durable records, indexed lookups and bounded lists | Correct stock movements, concurrent updates, search/edit and restart persistence |\n| Service request desk | One typed workflow, registered jobs and a verified delivery adapter | State transitions, safe repeated work, reminder delivery and recovery |\n\nThese are app invitations. Packaged reference templates, executed migration tutorials and measured capacity profiles are in preparation. The default memory job adapter is process-local and lost on restart; reliable reminders need their own verified delivery/recovery path.\n\n## What a recommendation carries\n\n- A runnable example at an exact template/release revision and hash, with supported toolchain/dependencies, configuration, schema/indexes and fixtures.\n- A short explanation of intended use, assumptions, measured rationale and meaningful alternatives.\n- A version-pinned migration with ID/relationship/constraint checks, dry run, cutover and rehearsed recovery.\n- A measured operating range: tenant/data distribution, request/job mix, offered rate and concurrency, hardware/resources, database/pool/network, cold/steady/burst/soak durations, correctness, latency, throughput, errors, CPU/memory and relevant database/queue results.\n- Raw repeated trials, uncertainty, operational headroom, observed limits, accountable review and intended-use guidance for people and agents.\n\nCore router or codec results supply evidence at their own scope. Numeric business-app capacity needs complete application/database measurements. You own suitability and acceptable latency, isolation, cost and growth needs; maintainers own the reference profile and harness.\n\nA relevant source, schema/index, configuration, workload or environment change invalidates the affected profile until remeasurement and review. Keep earlier profiles tied to earlier releases. Publish the tutorial, profile, agent guidance and budgets together through the [release contract](/docs/v2/project/release-contract)."}