A member of our Customer Success team built an internal client health tracking application using Codex and Mapp Labs. They’re not an engineer. And while I built much of the technical foundation underneath it, I had very little involvement in the application itself.

When they ran into problems accessing customer data in Salesforce, DealHub, and SharePoint, they found people who could help with those systems and their APIs. The application went into heavy internal use without becoming a Product and Engineering project.

That’s the kind of independence I wanted when I built the Mapp Labs application template. The person doing the work could start building and figuring out what they needed, while relying on authentication, internal APIs, deployment patterns, and security practices that Engineering had already established.

AI coding agents make writing an application easier. Making that application work within the rest of an enterprise is a different problem. That’s the part we set out to address with Mapp Labs.

It Started With a Customer Onboarding Portal

Mapp Labs started with a solutions architect who needed a better way to support customers through the onboarding process.

Mapp delivers multiple enterprise products. As a result, customer onboardings often involve coordination between several internal teams and several external teams on the customer side. Everyone needs to know dependencies, what’s been completed, what’s coming next, and when access to different systems becomes available. The portal was intended to track those steps, keep everyone informed, and send updates when necessary.

Engineering couldn’t prioritize building it, and the solutions architects and other commercial teams couldn’t keep waiting.

So he built a system with AI and asked me to make sure he’d approached everything in a sane fashion. I showed him a bit about database indexes, DRY code, and how boilerplates and service templates could work as reusable starting points for building standardized software. I’d already used similar ideas in more traditional engineering environments with microservices, where repeatable conventions make it easier to build and deploy consistent applications. So I figured it would work well here too.

Once I got into the meat of what he was building, I realized a full application template could solve a much larger problem. So I asked him to segment out the portal and template code and then I took over ownership of the template.

I started generalizing it, adding the things that an experienced engineer would normally consider when starting a new application: database organization and indexing, API conventions, authentication, authorization, code organization, design standards, deployment patterns, logging, monitoring, and documentation. And critically, tied it all in to our internal systems like our user management and customer catalog.

This was still early days for AI-assisted application development, and the agents needed considerably more guidance than they do now. I’ve spent nearly three decades working across software engineering, Product Management, and DevOps. That’s how I knew which decisions and practices were worth standardizing instead of leaving every builder and agent to figure them out independently.

New customers still use the original onboarding portal today, largely unchanged. The template we pulled out of it has since become the starting point for dozens of other applications.

Engineering capacity and prioritization were the immediate problems around building the customer portal. But I saw a bigger opportunity: let the people closest to a problem build something to help them understand and solve it.

People don’t always know exactly what they need when they start trying to build something. But they usually know what’s frustrating, what isn’t working, and what they’d like to change. Traditionally, they’d explain that to Product, who would work with Engineering to turn it into software. That’s a lot of translation for a problem the original person might not yet fully understand. The alternative was often buying something from a vendor, going through procurement, configuring it, and paying for capabilities they might never use.

I wanted people to be able to build something tied into our internal systems, see where their assumptions were wrong, change it, and try again. And I wanted them to do that while using the infrastructure and engineering practices we’d already established at Mapp.

I also didn’t want everyone building disconnected applications on Vercel, Lovable, Bolt, or arbitrary AWS accounts. Vercel has since announced enterprise tooling for this kind of platform work. But whichever platform we ended up using, we would still have to connect applications to Mapp’s identity infrastructure, customer catalogs, and APIs, and meet our compliance and security requirements.

We’d already built most of those capabilities. The challenge was making them available to people who didn’t know how our infrastructure worked.

Michael Diestelberg has written about the product thinking behind the Mapp Labs innovation program. I want to focus here on the engineering foundation that made it possible.

What We Actually Built

Mapp Labs combines a working application template, instructions written for coding agents, access to our shared infrastructure, and the processes for maintaining the applications built from it.

The starting point is a template repository containing a working application built with Next.js, React, TypeScript, Prisma, and PostgreSQL. It includes application structure, an admin interface, customer-facing components, design standards, authentication, authorization helpers, and infrastructure definitions.

