Can we have an admin console for making routine changes ourselves?

Yes. Frequent, low-risk changes that do not alter the data model should normally be self-service. Prices, financial rules, permissions, fraud thresholds, and workflow states need stronger authorization, review, preview, scheduled or staged activation, audit, and one-step rollback. New business logic still needs development and testing; turning every rule into a free-form field creates a different kind of fragility.

Change	Examples	Delivery path	Essential controls
Content	Copy, images, announcements, help	Self-service publishing	Draft, preview, asset validation, rollback
Operations	Campaign dates, local stock, notification templates, ordering	Self-service or reviewed publishing	Scope, timing, bounds, logs
High-impact rules	Price, discount, commission, refund, points, risk threshold	Dual review or controlled ticket	Separation, impact preview, staged release, rollback
Code and schema	New workflow, payment method, or field relationship	Normal engineering release	Requirements, tests, migration, version deployment

When decomposing features, data, and acceptance scenarios, also compare Does admin-system development include customer service and campaign operations? and How should a business choose between custom software and SaaS?; the linked guidance adds context that should be considered in the same decision.

Wavesteam decides configuration boundaries from change frequency, whether finite fields can express the rule, blast radius of an error, validation needs, and whether operators can understand the consequence. Frequent and bounded changes deserve configuration. Rare, combinatorial, or security-sensitive logic is often safer in tested code.

Each setting needs a business-readable name and explanation, type, unit, default, allowed range, applicable location or user, validity period, owner, and affected channels. Validate image dimensions, numeric bounds, date order, and conflicting promotions before save, then preview impact. Names such as config_1 merely move developer dependence into the admin screen.

Separate editing, review, and publishing according to risk. Low-risk copy may allow one role to publish; money, permissions, and global rules should require another authorized reviewer. Record prior and new values, operator, reviewer, time, reason, and outcome without exposing secrets in logs. Every release gets a version that can return to a known-good state.

“Saved” does not mean every app, mini program, website, and store terminal has applied the setting. Show configuration version, release time, and client retrieval state. Enforce critical rules on the server so an old client cannot bypass them. Target staged releases to explicit users or locations, and remove obsolete feature switches.

Acceptance is a real operator completing representative changes in a test environment: draft, preview, submit, schedule, verify every channel, inspect audit history, and roll back. Also attempt invalid assets, negative prices, conflicting dates, unauthorized edits, self-approval of high-risk changes, release failure, and an old client reading a new field. The safe outcome is rejection or continued use of the prior version, plus an alert—not a partial release.

Wavesteam derives a configuration catalogue from a representative history of seasonal, price, policy, and operating changes, prototypes it with operators, and delivers its dictionary, permissions, audit fields, defaults, and release/rollback guide. The Twelve-Factor App, NIST RBAC model, and OWASP ASVS support separation, authorization, validation, and logging principles; the project still needs its own business-risk design.