Running a Platform Solo

When you're a solo founder running a SaaS platform, you spend a lot of time in two places: building features and keeping the lights on. The operations part—understanding your users, monitoring platform health, debugging issues—is something you have to get right without a team behind you.

Early on, I was doing platform operations through AWS dashboards, clicking through DynamoDB tables, SSH-ing into Lambda logs. It worked, but it was slow and error-prone. Every time I needed to investigate a user issue or check revenue numbers, I'd lose 10 minutes navigating menus. When you're moving fast, that friction adds up.

So I built the Admin CLI—a command-line tool that lets me manage the entire Jottings platform from my terminal. It's become one of my most-used tools for keeping the platform healthy.

Why a CLI, Not a Web Dashboard?

I considered building an admin web interface. It seemed like the "proper" way to do it. But there are real advantages to a CLI for a solo founder:

Speed: I can get insights with 3 keystrokes instead of 5 clicks through a web UI. No page loads. No waiting for APIs to respond.

Scripting: I can chain commands together. Export users to CSV, filter subscriptions, run batch operations—all without switching between tools.

Flexibility: I can add new commands in minutes without designing web forms or managing state. The terminal is flexible in ways a web UI isn't.

Transparency: Everything that happens is logged in my terminal. I can audit what I did, when I did it. Compare that to a web dashboard where operations can get buried.

No Attack Surface: An admin web panel is a security target. A CLI that runs locally and requires AWS credentials is inherently more secure.

The trade-off is that it's only available to developers with terminal access and AWS credentials. But for platform operations, that's exactly the right constraint.

What Can You Actually Do With It?

The Admin CLI is organized into six command groups:

Users: List all users, search by email pattern, get complete user profiles, view platform-wide statistics. When someone emails about a missing account, I can find them in 3 seconds.

Sites: List all sites (with filters for Pro status, custom domains), show full site details with owner info, search by subdomain, view analytics. Perfect for debugging site-related issues or understanding Pro customer usage patterns.

Subscriptions: List and show subscription details, calculate monthly recurring revenue (MRR) and annual recurring revenue (ARR), see which subscriptions were manually granted by admins. I run the revenue command on the first of every month to know where we stand.

Analytics: Get a complete platform overview (total users, sites, growth), view daily/weekly/monthly growth trends, see signup method breakdowns. I run the overview command almost daily to understand momentum.

Debug: Find orphaned sites (sites with missing users), check for counter mismatches in the database, monitor SQS queue health, list builds stuck in the dead letter queue. These are lifesavers when something goes wrong.

Export: Dump all users, sites, or subscriptions to CSV. Makes it easy to do analysis in a spreadsheet or share data with someone else.

Each command supports multiple output formats (table, JSON, CSV), which means I can pipe output to other tools or grep for specific information.

Typical Workflows

Here's how I actually use this thing:

Morning health check:

jottings-prod analytics overview
jottings-prod debug queue-status

Takes 30 seconds. I see total users, new signups, revenue, and whether the build queue is healthy.

User investigation (someone reports a broken site):

jottings-prod users search user@example.com
jottings-prod users show <user-id>
jottings-prod sites list --user-id <user-id>

In under a minute, I know everything about that user, all their sites, and can see if something is obviously broken.

Monthly revenue report:

jottings-prod export users users-$(date +%Y-%m).csv
jottings-prod export sites sites-$(date +%Y-%m).csv
jottings-prod subscriptions revenue

I've got the data I need to understand the month. If growth is slow, I can dig into which signups methods are converting (email vs Google vs Apple OAuth).

Debugging a build failure:

jottings-prod debug queue-status
jottings-prod debug failed-builds

Tells me immediately if builds are backed up, if there are messages in the dead letter queue, and I can grab error details to fix the underlying issue.

The Detail That Makes It Work

What makes this tool actually useful is that it's environment-aware. I can run the same commands against dev or production:

alias jottings-dev='STAGE=dev AWS_PROFILE=jottings-admin npx tsx lambda/scripts/admin-cli.ts'
alias jottings-prod='STAGE=prod AWS_PROFILE=jottings-admin npx tsx lambda/scripts/admin-cli.ts'

Now I can test something in dev, verify it's fixed in prod, all without context-switching. The fact that it's environment-aware in the code means I never accidentally run a destructive operation on the wrong database.

Color-coded output is another detail—Pro sites show in green, free sites in gray. Failed builds highlight in red. My eye can scan output instantly and spot anomalies without reading every line.

What This Frees Up

The biggest benefit isn't that the CLI is fast (though it is). It's that I don't have to remember AWS console navigation. I don't have to context-switch between Lambda logs, DynamoDB tables, and Cognito dashboards. Everything is one command away.

This matters because platform operations can be a huge cognitive load. If you're also building features, the last thing you want is to spend 15 minutes finding where a user's data is stored. The CLI lets me stay in flow.

It also means I catch issues faster. A daily routine becomes automatic. Revenue tracking becomes a habit. Queue health becomes something I notice immediately if it breaks.

Building Tools for Yourself

If you're building any platform, I'd encourage you to invest in your own operations tooling. Don't wait until you have a team to justify it. A well-designed CLI can handle what a founder needs for years before you need a full admin dashboard.

The specifics will be different for your platform—your command groups, your metrics, your debugging needs. But the principle is the same: remove friction from the operations you do most often.

I spent maybe 20 hours building this. It's saved me hundreds of hours since. That's the kind of leverage that compounds over time.

If you're running a platform, what's the operation you do most often that's still too slow? That's probably where to start.

Want to build your own platform? Jottings makes it easy to launch a microblog without hosting headaches. Start free today.