Each builder gets their own application and repository, rather than adding features to a shared application and creating another monolith. That was a design decision I made around how I wanted to manage complexity and there are clearly pros and cons here. And since I don’t know what people are going to build, I don’t want them or their agents constrained by a common codebase or having to understand pull requests and development workflows just to experiment.

Their agents can modify the application however they need. If they want to connect to Redshift, add AWS services like Lambda or EventBridge, or split the application into separate frontend and backend services, they can do that without coupling their code and releases to everyone else’s.

What they inherit is the engineering foundation: how we organize code and infrastructure, handle authentication, deploy applications, manage configuration, and document decisions. They don’t have to start from scratch, but they also don’t have to keep the application or the repository looking exactly like the original template.

The repo also contains deployment scripts, setup instructions, and documentation for coding agents. The documentation tells agents which engineering patterns, testing practices, and compliance requirements to follow. It also helps the agent explain those requirements to builders in terms they can understand, and walk them through steps they might not even know need to be done.

An agent working inside a Labs application can read instructions about how to use existing services, where to find configuration, how to deploy, what resources it’s allowed to modify, and what security conventions it should follow.

The instructions in AGENTS.md also tell the agent to document more than what it built. I want it to record what was tried, why it was tried, what didn’t work, and what changed as lessons were learned. If we throw an approach away, that should be documented too.

Someone can understand a customer problem quite well without having learned the habits of a PM, like recording what they tried and why they changed direction. I want the agent capturing as much of that history as possible while they work, rather than leaving us with only the “final” version of the code that survived.

We use a consistent documentation structure across the repositories. That means another engineer or agent has a predictable place to find the reasoning behind an implementation, not just the final code. It’s also useful when we evaluate whether an experimental application is ready to become part of our regular product offering.

Don’t Reinvent the Wheel

Let’s take authentication as an example.

Mapp uses Keycloak, integrated with our existing identity systems and supporting the federation and other security standards our enterprise customers require. Supporting internal employees and external customers requires different identity and authorization behavior anyway. The application simply needs to understand who someone is, which accounts or companies they belong to, and what they’re allowed to do.

A builder doesn’t need to understand the implementation of Keycloak or the details of the underlying identity infrastructure.

They can ask their agent to determine whether a user should have access to an account, and the agent has existing code, interfaces, and documentation showing how to make that determination.

That doesn’t mean every authorization decision is automatic. The application still needs to implement the correct access rules, and specialized cases may require engineering review. Some apps may even require more granular access rules and controls than what our centralized authorization system already provides.

I don’t want anyone designing an identity system from scratch.

The same idea applies to internal APIs, customer and workspace information, product feeds, application storage, and other capabilities. Some are general engineering services. Others, like our unified product catalog, represent years of work understanding the specific problems our products solve.

These aren’t capabilities that appeared when we created Mapp Labs. Engineering had already built and maintained them as part of our existing products and infrastructure.

But not every capability is ready to use out of the box. The template includes working integrations, optional modules, and examples that agents still have to adapt for a particular application. A few are incomplete and will be updated in a future retrofit.

This works in the other direction too. When any Labs application exposes an API, they all start from the same Swagger/OpenAPI setup, with documentation in predictable and consistent locations. The instructions tell agents to keep it that way. Nothing enforces it technically, but it gives other agents a familiar place to look.

A builder doesn’t need an API to have been registered in the original template. They can tell their agent, “This application has the data I need,” and give it access to the URL or repository. The agent can read the current endpoint definitions and figure out how to integrate.

Humans still have coordination to do. Someone may need to ask another builder to expose some data in a specific way, agree on how the API should behave, or get the API key needed to access that app. The agents can implement the result, but they don’t remove all conversation.

We’ve already had API changes break other applications. I’ve since added guidance for the agents about deprecating endpoints and documenting changes. I still think the flexibility is worth that risk for now. But those dependencies don’t end up managing themselves.

