The Strategy: Crossing the Chasm
The Mach Five Tech SaaS engine brings together reusable core components, engagement-first design, and configuration-driven differentiation to help turn a product idea into software people use. Its maintainable client and admin apps provide a foundation that can grow with the product, from the first launch to everyday operations.
TL;DR
Launch in days, configure for change
The requirement is to build a SaaS engine that will allow M5T to launch a complete product in any vertical, in a matter of days. We’ve encapsulated the core functionality that is common to all SaaS products. We’ve built change into the engine, so that custom differentiation logic can be abstracted via stack configuration. No code required.
Build engagement into the product
An M5T SaaS is engagement first. Meaning we’ve codified strategies for growth, discoverability, social virality, user-generated content, AI agent exposure, affinity marketing, developer advocacy, partnership marketplace, dynamic JSON-LD, and user skill certification. We do not “Build it and they will come”.
Keep the experience interactive
An M5T SaaS is interactive. It is an easy-to-use platform to send targeted instant messages to your app users. You can easily send notifications, in-app surveys, product tours, voice mail, and slideshows. No code required.
ERD Schematic
Explore the database architectureDesign principles and eight reusable core components.
The database schematic is designed to perform well with both atomic user transactions and aggregated community push updates (multi-user bidding or dynamic pricing). This design can be described as evolved, vetted, rational, auditable, and performant.
The standardized audit trail captures not only the when and the who, but also who is responsible for which state transition. Additionally, self-serve auth events such as password reset are anonymized and preserved in an indexed and searchable JSONB column. This supports auditing of authentication workflows and password policy enforcement.
Data integrity is enforced by the schema. Standardized use of CHECK constraints prevents data state drift, ensuring that every data update meets categorization requirements. All timestamps use UTC (Zulu time) in ISO format.
Third-party integration is anticipated and facilitated. We’ve standardized persistence for event-driven webhooks, RSS feeds, and synchronized GUIDs for downstream extracts.
A layer of database views provides a role-based, optimized, standardized, and sometimes denormalized access to data without exposing soft-deleted or archived rows.
Push-optimized database triggers aggregate community data and package it for server-sent event (SSE) streaming. Within a user’s particular community, one user’s changes may be instantly made visible to all the other users. This is required for applications wherein users are bidding in real-time or multi-user gaming platforms. Minimal code required.
Application metering is a holistic administrative debugging view, giving insight into application usage and health. This self-cleaning data silo acts as a log with the powers of an RDBMS. Meaning that the captured events contain the keys to actual related rows, making auditing and diagnostics easier.
The reusable components are those named with the “acct” or “core” prefix. These are the database objects that will exist in every SaaS instance, such as:
Reusable Core Components
acctEntitySaaS account entity representing users, roles, and organizations.
status — account verification and lifecycle state
Default: UNVERF
| Value | Meaning |
|---|---|
UNVERF | Created but the email link has not been followed. Cannot sign in. |
AUTH | Verified and able to sign in. The only status that authenticates. |
DELETED | Soft deleted. Email is timestamp-prefixed so the address can be reused. |
ARCHIVED | Retained but withdrawn from use. |
class — user role / privilege level
Default: client_standard_role
Roles are ordered by privilege value. A user may only assign a role at or below their own, and the User Management Console requires a value of 50 or above.
| Value | Value rank | Meaning |
|---|---|---|
admin_root_role | 100 | Superuser — infrastructure and architecture |
admin_business_role | 90 | Financial oversight |
admin_support_role | 80 | Maintenance and configuration |
admin_readonly_role | 70 | Help desk, read only |
client_tier_4_role | 40 | Paid tier 4 |
client_tier_3_role | 30 | Paid tier 3 |
client_tier_2_role | 20 | Paid tier 2 |
client_tier_1_role | 10 | Paid tier 1 |
client_standard_role | 0 | Free tier |
The rank column is not in the DDL. It comes from
EntityClassesinpackages/shared/src/metadata/entityClasses.js, which is where the ordering is enforced. The database constrains membership; the application constrains precedence.
coreAIQCore AI queue for LLM prompts, responses, and system contexts.
status
Default: ACTIVE
| Value | Meaning |
|---|---|
ACTIVE | Live queue entry |
EXPIRED | Past its useful window |
DELETED | Soft deleted |
ARCHIVED | Retained, withdrawn from use |
class
Default: coraiq_silo_augment
| Value | Meaning |
|---|---|
coraiq_silo_augment | Enrichment of a specific data domain |
coraiq_realtime | Live interaction |
coreAssetsAsset management for promotions, branding, and white labeling.
status
Default: DRAFT
| Value | Meaning |
|---|---|
DRAFT | Not yet served |
ENABLED | Live |
DISABLED | Deliberately withheld |
DELETED | Soft deleted |
ARCHIVED | Retained, withdrawn from use |
class
Default: coreasset_brand
| Value | Meaning |
|---|---|
coreasset_brand | Brand identity asset |
coreasset_promotion | Promotional material |
coreasset_whitelabel | Per-customer white-label asset |
coreasset_theme | Theme definition |
coreDialogCorrespondence — email, SMS, and notifications, with threaded conversations.
status — delivery lifecycle
Default: QUEUED
This is the longest lifecycle in the schema because it tracks a message all the way to recipient engagement, not just to dispatch.
| Value | Meaning |
|---|---|
DRAFT | Composed, not yet queued |
QUEUED | Awaiting the send daemon |
SENT | Handed to the transport |
RECEIVED | Confirmed delivered / opened |
CLICKED | Recipient followed a link |
REPLIED | Recipient responded |
EXPIRED | Time window elapsed without action |
DELETED | Soft deleted |
ARCHIVED | Retained, withdrawn from use |
class — channel
Default: diacls_email
| Value | Meaning |
|---|---|
diacls_email | |
diacls_sms | SMS |
diacls_bell | In-app notification bell |
diacls_web_note | On-page note |
coreInvoiceTiered subscription billing and partner invoices.
status — billing lifecycle
Default: DRAFT
| Value | Meaning |
|---|---|
DRAFT | Not yet issued |
BILLED | Issued and outstanding |
PASTDUE | Outstanding beyond its terms |
PAID | Settled |
DELETED | Soft deleted |
ARCHIVED | Retained, withdrawn from use |
class
Default: corinv_tier_bill
| Value | Meaning |
|---|---|
corinv_tier_bill | Subscription tier billing |
corinv_partner | Partner arrangement |
coreMetaEnvironment variables, feature flags, overrides, macros, rules, and silos.
meta_env — environment scope
Default: PROD
Unique to this table. The same meta_token may exist once per environment, which is how a flag takes different values in DEV and PROD.
| Value | Meaning |
|---|---|
PROD | Production |
QA | Quality assurance |
UAT | User acceptance testing |
SIT | System integration testing |
DEV | Development |
SANDBOX | Isolated experimentation |
status
Default: DRAFT
| Value | Meaning |
|---|---|
DRAFT | Defined but not served |
ACTIVE | Served to the config loader |
DELETED | Soft deleted |
ARCHIVED | Retained, withdrawn from use |
class — metadata classification
Default: metcls_env_var
| Value | Meaning |
|---|---|
metcls_env_var | Environment variable |
metcls_feature_flag | Feature flag |
metcls_override | Override of another value |
metcls_macro | Macro definition |
metcls_rule | Rule definition |
metcls_silo | Silo configuration |
metcls_keyval | Generic key/value |
metcls_template | Template (e.g. email markup) |
metcls_schema | Schema definition |
coreMeterUsage, events, and system activity, recorded at syslog severity levels.
status
Default: NEW
| Value | Meaning |
|---|---|
NEW | Unread |
READ | Reviewed |
PRESERVE | Pinned against routine cleanup |
DELETED | Soft deleted |
ARCHIVED | Retained, withdrawn from use |
class — syslog severity
Default: INFO
The only class in the schema that is an ordered severity scale rather than a taxonomy. Values follow RFC 5424, most severe first.
| Value | Severity | Meaning |
|---|---|---|
EMERGENCY | 0 | System unusable |
ALERT | 1 | Immediate action required |
CRITICAL | 2 | Critical condition |
ERROR | 3 | Error condition |
WARNING | 4 | Warning condition |
NOTICE | 5 | Normal but significant |
INFO | 6 | Informational |
DEBUG | 7 | Debug detail |
coreSnippetReusable code templates, queries, and schemas.
status
Default: DRAFT
| Value | Meaning |
|---|---|
DRAFT | Not yet served |
ENABLED | Live and servable |
DISABLED | Deliberately withheld |
DELETED | Soft deleted |
ARCHIVED | Retained, withdrawn from use |
class — snippet language
Default: coresnippet_js
| Value | Meaning |
|---|---|
coresnippet_js | JavaScript |
coresnippet_sql | SQL |
coresnippet_json | JSON |
coresnippet_schema | Schema definition |
coresnippet_css | CSS |
coresnippet_html | HTML |
The Client App
The SaaS Client app is the customer-facing user experience. It may exist in a browser, a smartphone native app, or a plugin to a chat or platform ecosystem.
The Client is web native, meaning it is built with standard web technologies and should function on any reasonable viewport.
Our preferred architecture is vanilla JavaScript with a Vite build. Our framework-agnostic web components can be used and reused in any web page. We tend to push the limits of the user agent APIs, pushing the boundaries of offline first, PWA, Web Crypto, Worklets, WASM, Web Audio, Voice, USB, WebGL, Multi-threaded Web Workers, WebMCP, and WebLLM.
We favor the PubSub pattern because it allows us to abstract our components and facilitates automated testing. It’s not uncommon for us to record and play back entire user sessions using just the storage of the PubSub session. This is a powerful supportability toolset. It is exactly this type of commitment to maintainability that separates our vetted implementations from the vibe-coded AI slop that you will be seeing much of.
We use a monorepo project structure. This allows us to share business logic between the client app, the admin app, and the backend services.
All of our component libraries have an accompanying Claude SKILL file, to leverage shared wisdom across the developer community and quick adaptation.
The Admin App
The admin app is used to manage the core system functionality of the app. This tool is usually run locally and because every SaaS implementation uses the same core components, it may be used to administer multiple SaaS products. This is the tool that one would use to monitor the health of the app, resolve helpdesk inquiries, and run maintenance processes. The tool may be accessed in a read-only mode (role) for helpdesk personnel.
