Atlas

Mission Cloud’s customer-facing app, Mission Control, kept bumping into a gap. The Product Development team I was on ran into projects that weren’t straightforward customer features. Cross-customer reports. Internal workflows. Data customers shouldn’t see. Our legacy internal tool was a decade out of date, slow, and unmaintained. So I spent two months of spare cycles designing and building Atlas, an internal tools platform that now accounts for over a third of the engineering team’s roadmap.

The Problem

Problem Statement

Supporting Mission’s customers takes more than a customer-facing app. Internal teams need their own data, workflows, and tools to do their work.

Today, that work is scattered across a customer-facing app where it doesn’t belong, a legacy tool that’s been left to rot, and one-off scripts and spreadsheets.

Without a dedicated home for internal tools, teams lose time, take on security risk, and avoid building the features they actually need.

The Plan

The problem was clear. The harder question was what to do about it. That took weeks of parallel work on two tracks.

What do we build?

I ran 10-15 stakeholder interviews across customer-facing and product teams at different seniority levels. Some sessions confirmed what I already suspected. Others surfaced needs that ended up shaping the post-MVP backlog. I designed conceptual screens to make the idea tangible. Where internal data would live, how it could scale, what it would feel like to use.

How do we build it?

I worked through the architecture with our Principal Architect and the five Frontend Engineers on the team I was managing. Could a second app share Mission Control’s authentication, API access, and UI components? Was a monorepo viable without turning into a multi-year migration? The conversations went deep on dependency boundaries, build tooling, and deploy paths. By the time they wrapped up, the engineers were on board with a phased approach.

When the what and the how came together, I went in for the pitch.

The Pitch

I pitched to the Director of Product Management, Director of Engineering, and VP of Product Development. The vision landed. So did the architecture, because the engineers already in the room had vetted it. The blocker was time. No one wanted to pull people off the existing roadmap for a speculative project, which was fair. That’s the only concern I could argue against with fancy concepts and infrastructure diagrams. So I made the offer. I’d do the infrastructure work myself, on spare cycles, without anyone leaving the existing roadmap commitments. They gave me the green light.

Building It

Over the course of two months, using slow Friday afternoons, occasional evenings, and a few focused blocks I carved out, I got to work. I was managing the frontend engineering team at the time, so the engineers on my team reviewed every PR and architecture decision along the way. I phased the work into small, reviewable chunks where each PR improved the existing codebase on its own. Even if Atlas never shipped, the work would pay for itself. The MVP was a searchable list of customers, built on existing API endpoints. That was it.

.
├── .storybook/
├── apps/
│   ├── atlas/
│   └── mission-control/
├── packages/
│   ├── api/
│   ├── auth/
│   └── ui/
├── jest.config.js
├── playwright.config.js
├── tsconfig.json
└── vite.config.ts

What the tree doesn’t show is the work behind it. Auth, the API layer, and UI components had to be pulled out of code that wasn’t built to be reused. Each extraction was its own refactor. Storybook, Jest, and Playwright kept running across everything the whole way through.

Growth

We didn’t announce Atlas to the broader company for about a year. Instead, we shared it quietly with individuals who’d find it useful. An Account Manager looking up customer details. An engineer who wanted AWS account information without waiting 10 minutes for the legacy tool. They used it more than expected, shared it with more coworkers, and started requesting features. Each new feature was a side project that I designed ahead of time so the team could ship whenever the next spare cycle landed. Once the backlog grew past what I could keep up with alone, I brought one of the product designers on my team in to help work through new page designs. Eventually Atlas had to be actively planned in quarterly roadmaps.

About a year and a half in, we’d reached near feature parity with the legacy tool. Combined with that legacy tool’s mounting security issues, we made the call to port over the remaining functionality and sunset it entirely.

What It Is Today

Atlas has grown into six primary areas, each cross-linked to the others and to Mission Control.

A customer's overview page. AWS accounts, contracts, integrations, and Loops all show up in context for teams that start with a customer in mind.

An AWS account overview. Same data, accessed account-first. The customer is preserved as a link, not duplicated as a view.

The Loop Timeline view inside a customer. Every meeting and its state, without bouncing between tools.

Finance needed more than surfaced data. They needed workflow tools. Uploading contracts, applying billing adjustments, configuring tiered support fee rules with the SQL that drives the billing engine. These are the screens finance teams stare at every month. They deserved the same care as any customer-facing surface.

The Contract Upload modal. A structured form for what used to be tracked in spreadsheets.

Pricing dimensions, the building blocks for billing rules and adjustments.

The Billing Adjustment modal. A guided flow for corrections that used to require an engineer.

The Billing Rules modal. Finance can read and verify the underlying SQL without an engineer translating it.

What I Learned

Infrastructure as product design

The monorepo, shared design system, and build tool swap were the hardest things to get buy-in for. They sounded like engineering overhead. They were actually the product decision. Every feature after the MVP was cheap because the foundation was shared. The auth refactor meant no new login flow. The shared components meant no new design system. The monorepo meant no new deploy pipeline. The infrastructure wasn’t a prerequisite for Atlas. It was the whole project, why we could do it in the first place. The customer list was just proof that it worked.

IA for multiple mental models

Different teams approached the same data from different directions. Account Managers started with a customer, engineers with an AWS account, finance with a contract. We made a choice for Atlas to have multiple paths to reach the information you’re looking for. A top-level list view for browsing and searching, and a contextual placement inside related objects when you did. We kept the maintenance manageable with one strict rule. Actions only live on detail pages. One canonical detail view per object, regardless of how you got there.

Internal tools forgive too much

Internal users don’t churn, they use what they’re given. The list views haven’t been redesigned since launch. The lift-and-shift pages still feel like a different app. The entitlements UX has been on my list for a year now. None of it generated the feedback that would have forced improvement. Customer-facing products fix themselves because users vote with their attention. Internal tools have to be improved deliberately. The thing I’d do differently is set up deliberate feedback cycles with the early users from day one to build the feedback muscle quicker.

Outcomes

Atlas is the daily-driver for Mission’s customer-facing teams. Account Managers, Customer Success, Support Engineers, Onboarding, Finance, Revenue Ops, and the engineers keeping it all running. The AWS Accounts list alone saw 18,400 views in March.

The roadmap share isn’t scope creep. The company kept finding problems where the right place to solve them was inside Atlas. The legacy tool has been fully sunset, and every new internal feature now costs a fraction of what it would have with a separate codebase.