Deployment is Part of the Foundation

Builders also inherit a standard deployment approach inside our AWS infrastructure.

Applications have separate staging and production environments, standard resource definitions, database configuration, container deployment, identity integration, and conventions for configuration and secrets.

The deployment system uses AWS CDK and scripts that agents can run on behalf of builders. It’s still largely a scripted deployment process initiated from a builder’s development machine, rather than a centrally managed CI/CD system.

Infrastructure is tagged with information about the application, owner, team, product, and environment. That gives us a common way to identify resources, track ownership, and attribute infrastructure costs.

LLM functionality goes through our LiteLLM proxy infrastructure, allowing us to manage model access and attribute spending to applications, features, products, and customers. We can also route requests to different models automatically where it makes sense.

On the back side, Labs applications are integrated into the same OpenMeter-based usage metering infrastructure used elsewhere in our products.

That’s different from AWS cost tracking. One tells us what infrastructure costs us. The other tells us what customers are using, including usage that may need to be billed through our Finance systems.

Billing, like authentication, authorization, and identity management, is another place I really don’t want every builder or their agent improvising. If we’re charging a customer for usage, we need to be able to show what they used and why they’re being billed. We already have a metering infrastructure for that, so it needs to be available to Labs applications too.

I’ve included a much more complete technical inventory for the operationally-minded at the end, because there’s considerably more involved than a template and a few deployment scripts.

GETTING_STARTED.md

A new builder starts in Notion.

We have instructions explaining how to get access to GitHub, obtain the Mapp Labs template repository, and set up a development environment. The page includes a prompt they can give to Codex, Claude Code, or another agent, telling it to read the Getting Started instructions.

The agent walks them through the setup at whatever level of complexity they feel comfortable at.

There are still prerequisites, including access to the appropriate AWS environment and any credentials their application needs, which they still need to request through IT for compliance reasons. But much of the local setup, configuration, and deployment work is handled by the agent following existing instructions contained within the repo documentation.

From there, the builder can ask for features, screens, integrations, or new data structures. The agent has our design conventions, API documentation, and capability registry to work from, so it can use existing patterns rather than inventing a new approach every time.

The builder can work locally, deploy to staging, test the application, make changes, and eventually deploy to production.

Deploying an application doesn’t transfer responsibility to Engineering. The builder still owns it, including subsequent changes and maintenance. When something breaks, they’re usually the first person to investigate, often with their agent. If they can’t resolve it themselves, they ask in the Labs support channel or raise a support ticket.

We’ve already transferred applications between owners this way. It’s mostly updating GitHub access, documentation, and AWS ownership metadata.

That doesn’t mean builders are on their own. They still get stuck, and they still need people who know more than they do to help them get unstuck or guide them.

Support Is Part of the System

We have a dedicated Slack support channel for Labs builders.

People ask questions when their agents encounter something they don’t understand, when they need access to an unfamiliar system, or when they (or their agent) suspect the template has a bug.

Most support requests don’t require changes to the template. Sometimes someone just needs help understanding an API, getting access to a system, or figuring out why their agent is stuck.

When the problem is a defect or a missing reusable capability, we can fix it centrally rather than having every builder discover and solve the same issue independently (and potentially incorrectly).

I don’t want every support request coming through me. People across Engineering and the rest of the company can help directly. And when the same problem keeps appearing, the Slack channel helps us recognize that we should improve the foundation rather than keep helping people work around it.

I still do most of the template maintenance myself (mostly because I enjoy it). But there are plenty of other folks who also contribute. Our designers have worked on the design system, platform engineers have helped with Keycloak (authn/authz), DevOps folks have helped with the AWS infrastructure and networking, and engineers responsible for individual services have contributed integrations and documentation.

Those contributions go back into the template repository. The decisions, implementation details, and instructions are available to whoever works on the system next.

If I stopped maintaining the template tomorrow, another experienced engineer could pick it up. The system shouldn’t depend on everything staying in my head.

