Resort and Spa Management Vertical on Acumatica

Resort and Spa Management Vertical on Acumatica is the pattern that defines the next decade of enterprise software. The horizontal platform (Acumatica, NetSuite, Dynamics 365, Salesforce) gives you the foundation; the vertical layer is the differentiation. This guide is the field-tested pattern for resort on Acumatica — the architecture, the multi-tenant data model, the go-to-market, and the operational patterns that separate a real product from a one-off customisation.

Why vertical SaaS on a horizontal platform

The horizontal-vs-vertical SaaS debate is over. The answer is: build vertical on top of horizontal. The horizontal platform handles the unsexy work (GL posting, user management, tax calculation, security, audit, multi-currency, infrastructure) and gives you ten years of compliance work for free. The vertical layer adds the industry-specific workflow, the data model, the UI, and the integrations that win customers in the vertical.

Three reasons this works:

1. Time to value. A vertical built on Acumatica ships in 6 months. A from-scratch ERP vertical takes 3 years.
2. Compliance moat. The horizontal platform's compliance posture (SOX, GDPR, ISO 27001) is inherited. The ISV adds the vertical-specific compliance (HIPAA for healthcare, PCI for payments).
3. Customer trust. Customers trust Acumatica's GL more than they trust a startup’s. Building on a known platform is a sales asset.

The architecture

The architecture has three layers: the horizontal platform, the vertical extension layer, and the customer-facing UI. Each layer has its own deployment, its own team, its own release cadence.

Multi-tenant data model

Every vertical customization must be multi-tenant from day one. The data model decisions that determine multi-tenant safety:

• No hard-coded tenant IDs. Use AccessInfo.BranchID and AccessInfo.CompanyID at runtime, never literal IDs.
• Schema additions only. Add columns and tables; never modify base tables. The horizontal platform's upgrade tool relies on this.
• Row-level security in every GI. A GI that returns every tenant's data is a compliance violation. Add the row-level filter explicitly.
• Audit trail on every field. The vertical's data is sensitive. Audit it.

[PXTable(IsOptional = true)]
public class ProjectExt : PXCacheExtension<PMProject>
{
    [PXDBString(20)]
    [PXUIField(DisplayName = "Vertical Code")]
    public virtual string UsrVerticalCode { get; set; }
    public abstract class usrVerticalCode :
        PX.Data.BQL.BqlString.Field<usrVerticalCode> { }
}

For the broader multi-tenant patterns, see the Acumatica multi-tenant customisation guide.

Feature flags for staged rollout

A vertical customization is a product. Features are added over time, and not every customer wants every feature. The pattern: feature flags per tenant, configurable in the UI.

public static class VerticalFeatures
{
    public static bool IsEnabled(PXGraph graph, string featureKey)
    {
        var fs = PXSelect<UsrFeatureFlag,
            Where<UsrFeatureFlag.tenantID, Equal<Required<UsrFeatureFlag.tenantID>>,
                And<UsrFeatureFlag.featureKey, Equal<Required<UsrFeatureFlag.featureKey>>>>
            .Select(graph, AccessInfo.BranchID, featureKey);
        return fs.Any() && fs.First().Enabled == true;
    }
}

// Usage
if (VerticalFeatures.IsEnabled(Base, "advanced-scheduling"))
{
    // run the advanced scheduling logic
}

For the broader feature flag patterns, see the feature flags guide.

Tenant onboarding

Every vertical customer is a new Acumatica tenant. The onboarding flow:

1. Tenant provisioning. Acumatica SaaS tenant, Acumatica self-hosted, or on-prem.
2. Customization publish. The vertical package is published to the tenant.
3. Data migration. The customer's data is migrated to the new tenant (using Acumatica Import Scenarios).
4. Feature configuration. Feature flags are set per the customer's contract.
5. User setup. Users are created with the right roles.
6. Training. The customer is trained on the vertical-specific screens.

Pricing the vertical

The pricing for a vertical on a horizontal platform is layered:

Go-to-market

The go-to-market for a vertical SaaS on a horizontal platform is partner-led. The horizontal vendor (Acumatica) has the sales team, the marketing channels, the partner network. You bring the vertical expertise and the customer relationships in the vertical. The motions:

• Vertical-specific landing pages. SEO-optimised pages for every persona in the vertical.
• Vertical content. This blog, the whitepapers, the case studies.
• Vertical events. The trade shows, the user groups, the webinars.
• Acumatica Marketplace listing. The first place a customer looks.
• Channel partner program. The Acumatica resellers who sell in your vertical.

Operations at scale

The operational challenges of a vertical at scale:

• Multi-version support. Customers on different Acumatica versions (R1, R2, current). Your customization must support all of them.
• Multi-tenant testing. Every release is tested across tenant configurations.
• Issue triage. A bug report could be Acumatica, your customization, the customer's data, or the customer’s configuration.
• Compliance. SOC 2, ISO 27001, GDPR, the customer's industry compliance.

For the broader operational patterns, see the monitoring guide and the incident response runbook.

Wrapping up

The horizontal platform, the vertical layer, the multi-tenant data model, the feature flags, the onboarding, the pricing, the go-to-market, the operations. Get all eight right and the vertical scales. Skip any one and the product struggles. The discipline is the same as any product, with the Acumatica-specific patterns layered on top.

Wrapping up

That is the working approach I use on Acumatica projects. The same patterns show up whether you are in Nairobi, Johannesburg, Kigali, Lusaka or Harare — and they are the things that keep work moving when an upgrade lands at 6 PM on a Friday. If you are stuck on something specific, reach out or keep reading through the rest of the Acumatica blog.

John Kihiu

Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.