Operational SecurityIndie HackingWriting

BUILDING IN PUBLIC WITHOUT LEAKING SECRETS

Oct 9, 20266 min read

A lightweight checklist for sharing progress online while keeping credentials, infrastructure details, and user data private.

THE TENSION

Building in public is one of the best growth strategies for indie hackers and founders. Sharing your progress, your numbers, your code builds an audience, attracts collaborators, and keeps you accountable.

But the same transparency that builds trust can also leak things you never meant to publish: API keys, user data, internal URLs. One careless screenshot is enough.

THE ONE RULE THAT MATTERS MOST

A secret that has been public, even for ten seconds, is a burned secret.

Deleting the tweet doesn't fix it. Deleting the commit doesn't fix it. Bots scrape GitHub and social feeds in real time, and git history keeps everything. If a key, token or webhook URL was ever visible:

1. Rotate it first. Generate a new one and revoke the old one.

2. Then clean up the post or the commit.

3. Then check the provider's logs for activity you don't recognize.

Everything else in this post is about not needing to do that.

WHERE SECRETS ACTUALLY LEAK

Most people blur the .env file and think they're safe. These are the ones that get through:

DevTools Network tab. Authorization headers, cookies and request payloads are all one click away. A "look, it works" screenshot of a request can contain a live session token.

Terminal prompts and stack traces. They expose usernames, absolute file paths and machine names.

Console and dashboard URLs. Database IDs, project IDs and endpoints sit in the address bar and the page header.

Webhook URLs, error-tracking DSNs and storage bucket names. These behave like credentials, but nobody thinks of them as secrets.

Git history. A secret committed once and "removed" in the next commit is still there.

Screen recordings. Autofill dropdowns, notification popups and a tab you forgot you had open.

Image metadata. Exported screenshots and photos can carry device and location data.

DON'T RELY ON REMEMBERING

A manual checklist fails exactly when you're tired and excited to post. Put machines in the way:

Pre-commit secret scanning with gitleaks or trufflehog, so a commit containing a key never gets created.

GitHub secret scanning and push protection turned on for every repo.

A `.gitignore` that covers `.env*` from the first commit, plus a committed .env.example with fake values.

A separate browser profile for screenshots, with no extensions, no saved logins and no personal tabs.

A REAL NEAR-MISS

A few days ago I was learning Burp Suite, intercepting and modifying requests against my own servers, both local and live. I got a request tampered the way I wanted and took a screenshot of the intercept view to share.

I almost posted it.

The intercept panel shows the full raw request: session cookies, auth headers, everything. I was so focused on what I'd changed in the request body that I didn't see the credentials sitting in the same frame.

I caught it because I shared it to a friend on discord jokingly telling him that i'm now a hacker, then he noticed the auth cookies and told me to remove them before i post it and also cautioned me to be careful next time.

Afterwards, I tested with a throwaway account, so a leaked cookie would be worthless anyway.

I didn't bother posting it again for some reason but i guess that was a reminder for me to always be careful when building in public.

THE CHECKLIST

Screenshots & Recordings

Network tab, headers and cookies are not visible

Terminal shows no env vars, tokens, usernames or local paths

No user data (emails, names, IDs) is visible

Address bar and page headers don't show project IDs, endpoints or internal URLs

Other tabs, notifications and autofill are hidden

Code Snippets

Real values are replaced with placeholders

No comments reference internal systems or people

No hardcoded credentials, even "temporary" ones

Metrics & Data

User-related numbers are aggregated, never individual records

Timestamps can't be used to profile one user's activity

You've decided on purpose whether to share revenue and costs. That's a business choice, not a security one.

ASSUME YOUR STACK IS KNOWN

You'll often hear "don't reveal your tech stack, it helps attackers." That's weak advice. Attackers can fingerprint most stacks from response headers, error pages and front-end bundles in minutes. If hiding the vendor names is what protects you, you were never protected.

Assume the attacker already knows your framework, your database and your host. Then ask what stops them:

Are secrets stored outside the code and rotated?

Is every endpoint authenticated and authorized?

Is user data encrypted and access-limited?

Are webhooks signature-verified?

Share the stack freely. Protect the keys, the data and the access paths. Sharing how you secured something is good content. Sharing the credentials never is.

THE "WOULD I TWEET THIS?" TEST

Before posting anything technical, ask: "If someone patient and skilled saw this, what could they do with it?"

An example:

Before: a screenshot of your Redis dashboard to show you hit the free-tier limit, with the endpoint hostname and database ID visible in the header and URL bar.

After: a crop of just the usage graph, or a recreated chart with no dashboard chrome.

The story ("I burned through 500K commands in days and had to find out why") is the valuable part. The identifiers add nothing to it. If the story survives the redaction, redact.

WHAT YOU SHOULD SHARE

Most of the best build-in-public content is completely safe:

Product decisions and the reasoning behind them.

Design iterations and user feedback.

Aggregated growth numbers.

Mistakes and lessons learned. These are the most engaging posts, and they often show your security thinking best.

Your process and workflow.

THE BOTTOM LINE

"Public" doesn't mean "everything." It means "everything that's safe to share," and you'll only get that reliably by combining habits with tooling.

Rotate fast, automate the checks, and assume your stack is already known. Share your thinking, not your secrets.

Share this post

Share on WhatsApp