What People Are Building

As of today, we have roughly 50 applications built from the foundation and around 45 builders in a company with fewer than 250 employees.

They aren’t all engineers. Builders include Product Managers, Solutions Architects, Customer Success, Technical Support, Marketing, Compliance, and company executive leadership.

The applications range from small internal utilities to substantial systems used in everyday operations or built for customers.

The client health application I mentioned earlier replaced the parts of Gainsight we needed. I still think Gainsight is the gold standard for customer success management platforms, but properly configuring and operating it would have required more time, money, and dedicated attention than we had. What our team built does considerably less, and that’s fine. It does what they need and is customized to our needs.

Our compliance team has built its own tracking systems, led by people without conventional engineering backgrounds. A non-technical product manager has led development of an application around usage information and our metering infrastructure. A solutions architect built a Returns Intelligence platform that customers have already seen and can authenticate into.

This is especially useful at Mapp because we have several enterprise products, not one single-purpose application. They contain years of business logic, configuration, and capabilities that can be used together in ways we didn’t necessarily plan for.

Labs gives us room to combine those capabilities for a specific customer, or test a different way of using an established product without modifying its core code every time someone has an idea.

One application I’m particularly close to is CGS, Mapp’s Commerce Graph Studio.

Mapp Fashion, one of our main products, grew from a Rails application that has been developed for over a decade. Our fashion taxonomy is an important asset, but understanding, managing, and changing it wasn’t easy.

I initially built CGS because I was trying to understand the taxonomy better: how it was structured, where the gaps were, and what happened when I started visualizing and changing it.

I didn’t have a complete understanding of what the application needed to become. Building it was part of figuring that out.

It has since grown far beyond the initial exploration. Engineers, product managers, designers, and even commercial folks have contributed to it. It now supports a number of Mapp Fashion capabilities and continues to grow almost daily.

CGS also provides API access to the taxonomy and several other core Fashion capabilities. When another builder needs that data, they can request an API key themselves and point their agent at CGS’s Swagger docs. They don’t have to figure out the systems underneath the taxonomy or rebuild that integration on their own.

Labs lets us explore opportunities like these without making every idea a core product initiative. Some applications remain standalone. Others eventually become capabilities in our existing products.

Many of these ideas would never have reached our standard roadmap. They’re not necessarily important enough to displace committed core product work, but that doesn’t mean they aren’t worth building. Even our roadmap tracking system is built on a Mapp Labs application.

Engineers use Labs for experimentation too. They can build a capability outside the core system, see how it works, and bring the useful parts back into the product.

Getting something working can also show us that the idea isn’t worth pursuing, or that we misunderstood the problem in the first place.

If we throw that implementation away after learning something useful, it did its job. We didn’t have to spend weeks or months building out an assumption that turned out to be wrong. And because the agent wrote down what we tried and why it didn’t work, we can keep the learnings even after the code is gone.

Keeping #allthethings Maintainable

There’s a (not so hidden) cost to letting applications evolve independently.

Every application begins as a copy of the template. Once someone starts modifying it, it’s their application, with its own code, dependencies, decisions, and release history.

That independence is useful. It also creates a potential maintenance nightmare.

If the original template contains a defect or vulnerability, every application descended from it may inherit the same problem.

This is a bit like asexual reproduction in biology. Shared ancestry can distribute useful traits, but it can also distribute weaknesses. Applications subsequently diverge, so some may no longer contain a particular weakness while others remain vulnerable.

Fixing the template doesn’t automatically fix the applications.

We built a distributed retrofit system to deal with this.

Since it’s an app that I primarily maintain, I use CGS as an early testing ground for changes to the foundation, particularly around authentication, authorization, and compliance. It helps me catch problems before distributing the retrofit instructions more broadly.

But CGS has its own code and history. Just because it works there, isn’t a guarantee that the same change will work in every other application. Though it’s a useful starting point and why I keep CGS as a guinea pig.

