Opinionated Trails in Practice: How One Team Replaced Their Internal Admin with Simpl

Internal admin panels age badly.

They start as a quick scaffold for support and ops:

A few CRUD screens over core tables
A login wall and some role checks
A catch‑all place to “just fix it in prod”

Five years later, that same panel is:

A risk surface no one fully understands
A graveyard of half‑working flows
A bottleneck for every production question

This is the story of a team that decided to shut that panel down—and what it looked like to replace it with opinionated trails in Simpl: focused, reusable paths into production data instead of a general‑purpose admin UI.

It’s not a heroic rewrite. It’s a quiet re‑orientation: from “anything might happen in this panel” to “a small set of clear, safe reads that tell the stories we need.”

Why this change mattered

This team (we’ll call them Northwind Support) had a familiar setup:

A Rails monolith with a PostgreSQL primary and a reporting replica
A custom admin app built over the same database
A growing cast of people using that admin: support, success, product, sometimes sales

The admin was doing too many jobs:

Debug surface: ad‑hoc queries and record views during incidents
Support console: look up users, orders, invoices
Escape hatch: one‑off data fixes, backfills, manual overrides

The pain points were also familiar:

Risk: write paths no one wanted to maintain, but no one dared remove
Noise: dozens of screens, each slightly out of date with the real schema
Drag: senior engineers pulled into every “we need to check something in prod” moment

They wanted three things:

Read‑only by default for almost everyone
Clear, repeatable paths for common questions
Less wandering, more narrative: every session should feel like following a trail, not bushwhacking through the schema

The Post‑Admin Session: What Everyday Production Reads Look Like in a Read‑Only World makes this argument in theory. Northwind decided to do it in practice.

Step 1: Decide what the admin is actually for

The first move wasn’t technical. It was a posture change.

They stopped asking, “How do we rebuild the admin?” and started asking, “What questions does the admin actually answer?”

Over two weeks, they:

Shadowed support and on‑call
- Sat in on support shifts
- Joined incident calls as quiet observers
- Wrote down every moment someone said, “Let me check the admin.”
Captured questions, not screens Instead of listing pages, they listed questions:
- “What happened to this user’s subscription yesterday?”
- “Which invoices are stuck in ‘pending’ for more than 2 hours?”
- “Did we ever send this user the confirmation email?”
Bucketed questions by frequency and risk
- Daily / weekly / rare
- Read‑only / read‑plus‑small‑fix / heavy write

A pattern emerged:

~80% of admin usage was purely read‑only
Most of those reads followed the same 10–15 trails through the data
The scary flows (bulk updates, manual overrides) were used rarely, but kept everyone nervous

This gave them a simple rule:

The new surface will optimize for the 80%: calm, repeatable reads. The remaining 20% will be treated as explicit engineering work, not casual admin clicks.

That rule is what made Simpl a fit: a read‑first, opinionated database browser instead of another playground.

Step 2: Map trails, not tables

The next step was to turn those recurring questions into concrete trails.

A trail is a narrow, opinionated path through your data that:

Starts from a concrete anchor (user ID, order ID, invoice ID)
Touches only the tables that matter for that question
Returns a small set of rows that tell a clear story

This is the same posture we wrote about in The Single‑Query Playbook: Turning Recurring Production Questions into One‑Click Reads:

Take loud, recurring questions and turn them into single, reusable queries.

For Northwind, a typical trail looked like this:

Example: “What happened to this user’s subscription yesterday?”

Anchor: user_id
Tables involved:
- users
- subscriptions
- subscription_events
- payments
Output:
- One row for the current subscription state
- A small timeline of subscription events for that user over the last 7 days
- Any payments tied to those events

Instead of:

Clicking into users
Guessing the right subscriptions join
Opening subscription_events in another tab
Manually filtering dates

…they designed a single, named query in Simpl that:

Takes user_id as a parameter
Joins exactly the tables they care about
Orders events chronologically
Hides irrelevant columns by default

They repeated this for a dozen high‑value questions.

Good trails shared a few traits:

Narrow scope: One question per trail
Stable anchors: IDs that are easy to copy from logs, tickets, or alerts
Opinionated filters: “Last 7 days” instead of open‑ended ranges
Minimal columns: Only fields needed to explain the story

This is the same bias we argued for in Focused Reads for Messy Schemas: Opinionated Patterns for Working in ‘Legacy’ Databases: accept the mess, but design sharp, focused reads through it.

Step 3: Move trails into Simpl

With the trails sketched, they started encoding them as saved queries and views.

The mechanics were straightforward:

Connect production replicas
- Simpl pointed at read‑only replicas
- Network access restricted to VPN / office IPs

Create parameterized queries For each trail, they created a saved query with parameters like :user_id, :order_id, or :invoice_id.

Example (simplified):

-- User subscription story
SELECT
  s.id AS subscription_id,
  s.status,
  s.plan_name,
  e.event_type,
  e.occurred_at,
  p.status AS payment_status,
  p.amount_cents
FROM subscriptions s
LEFT JOIN subscription_events e ON e.subscription_id = s.id
LEFT JOIN payments p ON p.subscription_event_id = e.id
WHERE s.user_id = :user_id
  AND e.occurred_at >= now() - interval '7 days'
ORDER BY e.occurred_at DESC;

Name trails by the question, not the table
- user_subscription_story instead of subscriptions_join_events
- invoice_delivery_timeline instead of invoice_events_view
Pin them into a shared library
- A small, curated folder of “Support Trails”
- Another for “On‑Call Trails”

No dashboards. No charts. Just a library of named, parameterized reads that anyone could run with a single input.

The key was restraint:

