Product Design
Mesh Communities
Bild App Manager
App Manager was the admin platform behind Mesh Communities' white-labeled app product. Mesh let organizations launch their own branded mobile app, and Mesh App Manager was the control surface that let the people running those apps (creators and admins were the same role in Mesh's ecosystem) configure everything about them without filing a developer request. BILD, a bodybuilding community and one of Mesh's white-labeled clients, is the branded example that appears throughout the file's mockups.
My role
Lead Product Designer
Company
Mesh Communities
Timeline
June 2023 - June 2024
Outcome
[ Project hero image ]
Overview
A platform built to give admins their time back
Mesh App Manager was the admin platform behind Mesh Communities' white-labeled app product. Mesh let organizations launch their own branded mobile app, and Mesh App Manager was the control surface that let the people running those apps, creators and admins were the same role in Mesh's ecosystem, configure everything about them without filing a developer request. BILD, a bodybuilding community and one of Mesh's white-labeled clients, is the branded example that appears throughout the file's mockups.
The problem
Every small change created a big bottleneck
The original brief wasn't for an admin panel at all, it was for a mobile-first analytics dashboard, scoped to ship before the white-labeled apps even launched. That plan got deprioritized, and when the apps shipped, the real gap showed up immediately: every organization running one needed to configure it, brand it, price it, and maintain it, with no self-serve path for any of it.
No self-serve editing
Store info and brand assets, the app's core identity, needed a developer to touch for anything: a logo swap, an about-page edit, a new banner. There was no path for an admin to make that change themselves, no matter how small it was.
Developers were bottlenecked
Categories, attributes, and node-level visuals each needed their own configuration, and none of it was exposed to admins. Setting images, defining its attributes, adjusting how they were categorized: all of it had to be filed via ticket and built by hand.
No visibility status
Subscription pricing, the in-app purchase toggle, invoices, itemized receipts, payment methods: none of it lived anywhere an admin could see or act on. Even knowing what a plan would cost meant asking, not calculating it themselves.
High error rate on handoffs
Attribute validation failures, oversized file uploads, and permission conflicts: none of it had a designed response. When something went wrong, an admin had no way to know why or whether the fix was even something they were allowed to make.
Context
Getting into the admin's world
Mesh's white-labeled apps were built to launch before the tooling to run them existed, so the original plan was designed for a product that wasn't fully real yet: a lightweight analytics dashboard a creator could check between posts, built around monetization and engagement rather than administration. An overview on login, a running list of past brand campaigns, a way to apply for new ones, a feed of what had been posted, a member list. Nothing in it assumed anyone would need to configure the app itself, because at that point, nobody had to yet.
Artifact
Journey map tracing the admin experience from identifying a change needed to seeing it go live, surfacing exactly where the process broke down and what it cost in time and confidence.
That assumption broke the moment the apps actually went live. Someone had to run each one, and running it meant configuring it, not just watching its numbers: BILD and the other white-labeled communities needed their branding set, their pricing decided, their categories and content organized, on an ongoing basis, not just at launch. The person doing that was usually the same creator, wearing a different hat, and often responsible for more than one branded app at once rather than just their own. The product had to account for that before anything else: an admin logging in might control two instances or a dozen, and the login flow itself had to sort out which before the rest of the console could open. That's the real shift this project tracks, a dashboard for checking your own numbers becoming a console for operating someone else's business on your behalf, pricing, permissions, and all.
“
It's my app. I should be able to change the logo without filing a ticket.
Process
Designing for confidence, not just capability
From March through June 2024, work on the admin platform moved at close to a weekly cadence, roughly four months of steady iteration rather than a single settings screen shipped once. That pace is its own signal: this was an admin surface built section by section, as the scope of "self-serve configuration" kept turning out to be bigger than it first looked.
01
Mapping the configuration space
The information architecture that emerged breaks into five areas, each with its own edge cases designed in rather than left as an afterthought: store info, customization, subscriptions, assets, and permissions and billing.
02
Working through edge cases as failure modes
Attribute validation, oversized file uploads, locked permissions: each got its own designed state instead of being left to fail invisibly. The categories and nodes screens show this concretely, an admin can drag and drop up to six default banner images across a node, with validation errors handled inline rather than silently.
03
Prototyping and pressure-testing
Interaction patterns for drag-and-drop uploads, revenue calculators, and locked and unlocked permission states got tested and revised over that stretch, not designed once and shipped.
04
Validation as the real design work
The hardest problems in this project were never the primary flows. They were the moments an admin needed to know exactly what a change would do, and who was allowed to make it, before it happened.
Solution
A dashboard that felt like ownership
By June 2024, Mesh App Manager was a complete self-serve admin platform. An admin logs in, lands on an instance overview, and from there has direct control over everything that used to require a developer:
Editing store info and brand assets
Customizing categories, attributes, and node-level visuals, including bulk banner uploads
Setting subscription pricing and toggling in-app purchases, with a built-in revenue calculator
Managing billing: invoices, itemized receipts, payment methods
Gating who on their team can touch which settings, through a permissions layer with its own locked and unlocked states
Final design
The shipped App Manager dashboard. Admins can navigate between configuration sections using the left sidebar, with changes reflected in a live preview panel on the right before publishing.
Walkthrough
See it in action
A short walkthrough of the core admin flows: updating branding, managing content categories, and publishing changes with live preview.
Walkthrough
BILD App Manager — core admin flows
Outcome
From request queue to full autonomy
Mesh Communities no longer operates, so there's no analytics dashboard to pull retention or ticket-volume numbers from. The honest outcome here is qualitative, and it's worth stating plainly rather than dressing it up as a metric: admins went from filing a developer request and waiting in a queue for a logo swap or a price change, to making that change themselves, in real time, with no developer in the loop.
The shift
From filing a developer request to configuring the app yourself.
Before, anyone running a white-labeled app had to go through a developer to change how it worked. Mesh App Manager put store info, customization, subscriptions, assets, permissions and billing in one place that the people running the apps could control directly. Mesh no longer operates, so there are no metrics to point to. The shift is in who had the ability to make the change.
Reflection
What I learned
Looking back
What stuck with me most from this project was how much admin design comes down to trust. Every validation message and permission gate I built was answering the same question: what does this person need to know before I let them act on their own? That's a different problem than making something look clean. It's closer to deciding how much control someone actually deserves, and when.
I also learned what it takes to sit with a brief that changes underneath you. This one started as a lightweight analytics tool and turned into a full configuration platform, and it would have been easier to force the new problem into the old plan. Re-scoping around what admins actually needed instead was the harder call, and the right one.
There's no polished number to end on here, either. Mesh doesn't exist anymore, so I can't point to a retention chart or a support-ticket drop to prove any of this worked. The case for it has to be made on the work itself, which is a more exposed way to present a project. Honestly, I think it's the more useful one to have in a portfolio.
Alyssa Jones © 2026