When something important gets changed, we document what changed and provide instructions that builders can give to their coding agents. I want to make it as easy as possible for everyone to stay current. Builders are typically notified through Slack when updates exist and need their attention.

The retrofit instructions are deliberately not just a collection of code changes for the agents to copy. Each retrofit describes the problem, how to detect it, what a correct solution needs to guarantee, and some example code to help if that’s necessary.

The builder’s agent still has to examine the application it’s working on. If that application has diverged from the template around this update, it may have already solved the problem differently. Blindly copying the template’s implementation could introduce new problems or break something that already works.

What matters is whether the application still has the original problem, not whether its code looks exactly like the template. And if the problem still exists (or has been solved), then the retrofit system just asks the agent to ensure the “correct” outcome has been reached.

Finally, the retrofit system records which updates have been applied, which are partial, and which aren’t applicable. We have a growing library of migration records and dedicated retrofit instructions that sit in the repository for tracking.

Knowing What Exists: Inventory and Oversight

With this many independent applications, we also need to know what exists, who owns it, and how far each application has diverged from the template.

We’ve intentionally standardized where that information lives. Application configuration identifies the owner, team, and enabled capabilities. AWS resources are tagged, and retrofit and compliance information is recorded in JSON files within the repositories.

That standardized documentation also gives our fleet tools and agents a common place to start when inspecting applications. They can look at documented capabilities, implementation decisions, and the reasoning behind changes before digging through the code.

It doesn’t replace code inspection when something that specific is required. But it does mean we don’t always have to reverse-engineer an application to understand what someone was trying to accomplish.

Our fleet tracking system is already deployed, although its use is still fairly limited. It scans AWS and GitHub nightly to collect information. This gives us a way to track the applications without depending entirely on individual builders reporting their status or applications having to check in.

Our compliance team operates other apps that inspect repositories and dependencies. This includes integrations with security analysis tools like Sonar. Because the applications follow common conventions, those tools can collect the information they need without every builder implementing their own reporting and scanning, or having to learn how to integrate into CI systems.

When we discover a problem in the template, we need to know which applications might still have that problem and who is responsible for fixing it if it still exists. The common metadata and retrofit JSON records make that possible, even as the applications continue to diverge.

I use the fleet management system to identify outstanding retrofits and follow up with the application owners. If a required fix still isn’t applied after “too long”, I shut the application down. Admittedly this is a last resort and not the way I want interactions to go.

Independence Still Has Boundaries

We’ve deliberately given builders a wide berth. It’s the kind of culture of trust I want to have at Mapp.

They can make architectural and product choices, introduce integrations, and deploy applications without asking an engineer to approve every change.

That also comes with a whole lot of inherent risk that is mine to accept as the CTO.

Labs apps run in a separate AWS account. This account comes with network boundaries between it and our existing production systems. The connections into Mapp’s internal infrastructure are built and maintained by experienced engineers and DevOps people, including me.

Within Labs, some deployment permissions are still broader than I’d like. We’ve deliberately allowed builders to (have their agents) add infrastructure without having to ask our Infrastructure team to provision every service for them. That freedom isn’t ideal, but for now it’s a tradeoff I’m willing to make. And part of allowing that freedom requires staying on top of costs.

From an encapsulation perspective, the agents are instructed to keep infrastructure changes within their application’s own CloudFormation stack wherever possible, rather than modifying shared resources or infrastructure belonging to other applications. Better agents, as they arrive, may make fewer mistakes. But those instructions passed in the documentation aren’t a security boundary. We’re still working on finding the right balance between safety and tightening the technical enforcement of those guardrails.

I never intended the whole system to be fully automated. Some controls are enforced in code, some are instructions for the agent, and others require someone to make a judgment. I think there’s value in keeping builders involved, even if their involvement is limited. I’m not expecting someone without an engineering background to understand every technical decision or review a patch to identity and access management. But I do want their agent to explain what was wrong, what it changed, and why.