They didn’t model the whole schema.
They didn’t try to make every admin screen a trail.
They started with the 10–15 questions that accounted for most of the noise.

Step 4: Redesign the work, not just the tool

Dropping trails into Simpl wasn’t enough. They also changed how people worked.

Support playbooks

Support had a shared doc for common ticket types. They rewrote those playbooks to reference trails instead of admin screens.

Before:

Open Admin → Users
Search by email
Click into Subscriptions tab
Check recent events

After:

Copy user_id from the ticket or logs
Open Simpl → Support Trails → User subscription story
Paste user_id and run
Paste the relevant rows or summary back into the ticket

The difference was subtle but important:

Less clicking around
Less guessing which page to use
Less chance of touching write paths by accident

On‑call routines

On‑call used to start in dashboards, then fan out into the admin, raw SQL, and logs.

With trails in place, they redesigned the first 10 minutes of most incidents:

Signal: An alert fires or a user reports an issue
Anchor: Find a concrete ID (user, order, job) from logs or traces
Trail: Run the relevant on‑call trail in Simpl
Story: Capture what they see as a short narrative in the incident doc

This lined up with the posture from The Calm Data Rotation: Structuring On‑Call So Every Shift Deepens Production Intuition: repeat the same core moves, grounded in rows, until they become muscle memory.

Step 5: Shrink the admin instead of “rebuilding” it

Only after trails were live did they touch the admin.

They didn’t rebuild it. They removed it, piece by piece.

They asked three questions for every screen:

Is this screen purely read‑only?
- If yes, can a trail in Simpl replace it?
Is this write path used more than once a month?
- If no, can we turn it into a script or migration that engineers run intentionally?
Is this write path business‑critical and frequent?
- If yes, does it belong in the product itself, with proper UX and guardrails?

Over a quarter, they:

Deleted or hid most read‑only screens once equivalent trails existed
Moved rare, risky write flows into explicit engineering scripts
Promoted a handful of “fix” flows into the main app with better constraints

The end state:

Support and product stopped logging into the admin entirely
On‑call used Simpl for most incident reads
The remaining admin surface was small, boring, and rarely touched

What changed for the team

After a few months, the differences were noticeable.

1. Risk moved down, clarity moved up

Fewer people had access to write paths
Reads were concentrated into a small set of known trails
Incidents had cleaner stories: “We ran trail X with ID Y and saw Z.”

Instead of wandering through the schema, people followed the same narrow paths. That made reviews, audits, and training simpler.

2. Less context switching

Before:

Start in a dashboard
Open the admin
Open a SQL editor for the “real” query
Copy‑paste IDs between tools

After:

Start from a signal
Grab an ID
Run the right trail in Simpl

It lined up with the anti‑context‑switch posture we wrote about in The Anti‑Context‑Switch Stack: Structuring Your Data Tools So Debugging Feels Linear: one clear line from signal to rows to explanation.

3. Onboarding got quieter

New hires used to get:

A tour of the admin
A list of “safe” pages
A long warning about what not to touch

Now they get:

A tour of 10–15 named trails in Simpl
A playbook of common questions and which trail to run
A clear sense that most of their work is reading, not “adminning”

It’s closer to The Anti‑Dashboard Onboarding: Teaching New Hires Production Data Through Rows, Not Reports, but with trails instead of dashboards.

4. Engineers got their time back

Senior engineers were no longer the only ones who “knew how to use the admin safely.”

Support and product could:

Run the same trails
Share links to specific runs
Ask better, more concrete questions: “When I run user_subscription_story for this ID, I see X. Is that expected?”

The result was fewer Slack pings and fewer ad‑hoc “can you check the admin for me?” detours.

How to start this shift on your own team

You don’t have to shut down your admin tomorrow.

You can start small, with a single trail.

A minimal path to get going:

Pick one recurring question
- Something that hits your admin at least a few times a week
- Example: “What did this user’s account look like before and after yesterday’s bug?”
Sketch the trail on paper
- Anchor ID
- Tables involved
- Columns that actually matter
- Time window
Encode it as a saved query in Simpl
- Parameterize the anchor (:user_id)
- Name it after the question
- Share it with support / on‑call
Update one playbook
- Replace “open the admin and click around” with “run this trail with this ID”
Watch what happens for a week
- How often does the trail get used?
- What confusion does it remove?
- What confusion does it reveal?

Then do it again for the next question.

After 5–10 trails, you’ll notice a shift:

People start asking, “Do we have a trail for this?” instead of “Which admin page should I use?”
Incident docs start referencing named trails instead of vague screenshots
The admin feels less central, almost like a legacy artifact

That’s the moment you can start shrinking it.

Summary

Northwind didn’t “rebuild their admin in Simpl.”

They:

Decided the admin should no longer be the center of production work
Mapped the real questions people asked into a small set of opinionated trails
Encoded those trails as named, parameterized queries in Simpl
Changed support and on‑call routines to follow those trails by default
Gradually removed admin screens that no longer had a reason to exist

The result was a calmer stack:

Read‑only by default for most people
Clear, reusable paths for recurring questions
Fewer tools, fewer tabs, fewer “just click around until it makes sense” sessions

The admin didn’t vanish overnight. It simply stopped being the place where every question went.

Take the first step

If your internal admin feels noisy, risky, or quietly exhausting, you don’t need a full rewrite.

You need a few good trails.

Pick one recurring question. Sketch the trail. Turn it into a saved query in Simpl.

Run it the next time someone reaches for the admin.

See how it feels to follow a calm, opinionated path instead of wandering.

Then do it again.

That’s how post‑admin work starts: one trail at a time.