[MS] The Agentic Road to Revenue - devamazonaws.blogspot.com

The Agentic Road to Revenue   From SaaS concept to Azure Marketplace Building a SaaS application is only part of becoming a commercial software provider. To sell through the Microsoft commercial marketplace, the application also needs tenant isolation, subscription lifecycle management, billing integration, security evidence, and a publishable Partner Centre offer. To make this journey easier we have built SaaS_Skills into GIT-APE. This article follows Contoso Azure SaaS through seven stages, from selecting an offer model and applying the SaaS Architecture Reference Design to publishing its Azure Marketplace listing. All code was opened in VScode and git-ape run from the chat there.

• This is based on a fictious SaaS app you can find here
• The SaaS_Skills can be found here
• The Architecture Reference Desing they reference can be found here

We will be run the SaaS journey from concept to Public offer using the below skills now found in to git-ape

Step	Skill(s)	What they do
1	marketplace-offer-types	Confirm the commercial model and offer type. Completed: SaaS Transactable is the target.
2	multi-tenant_SaaS	Assess the repo, define the target architecture, and produce the master implementation plan.
3	tenant-isolation-models + isv-landing-zone-foundation	Define tenant boundaries and establish the Azure identity, networking, governance, and environment foundation.
4	saas-accelerator-bootstrap + tenant-lifecycle-automation + fulfillment-and-metering	Build Marketplace integration, tenant provisioning, subscription lifecycle, entitlements, and billing.
5	security-and-compliance + deployment-blueprints + scale-and-sre	Validate security and isolation, create repeatable deployments, and prepare reliability and operations.
6	onboard-to-marketplace	Configure Partner Centre, test the offer privately, complete certification, and prepare for launch.

1. Select the offer model with marketplace-offer-types

The first decision is how customers will discover, purchase, and pay for Contoso Azure SaaS. The marketplace-offer-types skill compares SaaS, Azure Application, container, virtual machine, and managed-service offers. Because Contoso is operated as a hosted application rather than deployed into each customer's subscription, a SaaS offer is the natural fit. It uses the flowing flow based on your code to come up with an outcome you can add to the prompt to help guide choices. The team uses git-ape to help them chooses between. In git-ape run /git-ape-azure-saas-skills marketplace-offer-types: Here's the Marketplace offer-type assessment for Contoso Outdoors: Product Profile

Attribute	Value
Application	Contoso Outdoors — e-commerce web app (Next.js SSR)
Hosting	ISV-hosted on Azure App Service (B1 Linux)
Architecture	Single-tenant web app + App Insights monitoring
AI Features	Chat API (grounded, visual, prompt flow endpoints)
Data	Static JSON catalogue (products, brands, categories) + product manuals
Current Infra	Bicep IaC, GitHub Actions CI/CD, managed identity

Offer-Type Fit Assessment

Offer Type	Fit	Rationale
SaaS Transactable	★★★★★ Best Fit	ISV-hosted, multi-tenant potential, Microsoft handles billing, co-sell eligible, works with your current App Service architecture
SaaS License-only	★★★★☆	Good if you prefer enterprise-negotiated pricing or want lead-gen before committing to Fulfillment API integration
Managed Application	★★☆☆☆	Poor fit — your app is ISV-hosted, not deployed into customer subscriptions
Solution Template	★☆☆☆☆	Poor fit — non-transactable, customer-managed, opposite of your SaaS model
Virtual Machine	★☆☆☆☆	Not applicable — this is a web app, not an appliance
Container	★★☆☆☆	You have a Dockerfile, but this offer type is for customer-hosted K8s workloads
Managed Service	★☆☆☆☆	Not applicable — you're selling software, not operational services

Recommendation: SaaS Transactable This is the strongest fit because:

1. You already host the app — customers subscribe and use it via browser, no deployment into their tenant
2. Billing flexibility — per-seat (per store/user), metered (API calls to chat endpoints), or flat monthly
3. Co-sell eligible — Microsoft sellers can include your offer in deals
4. Azure Portal integration — customers can subscribe directly from the Azure Marketplace
5. Your infra is ready — App Service + Bicep + GitHub Actions is a clean foundation to build on

What You'd Need to Add