Even if the builder only understands part of that explanation, they’re being exposed to the kinds of problems and decisions involved in maintaining software. Over time, they start recognizing terminology, seeing patterns, and hopefully asking better questions. That’s how they can start building some judgment about their application, even if they’re not writing or reviewing the code themselves.

But none of that replaces an experienced engineering review or technical controls. I’d rather have builders progressively learning a little from each change than simply pressing a button and hoping everything works.

I don’t want to stop someone from prototyping an idea simply because it might eventually need to handle sensitive data or operate at significant scale. They can investigate the idea with appropriate test data. It’s also pretty easy to create properly shaped test data with AI.

But putting that application in front of customers and manipulating live data is a different decision. That’s when I want experienced engineering judgment applied to the data handling, security, and scaling requirements, rather than relying on the builder and their agent to recognize every potential problem.

A lot of our traditional security and compliance controls were designed around applications passing through Engineering’s SDLC. With Labs, that isn’t how software gets built. The industry is more broadly moving away from that model whether anyone likes it or not. So we’ve been moving those checks into the template and the instructions agents follow, allowing them to be applied regardless of who builds the application.

Customer-facing Labs applications have a mandatory review before they’re made available to customers as part of the graduation criteria. It’s documented in our ISO policies. Sometimes our compliance team does a good chunk of the review, but I still look over their findings and make the final call. I’m ultimately accountable for the decision and so far it hasn’t created a bottleneck.

I generally have the builder deploy the application to their production environment first. I click through it to see how it behaves and what goals they are trying to achieve. Then I pull down the repository and inspect it with an agent. We work through security, authorization, dependencies, data handling, compliance, and whatever else the application suggests we should examine. When something looks like a potential scaling or sensitive-data problem, I dig further and involve the relevant engineers.

The deployment scripts don’t technically enforce that review. It’s an organizational requirement. And just because you can deploy, doesn’t automatically mean you can and should let a customer use it.

Every time I discover a new question worth asking or a problem we hadn’t anticipated, I add it to the template’s compliance and tracking instructions. That way, the next builder’s agent can catch it earlier, and another experienced engineer can begin working from the same standardized set of checks.

I don’t want every future review to depend on me remembering the right questions. The more of that judgment we can capture in the system, the less we have to rediscover every time someone wants to put something in front of a customer.

When a Labs application goes in front of customers, I help set up basic monitoring and alerting, generally on an 8×5 basis. If an application graduates into our regular production operating model, our infrastructure team brings it into the existing monitoring and on-call processes for our standard (much higher) SLAs and uptime requirements.

Those are different levels of operational commitment, with different SLAs, SLOs, and contractual expectations. Deploying an application to a production environment doesn’t mean we’ve committed to operating it like one of our core SaaS products with the relevant 9’s.

Enabling Everyone to Innovate

I think more CTOs should be doing some version of this. You can build it yourself, use something like Vercel, or start with the infrastructure you already have. The specific technology matters less than making the capabilities your engineers have spent years building, available to more people across the company.

That includes engineers themselves. They can maintain the foundation, build reusable capabilities for everyone else, or use the same tools to experiment with problems they’re close to. When they understand the company’s strategy and goals, there’s no reason they shouldn’t be building and testing ideas in the same way the rest of the company is pursuing innovation.

This hasn’t reduced the amount of work Engineering does, and that was never a goal. There’s always pressure to read something like this as a reason to cut engineering headcount. That’s not what this is. What this can change, is where some of that Engineering work goes. Instead of implementing every application, engineers can make it possible for dozens of other people to build independently with more of the capabilities of the internal systems accessible to them.

And that makes their decisions more consequential. When fifty applications inherit an authentication pattern, getting that pattern right matters a lot more. The same goes for deployment, security, and access to internal systems. Engineering still needs to build and maintain those foundations, help when people get stuck, and step in when something requires deeper expertise.

There are still plenty of tradeoffs being made. Independent applications diverge, APIs break, and maintaining all of this introduces problems that we as technology leaders didn’t have before.

