Building a App Playground for Experimentation
How a shared scaffold lets the team ship tools outside the sprint queue
In January 2026, we launched apps.aampe.com.
A shared URL where anyone at Aampe, or any customer, can access purpose-built tools that don’t belong inside our core product. No separate logins. No sprint dependencies. No waiting.
Seven apps live there now — built by engineers, a researcher, and me, across teams and time zones.
Pain Depot to apps
We ran a weekly customer research process called Pain Depot. Themed VoC sessions, pain points logged, patterns surfaced. It was a good signal machine.
The problem was what happened after. Most pain points went into a doc. Some made it to a sprint pitch. Very few became anything.
Label Buddy came from repeated CS friction around managing the label system. Audience Coverage came from customers and CSMs not being able to see which audience segments their messages were missing. Neither was big enough for the sprint queue. Both were real enough to build.
Everything is at least two sprints away
At a small startup, every internal tool competes with product work for sprint slots. Most of the time, the small things lose.
We had a researcher who built a quality auditing prototype on his own time. A CSM who needed to test Surface configurations before deploying them to customers. A way to make customer email templates work with our AI system — it came up on every onboarding call.
None of these were product features. All of them were blockers. Getting anything built through the normal process meant a sprint pitch, a betting table, design, build, QA, release. Two sprints minimum. Often more.
apps.aampe.com was built to change that.
It started with a Figma plugin
Before apps.aampe.com, the team built a Figma plugin for designing Aampe Surfaces directly inside Figma. It was small. It did one thing. It talked directly to our APIs.
That pattern is what apps.aampe.com is built on: a purpose-built tool that speaks directly to the product’s API, with just enough UI to do the job.
What the platform actually is
Most internal tool efforts produce one-offs. apps.aampe.com was designed to compound.
Three layers do the work:
The first is standardized Aampe APIs. A consistent API surface across Composer, Surfaces, labels, formulas, audiences. Every app speaks the same language. New apps don’t need to reverse-engineer the backend — the contracts are already there.
The second is a shared design shell. One navigation, one auth layer, one visual framework. Each new app inherits it. The result is a coherent product feel across all seven apps without rebuilding UI from scratch each time.
The third is agent-ready scaffolding. The API layer and design shell together form a context that AI agents can use to generate new UI. Describe the problem. Claude Code generates an interface that already knows Aampe’s design patterns and connects to the right APIs.
[ Aampe APIs ] + [ Design Shell ] → [ Agent generates UI ] → [ Live on apps.aampe.com ]This is what separates it from a collection of Replit/Claude Code hacks. The standardization is intentional. Every subsequent app is faster to ship than the last. We called it a labs environment internally. A place for experiments that live outside the release cycle.
The test that proved it
In December 2025, we shipped the Email Variable Configurator.
The problem: customers had email templates in Braze or Salesforce but couldn’t get them into Aampe’s personalization layer. CS was walking through it manually on every onboarding call.
Through the normal process: at least two sprints away.
Through apps.aampe.com: v1 was built and deployed. Peter Yoon (CSM) used it with a customer the same week, live, on a real onboarding.
Peter sent feedback via Loom. A CSS bug, a header styling regression, a file size display the customer had mentioned in passing. All of it was in and redeployed within the same sprint.
Concept to live customer use to fix to redeploy. One sprint. No betting table.
What gets built when the scaffold exists
Label Buddy is a good example of what the platform unlocks.
At Aampe, one agent is assigned per end user. Those agents learn from labels — the taxonomy on every message. If the labels are wrong, the agents learn the wrong thing. At 100k+ message combinations per customer per day, that compounds fast. There was no tooling to catch it. A content person would spend a full week on manual matching every time a new customer onboarded.
Label Buddy is a semantic validation tool that processes a 140k row CSV in under an hour for about a dollar. Not because of AI — Jaccard similarity, SHA-256 deduplication, and rules-based filtering handle most of the work before the LLM ever sees a row.
It never shipped publicly. It also never stopped being used.
I spoke about it at GitLab’s The Other Interface in Bangalore — the talk was called “3 Sprints Away.” The point wasn’t the tool. It was the design work that lives between a broken customer experience and an engineering fix. The stuff that calls the shots without ever being in the demo.
What’s live
Relay: LLM-powered copy generation for push and email. Originated by Schaun Wheeler, productised with Rajat Goyal and Madhuri to ~95% first-pass copy quality.
Resolve: AI quality auditing for Composer messages. Built by Schaun Wheeler.
Email Variable Configurator: converts customer HTML templates into agentic-ready format.
Surface Figma Plugin: design Aampe Surfaces inside Figma. Built by Tammo and Shashank.
Surface Template Builder: define and test Surface templates via live API. Built with Arav Batra.
Label Buddy: semantic label validation at scale. Built in Replit with Claude Code.
Audience Coverage: visualize message coverage gaps across audiences. Built with Kalyan Cahill (Forward Deployed Engineer) in Replit with Claude Code.
apps.aampe.com is now a menu item in Composer’s main navigation. What started as a side experiment is part of the official product surface.
Why this matters for the team
The platform exists so anyone can ship. If you have a pain point that keeps coming up in CS calls, a tool that would save a customer a week of manual work, or an experiment that doesn’t fit the sprint queue — apps.aampe.com is the place for it.
The scaffold is there. The APIs are documented. The design patterns are set. You don’t need to be an engineer. You need a clear problem and a willingness to build against real data.
The vibe-coding part works because the context is solid. An agent generating UI on top of a documented API with established design patterns is different from asking AI to build something from scratch.
The scaffold quality determines what gets built on it.
Thanks for reading!