Component	Status	Work Required
Partner Centre account	Needed	Register at partner.microsoft.com, set up payout/tax
Landing page	Needed	Page where Marketplace redirects after purchase (resolve token, activate subscription)
Webhook endpoint	Needed	Handle suspend/reinstate/unsubscribe lifecycle events
Fulfillment API v2 integration	Needed	Resolve purchase token, activate subscription, report usage
Multi-tenant support	Partial	Currently single tenant; need tenant isolation for catalogue/chat per customer
Metered billing (optional)	Needed	If charging per chat API call or per product catalogue size

Suggested Billing Model Given the product (e-commerce platform + AI chat):

• Base plan: Flat monthly fee per storefront
• Metered dimension: AI chat interactions (grounded/visual queries) billed per 1,000 calls
• Tiers: Free trial → Starter (1 store, 100 products) → Pro (unlimited stores, custom branding)

Next Steps Would you like to:

1. Start building the SaaS fulfillment API integration (landing page + webhook + token resolution)
2. Onboard to Partner Centre with a step-by-step guide
3. Design the multi-tenant architecture to support multiple customers
4. Deep dive into metered billing implementation

Exit condition: Contoso has a documented SaaS offer model and knows which Marketplace APIs it must support.

Apply the SaaS Architecture Reference Design

The SaaS Architecture Reference Design (SaaS ARD) provides the architectural blueprint connecting Contoso's product, Azure platform services, tenant management, and Microsoft Marketplace integration. While the SaaS Accelerator supplies reusable implementation components, the ARD explains how those components should fit into the wider production platform. It helps Contoso make consistent decisions about:

• Tenant identity and isolation.
• Control-plane and application-plane separation.
• Customer onboarding and tenant provisioning.
• Marketplace subscription and entitlement mapping.
• Regional deployment stamps and tenant placement.
• Data partitioning and tenant-context propagation.
• Metering, observability, and cost allocation.
• Security, resilience, and day-two operations.

For Contoso, the architecture can be divided into two major areas:

Control plane	Application plane
Marketplace landing page	Customer-facing APIs and UI
Subscription and entitlement management	Tenant workloads
Tenant provisioning	Tenant-partitioned data
Plan and configuration management	Messaging and background processing
Metering and operational administration	Tenant-aware monitoring

This separation prevents Marketplace and administrative operations from becoming tightly coupled to the customer-facing application. It also allows Contoso to scale application workloads independently from tenant provisioning and subscription management. The SaaS ARD is particularly useful for identifying gaps before adopting the SaaS Accelerator. Contoso can compare its current architecture with the reference design, decide which accelerator components to reuse, and create a backlog for missing capabilities rather than treating the accelerator as a complete product.

SaaS ARD	SaaS Accelerator
Defines the target architecture	Provides reusable implementation patterns
Documents boundaries and decisions	Implements landing pages and Marketplace flows
Guides scale, isolation, and operations	Accelerates subscription integration
Technology-guidance focused	Deployment and customization focused

Exit condition: Contoso has a target architecture showing tenant boundaries, control-plane responsibilities, Marketplace integration points, and the accelerator components it will adopt.

2.Validate the platform with multi-tenant SaaS

Marketplace integration does not automatically make the application safely multi-tenant. The multi-tenant SaaS skill evaluates the complete platform architecture, including tenant definitions, user association, tenant-context propagation, resource isolation, tenant lifecycle, and noisy-neighbour controls. When you run the command git-ape-azure-saas-skills multi-tenant_saas skill, it then collates and creates a report of the environment. In the plan it outlines the work necessary and step need to take. Our example shows how Contoso Outdoors plans to transform its single-tenant storefront into a scalable, multi-tenant SaaS platform sold through Azure Marketplace. The target architecture combines shared Azure compute with tenant-isolated data, per-tenant identity, AI configuration, usage metering, and automated subscription management. Delivery is staged across a 12-week roadmap—from landing-zone foundations and tenant isolation to Marketplace fulfilment, tiered pricing, security, and operational readiness. The result is a commercially viable, Microsoft-billed SaaS offer designed to scale efficiently while maintaining strong tenant separation, observability, and reliability. Example reports can be viewed here Exit condition: Contoso has documented tenancy boundaries, isolation decisions, tenant placement rules, and lifecycle automation.