But what interests me most is how much more of the company can participate in figuring out what we should build and actually building it. People who understand a customer problem or see something that isn’t working, can test an idea without requiring Product and Engineering to prioritize it first. And our engineers can spend more of their time making that possible, while still building and testing ideas of their own.

The first obstacle to understanding a problem shouldn’t be getting your first guess at a solution onto a Product and Engineering roadmap.

---

Addendum: What’s Actually Included in Mapp Labs

Technical inventory, October 2026. This is a snapshot of an evolving system. Some capabilities are standard, some are optional or require application-specific work, and others are provided by shared services or separate applications.

Application foundation

• Application framework: Next.js 16, React 19, TypeScript, Node.js, and a modular application structure.
• Database foundation: PostgreSQL, Prisma, schema conventions, migration tooling, indexes, and common data access patterns.
• UI foundation: Tailwind-based design system, reusable components, branding, navigation, forms, tables, dialogs, and administrative views.
• Repository setup: Scripts for initializing a new application, naming it, recording ownership information, establishing configuration, and creating its own Git history.
• Agent documentation: AGENTS.md, GETTING_STARTED.md, architecture conventions, deployment instructions, known pitfalls, and application-specific documentation expectations.
• Capability registry: Machine-readable definitions describing available capabilities, dependencies, required configuration, implementation references, and agent instructions.
• Testing and code quality: Jest tests, database tests, ESLint, and specific checks for common authorization errors. The template does not provide a universal CI/CD pipeline.

Identity, authorization, and security

• Employee authentication: Keycloak integration with Entra identity brokering and existing Mapp identity information.
• Customer authentication: Optional company login with customer identity and account context. Application-specific eligibility checks must be configured.
• Session management: Server-side session storage, token handling, session expiration, and single sign-out behavior.
• Local authentication: Development-only authentication for testing without relying on the production identity flow.
• Application roles: Viewer, editor, and administrator permission conventions, together with server-side authorization helpers.
• Customer access controls: Account and tenant scoping helpers, membership checks, and application-specific permission handling.
• Customer preview: Optional read-only administrative access to customer views, with audit-related behavior.
• Service-to-service authentication: OAuth credentials and reusable clients for communicating with existing internal services.
• API authentication: Optional Keycloak bearer-token support and building blocks for authenticated public APIs.
• Audit logging: Data structures, administrative views, and helper functions for recording consequential changes. Applications must add logging where their own behavior requires it.
• Customer activity: Application activity and page-event recording.
• Security helpers: HTTP security headers, redirect validation, safer search patterns, private API caching conventions, environment validation, and access-controlled file handling.
• Compliance guidance: Agent-readable checks for secrets, authentication, authorization, sensitive data, vulnerabilities, external services, auditability, and privacy requirements. Several checks require human judgment; the checklist is not a hard deployment gate.

Existing enterprise integrations

• Customer and workspace information: Clients for Mapp’s internal company-management services.
• Product catalogs and feeds: Access to existing product-feed services, product attributes, and related customer data.
• Shared credentials: AWS SSM conventions for retrieving configuration and access to internal services.
• Internal networking: Connectivity to relevant internal services through shared infrastructure.
• Mapp Engage: Existing API integration for messaging and related functionality, including legacy magic-link email support.
• File storage: S3-based file and image storage, access rules, image conversion, and presigned URLs.
• SFTP: Optional file exchange functionality with connection and path-safety conventions.
• Public APIs: Optional API-key authentication, OpenAPI generation, documentation, and reusable route conventions. Application-specific routes and data models must still be implemented.
• Notion feedback: Reusable feedback integration with supporting code and optional interface scaffolds.
• Other integrations: Documentation, shared services, and application-specific implementations for additional systems. Salesforce, DealHub, SharePoint, Slack, and other integrations are not all automatic built-in capabilities.
• Cross-environment data synchronization: Infrastructure and example scripts for selected data movement between environments. This is not universally configured in every application.

