How WakeTech.ai deploys to enterprise customers.

The problem with shared-codebase SaaS

Modern cloud-native TMS vendors operate on a single multi-tenant codebase where every customer runs identical software against a logically-separated slice of a shared database. The vendor philosophy is one codebase, no customization, configuration only.

This model is efficient for the vendor and appropriate for customers whose operations fit inside the vendor opinionated workflow. It fails when a customer organization cannot be represented by the vendor data model. Enterprises with hierarchical sub-divisions, federated regional offices, multiple legal entities, or industry-specific workflows that fall outside the vendor core assumptions hit a ceiling that no amount of configuration can break through.

The Wake Tech model

WakeTech.ai operates on a hybrid architecture that preserves the engineering discipline of a single canonical platform while giving each enterprise customer the isolation, customization flexibility, and data sovereignty they need. The model has four components.

1. Shared rigid core

All WakeTech.ai customers run the same platform at the same version. Core is a single canonical codebase maintained by the WakeTech.ai engineering team. Core improvements, security patches, and new features propagate to every customer on a regular release cadence. No customer modifies core. No customer runs a forked version of core. This discipline is what lets us maintain high development velocity, predictable quality, and defensible security posture as we scale.

2. Dedicated per-customer deployment

Each enterprise customer receives a dedicated deployment of the WakeTech.ai platform. Dedicated means:

• Your own virtual infrastructure. Dedicated compute, dedicated storage, dedicated network perimeter. No shared VM, no shared container host, no noisy neighbor.
• Your own database. Customer data lives in a database that only your deployment writes to and reads from. No shared warehouse, no logical tenant separation inside a common schema.
• Your own Azure tenant option. For customers with strict data residency or regulatory requirements, deployment can land inside your corporate Azure tenant under your billing, your compliance controls, and your retention policies.
• Your own deployment lifecycle. Upgrades happen on a schedule that works for your change management process. You are not forced to upgrade the day WakeTech.ai releases a new core version. You are not blocked from upgrading because another customer is on an older version.

3. Customization layer

Customer-specific behavior lives in a dedicated customization layer that sits alongside core, never inside core. The customization layer is where the enterprise value lives for large customers. It contains:

• Workflow extensions that hook into core lifecycle events (order created, tender accepted, carrier onboarded, invoice generated) and execute customer-specific logic
• Custom data model extensions that add fields, tables, and relationships the customer needs without altering core schema
• Custom reports, queries, and dashboards built against core data plus the customer extended data
• Customer-specific integrations to legacy systems, compliance platforms, customs brokers, EDI networks, ERPs, and anything else the customer already runs
• Organizational model overrides for customers whose real-world structure exceeds the core platform default assumptions (hierarchical division trees, federated station networks, multi-entity corporate rollups, per-office workflow variation)
• Custom UI components rendered inside core pages through defined extension slots

4. Clean boundary between core and customization

The line between shared core and customer customization is enforced by engineering discipline, not convention. Core publishes a versioned extension API and commits to backward compatibility within a major version. Customization layers depend only on the published API, never on core internals. Core and customization layers deploy independently. The core test suite runs without any customer extensions loaded. Customization test suites run against a known core version and alert on incompatibility before production.

What this means for an enterprise customer

You own your data. Every row, every file, every log. Stored in your database, in your deployment, under your control. Portable on request.

You own your customizations. The extension layer code that represents your specific business processes belongs to you. If you ever leave WakeTech.ai, you take it with you. If you want to maintain it with your own engineering team, you can.

You do not own the core platform. WakeTech.ai owns and maintains the shared core, which is licensed to you as part of your deployment. You benefit from every core improvement we ship for every customer. You are never responsible for maintaining core yourself. This is the trade: shared core gives you leverage, the customization layer gives you control, and the dedicated deployment gives you isolation.

You are not a tenant in someone else database. Your data never mixes with another customer data. Your performance is not affected by another customer workload. Your security posture is not coupled to another customer security posture.

You can customize without forking. Unlike vendors who publicly state they do not allow customization, WakeTech.ai treats customization as a first-class product capability. When your workflow does not fit the core defaults, we extend your customization layer, not core, and your specific needs become a maintained part of your deployment without compromising the shared platform other customers depend on.

How customizations get built and owned

When an enterprise customer funds a new capability, WakeTech.ai evaluates whether it belongs in shared core or in the customer customization layer. The decision is based on generality, not who paid.

Broadly useful capabilities (hierarchical division modeling, multi-currency support, enhanced customs documentation) become part of shared core. Every WakeTech.ai customer eventually benefits. The funding customer gets the feature first, gets implementation priority, and gets recognition. Pricing reflects that the capability will be amortized across the platform.

Customer-specific capabilities (a particular legacy ERP integration, an internal GL code mapping, a proprietary carrier scoring algorithm, a specific compliance workflow unique to the customer business) live in the customer customization layer. They are built to the customer specification, maintained as part of the customer deployment, and do not appear in any other customer environment. Pricing reflects that the cost is not amortized.

This policy protects the integrity of the shared core while ensuring every customer gets genuine customization value.

Security and compliance posture

• Data isolation. Each customer data resides in a dedicated database with no cross-tenant queries possible at the infrastructure level, not just the application level.
• Network isolation. Each deployment runs in its own network perimeter with customer-controlled ingress and egress rules.
• Credential isolation. Customer credentials, API keys, and service account tokens never touch another customer deployment.
• Compliance boundary. Because deployment can live in the customer Azure tenant, WakeTech.ai is never a data processor for customers who require data to remain under direct corporate control. This simplifies GDPR, SOC 2, customs regulations, and industry-specific compliance obligations.
• Blast radius containment. A security incident in one customer deployment cannot propagate to another customer deployment. A database corruption event in one deployment cannot affect another.
• Audit and observability. Each deployment has its own audit log, its own monitoring, its own backups. Customers can receive direct read access to their own operational telemetry.

Responsibility split

Summary

WakeTech.ai architecture refuses the false choice between rigid multi-tenant SaaS and forking the codebase per customer. The shared rigid core preserves platform quality and development velocity. The dedicated per-customer deployment preserves isolation, data sovereignty, and compliance posture. The customization layer preserves the customer ability to model their actual organization and integrate their actual systems without compromising the core or affecting other customers.

For an enterprise customer whose organization cannot be represented by a vendor opinionated data model, or whose compliance posture cannot tolerate a shared database, this architecture is the only one that works at scale.