3. tenant-isolation-models + isv-landing-zone-foundation

The tenant-isolation-models and isv-landing-zone-foundation skills turn broad Azure architecture guidance into project-specific decision records. Rather than producing a generic checklist, the skills assess the application’s expected tenant count, security requirements, cost constraints, operating model, Azure services, and growth plans. They then capture the resulting decisions as Markdown files that can be reviewed, versioned, and updated alongside the application code. For Contoso Outdoors, the tenant-isolation-models skill produced tenant-isolation-model.md. It defines what a tenant means in this product—a retail brand operating a storefront—and maps users, administrators, and Marketplace subscriptions to that boundary. It recommends pooled compute with logically isolated data, documents how tenant context must be established and propagated, and specifies controls for Cosmos DB, Blob Storage, messaging, telemetry, and future AI workloads. It also records capacity thresholds and a migration path from one shared deployment stamp to regional stamps and dedicated infrastructure for premium tenants. The isv-landing-zone-foundation skill produced isv-landing-zone-foundation.md. This document moves beyond application-level tenancy and describes the Azure platform needed to operate the service safely. It defines separate development, staging, and production subscriptions; private networking; Azure Front Door and WAF; managed identities; least-privilege RBAC; Azure Policy; monitoring; cost controls; and deployment promotion. It also provides an ordered infrastructure backlog and a proposed Bicep module structure, helping the team translate architectural decisions into implementation work. For the reader, these files explain not only what Contoso intends to build, but why each choice was made. Developers can use them to understand tenant-context requirements, platform engineers can derive infrastructure modules, security reviewers can trace isolation controls, and product owners can see how cost and scale influence the architecture. Because the records live with the code, they also provide a shared baseline for pull-request reviews and prevent important decisions from being lost in meetings or chat history. A SaaS team can run the skills against its own repository and receive recommendations based on its tenant definition, regulations, scale, regions, and isolation needs. The value lies in the repeatable decision process: assess the product, document the trade-offs, establish measurable boundaries, and maintain those decisions as the platform evolves. Example reports can be viewed here

4. Build the marketplace integration with SaaS-accelerator-bootstrap

The next Git-Ape skills move Contoso Outdoors from architectural intent toward a practical Marketplace operating model. Each skill examines a different part of the commercial lifecycle and produces a Markdown decision record in the repository. These files are not generated application code or proof that the features are already deployed. Instead, they are version-controlled implementation blueprints that describe the target design, assign responsibilities, expose gaps, and give the team a sequence of work that can be reviewed through pull requests. The saas-accelerator-bootstrap skill produced saas-accelerator-bootstrap.md. It defines how Microsoft’s SaaS Accelerator patterns could provide the Marketplace-facing control plane—the purchase landing page, webhook receiver, subscription database, and administrative portal—while the existing Next.js application remains the customer-facing application plane. For Contoso, the document maps the boundary between reusable Accelerator components and product-specific work such as creating tenants, configuring storefronts, enforcing entitlements, and responding to subscription changes. It also turns those gaps into a phased customization and cutover backlog. The tenant-lifecycle-automation skill produced tenant-lifecycle-automation.md. This document explains what must happen after a Marketplace purchase has been resolved. It models a tenant’s journey through provisioning, activation, plan changes, suspension, reinstatement, offboarding, retention, and deletion. It then assigns each transition to a component and defines asynchronous event contracts, retry behaviour, idempotency, reconciliation, service-level targets, and operational recovery. For the reader, this demonstrates that tenant onboarding is not a single API call: it is a durable business process that must remain correct when events are duplicated, resources fail to provision, or Marketplace and application records drift apart. The fulfillment-and-metering skill produced fulfillment-and-metering.md. It connects Marketplace subscription state to Contoso’s internal tenants and entitlements. The document covers purchase-token resolution, activation, webhook handling, plan changes, suspension, cancellation, optional usage meters, retries, audit records, and financial reconciliation. This distinction is important: the SaaS Fulfillment APIs manage subscription lifecycle, while the Marketplace Metering API reports chargeable usage. Together, they ensure that a purchase grants the correct product access and that any consumption charges can be explained and reconciled. For readers the documents show the questions that every transactable SaaS platform must answer: Where does Marketplace integration end and product logic begin? How does a subscription map to a tenant? Which events change access? How are partial failures repaired? What evidence supports a usage charge? Teams can run the same skills against their own repository and adapt the resulting decisions to their pricing model, tenant boundaries, retention obligations, Azure services, and operational scale. The records also require validation against the actual product. For example, Contoso’s current repository has removed its AI chat capability, so the proposed chat-based plans and meters are illustrative rather than implementation-ready. Before development begins, those sections should be replaced with billable dimensions supported by the real application—or metering should be omitted in favour of flat-rate plans. This is another benefit of keeping the outputs as Markdown decision records: assumptions remain visible, reviewable, and correctable before they become production architecture. Example reports can be viewed here Exit condition: A Marketplace purchase can enter Contoso through a defined landing-page and subscription-processing flow.