LLM infrastructure

• LiteLLM integration: Shared proxy for model access rather than separate direct provider integrations in each application.
• Keys and budgets: Provisioned access and per-key spending limits.
• Usage attribution: Metadata associating model requests with applications, environments, features, users, and where relevant customers.
• Model configuration: Shared client patterns and supported model definitions.
• Data-handling instructions: Guidance on sensitive data and the information that may be passed to AI systems.

AWS infrastructure and deployment

• Infrastructure as code: AWS CDK definitions for application infrastructure.
• Application compute: ECS Fargate and containerized applications.
• Database hosting: Per-application RDS PostgreSQL resources.
• Container images: ECR repositories and image build/deployment scripts.
• Networking: Shared VPCs, environment-specific networking, and connectivity to internal company services.
• Public routing: Application load balancers, TLS certificates, Route53 DNS, and standard application domains.
• Configuration: Per-application and shared SSM namespaces, along with AWS Secrets Manager where appropriate.
• Staging and production: Separate environment configurations with different data, resources, and internal service connections.
• Deployment commands: First deployment, routine deployment, infrastructure updates, database migrations, and maintenance deployment procedures.
• Identity registration: Automated Keycloak redirect configuration as part of deployment.
• Resource attribution: AWS tags for application, owner, creator, team, product, and environment.
• Infrastructure cost reporting: Cost allocation using tags and supporting reporting tools. Reporting is not fully automated in the baseline.
• Deployment limitations: Broad shared deployer permissions remain, and not all production safeguards are enforced by infrastructure.

Monitoring, usage, and operations

• Application logging: CloudWatch integration and application logging conventions.
• Infrastructure monitoring: ECS and AWS monitoring capabilities, with Icinga health-check integration that requires setup and activation.
• Application health: Standard health endpoints and deployment health checks.
• Application-level audit and activity information: Reusable data structures and helpers, with coverage dependent on application implementation.
• Infrastructure cost attribution: Reporting based on AWS resource metadata.
• LLM cost attribution: LiteLLM spending information by application, feature, and customer context where provided.
• Customer usage metering: An existing UI connected to Mapp’s OpenMeter-based usage infrastructure.
• Standardized metering export: Automated daily ECS tasks producing per-application CSV usage records in S3 for ingestion into OpenMeter.
• Operational ownership: Repository metadata, application ownership tags, team attribution, and documentation that supports maintenance and transfer of responsibility.

Fleet management, maintenance, and retrofits

• Independent applications: Each application starts as a copy of the template and develops its own code and release history.
• Template versioning: Versioned baseline releases and migration records describing changes.
• Retrofit instructions: Dedicated prompts for coding agents to assess and implement changes in existing applications.
• Behavior-based retrofit checks: Rules describing the required result, detection steps, sample implementations, tests, and application-specific decisions.
• Retrofit state: .retrofit-state.json records applied, partial, skipped, pending, or inapplicable changes, as well as relevant metadata.
• Retrofit coordination: Builder notifications and support through Slack.
• Fleet overview: A deployed application that scans GitHub and AWS nightly for application, environment, ownership, and retrofit information. I use it to identify outstanding retrofits and follow up with owners, although the broader fleet management tooling is still being developed.
• Security and compliance tooling: Separate applications used by the compliance team to inspect repositories and dependencies, including integrations with tools such as Sonar.
• SBOM and licensing visibility: Handled through separate scanning applications rather than as universal built-in template functions.
• Vulnerability response: Template fixes, dependency reviews, documented migrations, and retrofit instructions for existing applications.
• Application ownership transfer: GitHub access, application documentation, and AWS resource metadata provide the mechanisms for transferring maintenance responsibility.
• Customer-facing review: Mandatory review before customer exposure, with Compliance, Security, or Engineering involvement as needed and final approval from the CTO.
• Innovation agreements: Separate contractual commitments for relevant customer-facing experimental applications.