5. Establish trust with security-and-compliance

The deployment-blueprints, security-and-compliance, and scale-and-sre skills take Contoso Outdoors beyond functional Marketplace integration and examine whether the proposed platform can be deployed, protected, and operated reliably. Each skill produces a Markdown decision record in the repository. These records do not prove that the controls or infrastructure already exist; they describe the target state, identify implementation work, and provide reviewable acceptance criteria for future changes. The deployment-blueprints skill produced deployment-blueprints.md. It translates Contoso’s architecture into an executable deployment strategy. The document defines how networking, data stores, messaging, control-plane services, customer-facing services, routing, identity, and observability should be deployed in dependency order. It also proposes environment-specific Bicep parameters, a modular infrastructure layout, CI/CD promotion, canary releases, rollback procedures, and blast-radius controls. As Contoso grows, the blueprint evolves from a single-region deployment into regional deployment stamps, with a global control plane responsible for tenant placement and routing. For readers, this document bridges the gap between an architecture diagram and working infrastructure. It shows which resources depend on one another, what changes between development and production, how releases should progress, and how the platform can expand without turning each new region into a bespoke deployment. Another SaaS team can reuse this decision structure while substituting its own Azure services, regions, capacity limits, and release policies. The security-and-compliance skill produced security-and-compliance.md. It evaluates trust boundaries across browsers, Marketplace webhooks, public application endpoints, internal services, data stores, and administrative components. The output maps proposed controls to each component, defines threats such as tenant-header manipulation and cross-partition data access, and establishes tests designed to prove that one tenant cannot access another tenant’s resources. It also covers managed identities, secret rotation, encryption, retention, audit logging, operator access, compliance evidence, and residual risks. To the reader, this record makes security requirements concrete and testable. “Tenant isolation” is no longer an architectural claim; it becomes a collection of controls and tests spanning APIs, databases, storage, background jobs, telemetry, and administration. The status of every control must still be checked against the deployed configuration. Controls labelled as configured in a target-state document should not be treated as implemented until the corresponding Bicep, application code, policy, and tests exist. The scale-and-sre skill produced scale-and-sre.md. It defines how Contoso should measure and operate the service after launch. The record introduces availability, latency, error-rate, and provisioning objectives; scaling thresholds for shared resources; per-tenant quotas; noisy-neighbour detection; backup and disaster-recovery expectations; tenant-aware observability; cost attribution; incident severity levels; and operational runbooks. This ensures that platform health can be measured both globally and for an individual tenant. For readers, the SRE record demonstrates that multi-tenancy changes day-two operations. A platform can appear healthy overall while one tenant is throttled, misrouted, or consuming a disproportionate share of capacity. Tenant-aware telemetry and quotas allow operators to detect those conditions, understand their commercial impact, and respond before one customer affects the rest of the service. Together, these three records form a practical production-readiness layer: Contoso is a reusable reference, not a finished production implementation. Teams can apply the same skills to their own repositories to generate architecture-specific decisions and backlogs. They should then validate every recommendation against the real product. In Contoso’s case, several records still refer to AI chat even though that feature has been removed from the current application, so related infrastructure, threats, meters, quotas, and SLOs are illustrative and must be revised before implementation. Example reports can be viewed here Exit condition: Critical security risks are resolved, tenant isolation tests pass, and evidence is ready for Marketplace certification.

6. Publish with marketplace-onboarding

The marketplace-onboarding and onboard-to-marketplace skills produced marketplace-onboarding.md, the final decision record in Contoso Outdoors’ SaaS journey. Earlier skills focused on architecture, tenant isolation, subscription processing, security, deployment, and operations. This record brings those outputs together and asks a different question: is the product ready to be configured, tested, certified, and sold through Microsoft’s commercial marketplace? The skill converts that question into a structured launch plan. It covers Partner Center account readiness, publisher verification, legal and financial setup, team roles, listing content, plans, prices, technical endpoints, marketing assets, private-preview testing, certification requirements, and go-live gates. It also links back to the earlier records so that claims made in the Marketplace listing can be traced to the proposed fulfillment, lifecycle, security, and deployment designs. For Contoso, the document proposes a transactable SaaS offer with public plans and technical integration through a landing page and Marketplace webhook. It identifies the tests required to prove the complete customer journey: purchase the offer, resolve the Marketplace token, activate the subscription, provision the tenant, grant storefront access, process plan changes, suspend and restore service, report any billable usage, and retain or remove data after cancellation. This turns onboarding from a form-filling exercise into an end-to-end product validation process. The private-preview stage is particularly important. Rather than publishing directly, Contoso would first restrict the offer to named test tenants and exercise each commercial lifecycle path in Partner Center. The resulting evidence supports certification and reveals failures that ordinary application testing may miss, such as an invalid landing-page response, webhook timeout, plan mismatch, broken privacy-policy link, or a subscription state that does not match the internal tenant record. For the reader, marketplace-onboarding.md acts as a release checklist for the commercial product, not merely the software. It makes clear that Marketplace readiness involves engineering, product management, finance, legal, design, support, and operations. Its blocking gate gives each team an owner and prevents submission while essential technical, legal, pricing, or payout requirements remain incomplete. Contoso remains a reusable reference rather than a submission-ready offer. The listed URLs, prices, plan names, certification status, and technical capabilities are proposals that must be verified. In particular, references to AI chat, AI metering, screenshots, and AI-oriented listing copy conflict with the current repository, where chat has been removed. Those items must be deleted or replaced before the listing can accurately represent the product. Used correctly, the record gives other SaaS teams a repeatable closing stage: The value of the skill is therefore not that it automatically publishes an offer. It transforms technical decisions from the rest of the SaaS workflow into a transparent, reviewable path from working platform to commercially operable Marketplace product. Example reports can be viewed here Exit condition: The offer passes certification, exits preview, and becomes publicly discoverable and purchasable in Azure Marketplace.

The Agentic path to Revenue

The content created with Git-Ape turns the journey from an existing Azure application to a transactable SaaS offer into explicit, version-controlled decisions. Rather than treating Marketplace onboarding as a publishing task, the Git-Ape skills connect commercial design, tenancy, platform engineering, subscription lifecycle, security, operations, and certification into one delivery path. The outputs for the Contoso example include:

• An offer-model assessment that selects a transactable SaaS offer as the target.
• A multi-tenant architecture assessment and staged implementation plan.
• Tenant-isolation and Azure landing-zone decision records.
• A Marketplace control-plane design covering the landing page, subscription records, webhooks, administration, and tenant lifecycle.
• Fulfilment, entitlement, and optional metering designs.
• Deployment, security, compliance, scale, reliability, and operational-readiness records.
• A Partner Centre onboarding and certification checklist.

These outputs are implementation blueprints, not proof that the platform is production ready. An ISV must validate each assumption against the real product, remove recommendations for capabilities it does not provide, assign owners, convert decisions into backlog items, and retain implementation evidence in the repository.

How an ISV should implement the recommendations

1. Confirm the product and commercial model

Define who the tenant is, who operates the service, what customers buy, and how access is licensed. Select a transactable SaaS offer when the ISV hosts and operates the application and wants Microsoft to manage the Marketplace transaction. Decide whether pricing will be flat-rate or per-user. Add custom meters only when there is a measurable, auditable usage dimension that the product can track and reconcile. Delivery gate: Offer type, pricing model, tenant definition, target markets, support model, and commercial owners are approved.

2. Establish the Azure platform foundation

Create separate development, test, and production environments with an agreed subscription and resource structure. Implement least-privilege access, managed identities, policy, tagging, private connectivity, secret management, monitoring, and cost controls. Represent the platform through reusable infrastructure-as-code modules and deploy it through reviewed pipelines. Delivery gate: The landing zone is deployable, policy-compliant, observable, and supported by a documented promotion and rollback process.

3. Implement tenant isolation

Introduce a trusted tenant registry and ensure tenant context is derived from authenticated identity, subscription mapping, or approved routing—not from untrusted request values. Apply that context to every API, data query, storage operation, background job, message, cache entry, and telemetry event. If using a hybrid isolation model, define the thresholds for moving high-demand or regulated tenants to stronger isolation. Delivery gate: Automated negative tests prove that one tenant cannot read, modify, enumerate, or influence another tenant’s data or workload.

4. Separate the control plane from the application plane

Keep Marketplace and administrative operations separate from the customer-facing workload. The control plane should own purchase resolution, subscription state, tenant provisioning, plans, entitlements, reconciliation, and operational administration. The application plane should enforce tenant and entitlement state while serving customer traffic. Map each Marketplace purchase to one internal subscription, tenant, plan, and entitlement record.

5. Implement the complete subscription lifecycle

Build the landing-page and activation flow, Marketplace webhook processing, activation, plan and seat changes, suspension, reinstatement, cancellation, retention, and deletion. Treat lifecycle processing as an asynchronous state machine with idempotency, retry handling, dead-letter processing, audit records, and periodic reconciliation between Marketplace and the ISV’s internal records. Microsoft requires SaaS publishers to keep subscription state aligned through these flows and webhooks. Delivery gate: Repeated or out-of-order events do not create duplicate tenants, incorrect entitlements, or incorrect access.

6. Add metering only where the product supports it

If the selected plan uses custom dimensions, maintain a source-of-truth usage ledger, aggregate usage according to Marketplace rules, and submit valid billable events. Include correlation identifiers, duplicate protection, late-event handling, exception queues, and financial reconciliation. Marketplace metering is an extension of a flat-rate SaaS plan and requires the ISV to track the usage it reports. Delivery gate: Every submitted charge can be traced to tenant activity, a pricing rule, an accepted Marketplace event, and a reconciliation record.

7. Operationalise security and reliability

Convert the security and SRE recommendations into controls, tests, dashboards, alerts, service-level objectives, backup and recovery procedures, capacity thresholds, and incident runbooks. Telemetry should expose both service-wide health and tenant-specific degradation. High-risk findings, failed isolation tests, missing recovery evidence, and unresolved certification blockers should prevent release. Delivery gate: A production-readiness review confirms security, privacy, resilience, support, cost ownership, and operational response.

8. Validate through a private preview

Configure the Partner Centre offer, listing, plans, legal links, technical endpoints, support details, and a private audience. Test the full customer journey using representative pilot tenants: purchase, activation, provisioning, access, plan change, suspension, reinstatement, optional metering, cancellation, retention, and deletion. A SaaS publisher remains responsible for its hosted infrastructure and the technical requirements of the selected listing model. Delivery gate: All end-to-end scenarios pass, certification evidence is complete, and engineering, product, security, operations, legal, finance, and support approve launch.

Recommended delivery operating model

The ISV should keep each Git-Ape output beside the application code as a living decision record. Every recommendation should be classified as accepted, adapted, deferred, or rejected, with an owner, rationale, target release, and validation method. Pull requests should update the relevant architecture record whenever an implementation changes a tenant boundary, entitlement rule, pricing assumption, security control, or operational threshold. Git-Ape provides the most value when it is used repeatedly at delivery gates, not only at project initiation. The skills should be rerun when the ISV adds a region, changes pricing, introduces a new usage dimension, adopts a different data store, changes its tenant-isolation model, or prepares a new Marketplace plan. This keeps the commercial promise, deployed platform, and operational evidence aligned.

Outcome

When implemented, the recommendations give an ISV more than a Marketplace listing: they create a controlled path from product intent to a secure, scalable, Microsoft-billed SaaS service. Git-Ape accelerates the decision and planning work; the ISV remains accountable for implementation, testing, evidence, certification, and reliable operation. If you want to build the changes then you can use the other skills within @git-ape to build out your solution…. But that’s another story for another blog.  
Post Updated on September 8, 2026 at 05:45AM
Thanks for reading
from devamazonaws.blogspot.com