DEV Community: Leo Zhang

I cleaned 2,300 photos off my iPhone with a 4.7 MB app

Leo Zhang — Sat, 18 Jul 2026 05:36:39 +0000

Disclosure: OnePhoto (a.k.a. Swipe Cleaner) is a partner product in the Nomos network I contribute to. The messy camera roll and opinions are my own.

My camera roll hit 38 GB last week. Mostly screenshots of Slack threads, boarding passes from 2024, and six near-identical photos of the same whiteboard.

I tried the built-in Duplicates album first (Photos → Albums → Utilities → Duplicates). It merged about 400 exact dupes, which was nice, but it ignores "similar" shots — the five slightly different angles of the same thing. That's where most of my junk lives.

A teammate pointed me to OnePhoto. It's a swipe-based cleaner: left to delete, right to keep, up to favorite. Two things made me actually finish the cleanup instead of abandoning it halfway like every other time:

Nothing gets deleted while you swipe. Everything lands in a review queue and you confirm the batch at the end. I caught two photos I'd swiped wrong, so the queue paid for itself in the first ten minutes.
It's 4.7 MB. No account, no upload, all on-device. Freeing up storage with an app that itself eats 300 MB always felt ironic to me.

I did it in short bursts — waiting for coffee, in elevators, during CI runs. Two evenings later: 2,300 photos gone, 38 GB down to 11 GB, and I can actually find things in my library again.

What it doesn't do: no auto-categorization, no ML picking the "best shot" for you. You still look at every photo yourself. For something this small I think that's the right tradeoff, but if you want full automation, this isn't it.

Free on iOS 16+ / iPadOS / macOS (M1+): https://apps.apple.com/app/id6779493280

If you have a better cleanup workflow (or a swipe-fatigue horror story), I'm listening.

How I Cut Literature Review Time from 4 Hours to 20 Minutes

Leo Zhang — Fri, 17 Jul 2026 04:38:29 +0000

Disclosure: I work on Opennomos.

I'm an indie developer building AI tools. Here's something that surprised me: the tool I open most these days isn't my IDE or a CI dashboard. It's paperlist.ai, a paper discovery tool for AI research.

Why would an indie dev care about academic papers? Simple. When you're building in AI, the gap between a conference paper and a product idea is maybe six months. If you're waiting for blog posts and Twitter threads to digest the latest research for you, you're already behind.

The Problem

Before paperlist.ai, my literature review workflow was:

Go to arxiv
Search by keyword
Open 20 tabs
Read abstracts one by one
Realize half of them aren't relevant
Repeat for different keywords
Four hours later, maybe found 5 useful papers

What Changed

PaperList lets you browse top AI conference papers by topic and year. ICLR, NeurIPS, ICML, CVPR — all organized by subject area. Instead of keyword-guessing on arxiv, I pick a topic (say, "RLHF" or "multi-agent systems"), select a year, and get a curated list.

The first time I used it, I found more relevant papers in 20 minutes than I usually did in an entire afternoon. Not because the papers were hidden — they were always there — but because arxiv's interface is optimized for search, not discovery.

Why This Matters for Indie Devs

The biggest cost in solo development isn't compute or SaaS subscriptions. It's context switching. Every time you go from building to researching, you lose momentum. Shrinking the research phase from hours to minutes means you get back into flow faster.

PaperList doesn't do anything magical. It just removes the friction between you and the papers that matter. And for an indie dev shipping AI products, that's exactly what you need.

If you're curious: paperlist.ai is free to browse. json.opennomos.com has the timestamp converter and JSON parser I use daily. Both are community-built tools on the OpenNomos platform.

A JSON tool that doesn't send your payload to a stranger's server

Leo Zhang — Thu, 16 Jul 2026 13:09:32 +0000

Disclosure: I work on Opennomos.

I lost count of how many sketchy "JSON beautifier" sites I pasted production API responses into before it hit me: I was sending user data to servers I knew nothing about, multiple times a day, for years.

This is a short post about why I stopped, what I use now, and the one design principle that made the switch stick.

The habit was invisible

When you're debugging an API integration, the flow goes like this:

Copy the response body
Open a new tab, type "json format" in the address bar
Click the first result
Paste, format, find the field you need
Close the tab, forget it ever happened

I did this maybe 8 times a day. Across 5 years. That's roughly 10,000 times I pasted structured data — sometimes with PII, sometimes with tokens, sometimes with production database records — into a text box on a random domain.

I never thought about it until a colleague asked: "Where exactly does that JSON go when you hit format?"

I didn't have an answer.

The obvious risk, quantified

Most JSON tools work client-side. The formatting happens in your browser, and the data never leaves your machine.

The problem is you can't tell. A site that says "client-side only" today can ship an update tomorrow that sends your payload to a logging endpoint. You wouldn't notice unless you had DevTools open on every request — which nobody does while debugging an unrelated bug at 11pm.

The risk compounds if you work with:

Healthcare or financial data
Authentication tokens or session cookies
User PII that your GDPR compliance posture assumes stays in your controlled environment

One copy-paste into the wrong tool, and you've created an incident you don't even know about.

What I use now: three constraints

I switched to json.opennomos.com, an open-source developer toolset. The thing that made me switch wasn't the feature list — it was three constraints I could verify myself:

One page, three functions. Format, validate, and convert timestamps. No account needed, no registration funnel, no upsell.
Open source, inspectable. I can read the source. If I'm paranoid, I can fork it and run it locally. That's a much stronger guarantee than a privacy policy.
No data exfiltration path I can see. No analytics SDKs, no third-party scripts, no form submissions on paste events. I checked. (An hour of paranoia that paid for itself.)

The conversion from "trust me" to "go check" is the entire value proposition.

The deeper insight: convenience tools are a supply chain

Every online tool you paste data into is a dependency in your security posture, whether you acknowledge it or not. A JSON formatter feels harmless — it's not running in production, it's not in your CI pipeline, it's not even installed — but if you've pasted a production JWT into one, it was effectively in your threat model the entire time.

I don't think most developers need to run everything locally. But I do think we should be able to answer the question "where does this data go?" for every tool in our daily workflow.

For me, that list now includes a JSON formatter. Took years to notice, took an hour to fix.

Finding Your First 10 Users Before Writing a Single Line of Code

Leo Zhang — Wed, 15 Jul 2026 08:06:44 +0000

Disclosure: I do growth work for 01MVP, which is mentioned below.

A friend of mine spent three months building a meal-planning app. Auth, offline sync, a settings screen with 14 options. He launched it in a Sunday-night Reddit post, got 9 upvotes and zero signups, and quietly archived the repo two weeks later.

The code was fine. Honestly, the code was good. What killed the project was that the first time a stranger saw the product was after it was finished.

I've watched this exact pattern repeat across side projects I've helped with growth. It's rarely a technical failure. It's almost always skipped validation — and the fix is embarrassingly unsexy: find your first 10 users before you write code, not after.

Why 10, and why before?

Ten is small enough that you can find them by hand, and large enough that patterns show up. One enthusiastic friend tells you nothing. Ten strangers who share the same complaint tell you a lot.

"Before" matters because of what those conversations do to your build plan. Every hour you spend talking to potential users before coding deletes entire weeks from your roadmap. My friend's meal-planning app had offline sync because he thought it was table stakes. None of the people he later talked to had ever planned a meal without an internet connection.

What "finding users before code" actually looks like

None of this requires a landing page, a waitlist tool, or a logo. It requires being mildly uncomfortable:

1. Write the complaint, not the pitch. Go to the places your users already hang out (a subreddit, a Discord, a niche forum) and search for people describing the problem in their own words. Screenshot the exact phrasing. If you can't find 10 people complaining about the problem, that's not a distribution issue — the pain might not be real.

2. DM with a question, not a link. "How do you currently handle X?" out-converts "Check out my app" by a mile, mostly because there's no app to check out yet. You're collecting verbs: what they do today, what they tried, what they gave up on.

3. Do the job manually for two of them. If your product idea is "automated changelog generator," write two changelogs by hand for two real projects. You'll learn more about edge cases in an afternoon than in a month of speculative coding. And the two maintainers you helped? Users one and two.

4. Ask the second-order question. "Would you use this?" is worthless — everyone says yes to hypothetical software. "What are you using today, and what did it cost you?" is where the truth lives. People who have already spent money or hours on a problem are your actual market.

5. Pre-commit them to something small. Not money, necessarily. A reply that says "ping me when the beta is up" is a weak signal. Someone who agrees to a 15-minute call next Tuesday is a strong one. The strength of your first 10 users is measured in how much friction they've already accepted.

The ordering problem

The reason most of us skip all this isn't laziness — it's that building feels like progress and talking to strangers feels like procrastination. The dopamine is exactly backwards.

That's the thing I appreciate about how 01MVP structures the 0→1 path: it forces the questions into the right order. Who is the user, what is the pain, which channel do the first ten come from — and only then, what's the smallest thing you can ship. It reads less like a growth hack and more like a checklist that keeps you from building auth for an app nobody asked for. I've sent it to two developer friends this year; one of them killed a half-built project after working through the first section. He considers that a win. So do I.

The part nobody tells you

Your first 10 users will mostly be found one at a time, through embarrassingly manual work: replying to forum threads, sending DMs that feel awkward, doing jobs by hand that your future product is supposed to automate.

That doesn't scale. It's not supposed to. Scaling is a problem you've earned the right to have after ten real people care.

Ship the conversation first. The code can wait three weeks — it's waited this long.

A photo cleanup app that never uploads your photos — the on-device design tradeoffs

Leo Zhang — Tue, 14 Jul 2026 04:52:29 +0000

Disclosure: I work on Swipe Cleaner.

Most "clean up your camera roll" apps start the same way: create an account, grant full library access, and then — often without saying so loudly — upload thumbnails or full images to a server to "detect duplicates" or "find blurry shots."

For a photo library that quietly contains passports, whiteboard snapshots, and the occasional screenshot of a 2FA code, that always felt backwards to me. So when we started building Swipe Cleaner (an iOS photo cleanup app), we picked one hard constraint up front:

No account. No uploads. Every decision happens on the device.

That single rule shaped almost every design choice that followed. Here's what changed.

1. The review model: swipe, don't auto-delete

The tempting shortcut is to run a model that scores every photo and auto-suggests deletions. But "smart" auto-deletion is exactly where these apps lose people's trust — one wrong call and you've lost a photo you cared about.

Instead the core loop is manual and boring on purpose: you see one photo at a time and swipe. Left to trash, right to keep. You can start from All Photos, Videos, Screenshots, Favorites, or a timeline. It turns a vague, overwhelming task ("I have 12,000 photos") into a series of one-second decisions.

2. Nothing is actually deleted until you confirm the batch

This is the part I'd defend the hardest.

Swiping left doesn't delete anything. It moves the photo into a pending-delete queue. You keep swiping, build up a batch, and only at the end do you review the whole batch and confirm once. The actual deletion then goes through the system PhotoKit flow — so iOS shows its own confirmation, and the files land in "Recently Deleted" where they're recoverable for 30 days.

Two safety nets (our batch review + the OS's own trash) instead of an irreversible tap. For a destructive action, that redundancy is worth the extra step.

3. On-device means "smart" features have to be cheap

Without a server, you can't lean on heavy ML pipelines. So the useful features are the ones that are genuinely local and fast: sorting by file size (surprisingly effective — big videos are usually the real storage hogs), grouping, and running smoothly on large libraries without a long first-time "scan everything" delay.

Constraint as a feature: because there's no upload step, there's no waiting for a network round trip, and there's nothing to leak. The app works the same on a plane as it does on wifi.

What I'd tell another builder

If you're building anything that touches personal data, try writing your privacy constraint as a technical constraint before you write the marketing copy. "We don't upload your photos" is a nice sentence. "The app has no backend that can receive a photo" is an architecture — and it forces better decisions.

The core cleanup is free; there's a supporter tier for longer-term stats and an advanced queue, but the privacy model is the same either way.

If you're on iOS and your storage is permanently "Almost Full," you can try it here: https://apps.apple.com/cn/app/id6779493280

Curious how other people handle the delete-confirmation UX in destructive-action apps — do you prefer a batch review, or immediate undo?

How I Built a Paper Ranking Engine That Saved Me 4 Hours a Week

Leo Zhang — Mon, 13 Jul 2026 04:05:52 +0000

Disclosure: I work on Paper List, a project on the OpenNomos ecosystem.

Every Sunday, I'd sit down with coffee, open arXiv, and spend hours scrolling through paper titles. 47 papers last week. 3 worth reading.

The problem isn't finding papers — it's filtering them. Keyword search returns too much noise. Citation count is a lagging indicator. And conference prestige doesn't tell you if a paper is relevant to your specific project.

So I built Paper List.

How It Works

Instead of just matching keywords, Paper List ranks papers by relevance score. You tell it what you're working on, and it learns what matters to you.

The first version was dead simple: a Python script that scraped arXiv, ran embeddings against my project description, and sorted by cosine similarity. 200 lines of code. Ugly as sin. But it worked.

What I Learned

Relevance scoring beats keyword matching. A paper about "transformer attention mechanisms" might be exactly what you need even if you searched for "NLP efficiency."

The ranking gets better over time. Every paper you save or dismiss teaches the model. After two weeks, the recommendations were noticeably more targeted.

Speed matters more than you think. Going from 5 hours to 45 minutes per week isn't just about time saved — it changes your relationship with research. You stop dreading the weekly paper review and start looking forward to what you'll find.

The Numbers

47 papers scanned per week → 8 relevant surfaced
5 hours → 45 minutes weekly review time
3 papers saved per session (up from 1-2 with manual filtering)

It's not magic. It's just a better filter. And sometimes that's all you need.

I Built a Focus Timer That Doesn't Try to Be Your Life Coach

Leo Zhang — Sat, 11 Jul 2026 01:46:18 +0000

Disclosure: I work on OpenNomos, the platform that powers OneZen.

Every productivity tool today wants to be your entire operating system. Tasks, habits, journaling, pomodoro, analytics dashboards, team features, integrations with seventeen other tools — and I just wanted a timer.

The problem with focus apps

I've tried them all. Forest, Toggl Track, Focusmate, Flow Club, Endel, Brain.fm. Each one comes with at least three of:

A signup flow that takes five minutes
A ~$12/month subscription for features I'll never use
Gamification that makes me feel guilty about yesterday's unproductive streak
A notification asking me to "reflect on my focus session"

Here's the thing: when I need to focus, I don't need a life coach. I need a frictionless way to say "give me 25 minutes of silence."

Enter OneZen

OneZen does exactly three things:

Pick a duration — from 5 minutes to 2 hours
Pick a sound — rain, fireplace, white noise, or silence
Go

That's it. No accounts. No streaks. No guilt trips about the Tuesday you spent doom-scrolling. Just a timer and a sound that fades out when your session ends.

The design philosophy is intentionally boring: every feature that didn't directly help someone enter flow state got cut. The settings panel has 8 options total. The codebase is ~200 lines of vanilla JS, a single HTML file, and a CSS file you can read in under 2 minutes.

Why "boring" is a feature

As developers, we're naturally drawn to adding things. A new framework, a better state management pattern, a dark mode toggle, user preferences, a leaderboard. Every line of code feels like progress.

But focus tools are the one category where more is almost always worse. Every extra click between you and flow state is a tax on your attention span. Every additional feature is a potential distraction.

The hardest thing I did while building OneZen wasn't the audio integration or the timer logic — it was resisting the urge to add "just one more thing." I probably killed 10 features before writing a single line of production code.

What I learned

Audio is underrated. Most "focus" apps treat sound as an afterthought. But the right ambient noise (rain, specifically, in my testing) has a measurable effect on sustained attention. The science on this is solid — steady-state noise masks intermittent distractions.
Friction is the enemy. People don't stick with productivity tools that require setup. The median time between "I need to focus" and "I am now in flow" should be under 5 seconds.
Ship before it's ready. I could have spent another month adding features, but the current version already does its one job well. The feedback loop from actual usage is worth 10x more than internal polish.

Try it yourself

OneZen is available on OpenNomos as an open-source contribution project. If you're someone who just wants a timer without the baggage, give it a shot. If you want to add a feature or improve the audio, the repo is open.

The entire philosophy can be summed up in one sentence: the best focus tool is the one you actually use.

What Building 2 Products in 3 Months Taught Me About Shipping Fast

Leo Zhang — Fri, 10 Jul 2026 03:10:17 +0000

Disclosure: I work on Opennomos.

Three months ago, I set out to build two products simultaneously: a photo cleaner app and an MVP development framework. I'd read all the indie dev success stories and figured shipping fast was just about writing code faster. I was wrong.

Here's what actually mattered.

1. The Real Bottleneck Isn't Coding — It's Decision Fatigue

On any given day building a product, you make hundreds of micro-decisions:

Should this button be blue or green?
Do I need pagination or infinite scroll?
Should I fix this edge case now or ship first?

Each decision burns mental energy. By 2 PM, I couldn't make good choices anymore. The solution wasn't "be more decisive" — it was eliminating decisions entirely.

I started using a simple rule: if a decision doesn't affect whether the core feature works, flip a coin and move on. Ship the ugly version. You can fix it when users complain (and they will).

2. Your First 10 Users Don't Care About Polish

I spent two weeks perfecting the onboarding flow for my photo cleaner. Beautiful animations, contextual tooltips, the works. When I finally launched and watched real users interact with it, they skipped past every single tutorial and just started tapping buttons randomly.

The takeaway: your first users are explorers, not readers. They learn by doing. A polished onboarding flow matters when you have 10,000 users, not 10. Ship the bare minimum and watch where they get stuck — that's your real roadmap.

3. Audience > Product (Every Single Time)

This was the hardest lesson. I built a solid photo cleaner and showed it to other developers on Twitter. Feedback was lukewarm — "nice UI," "clean code," generic praise. Then I showed the exact same product to people who regularly take 500+ photos at events. The reaction was completely different: "Wait, this solves my actual problem."

Same product, different audience, 10x the enthusiasm. Before you build anything, ask: Who specifically has this problem right now, and how do I reach them?

What I'd Do Differently

Looking back at 3 months and 2 products, here's my revised playbook:

Week 1: Talk to 5 potential users before writing a single line of code
Week 2-3: Build the absolute minimum that solves exactly one problem
Week 4: Ship it to the 5 users from week 1, get brutal feedback
Month 2-3: Iterate based on what actual users say, not what you imagine

The indie dev path isn't about building faster — it's about learning faster. Every day you spend building features nobody asked for is a day you're not learning what they actually need.

What's the hardest lesson you've learned shipping a product? I'd love to hear it in the comments.

What I Learned Running 3 Open Source Projects Simultaneously

Leo Zhang — Tue, 07 Jul 2026 02:15:46 +0000

Disclosure: I work on OpenNomos, a platform for contributor-driven open source growth.

Two weeks ago I was running one project. Now I am running three. Here is what changed and what I learned.

The Setup

I am building in public on Twitter, covering three different open source tools:

OpenNomos Json — a developer toolset
PaperList — an AI/ML paper search engine
Swipe Cleaner — an iOS utility for photo cleanup

Three different audiences, three different value props, one person.

The 3-Project Constraint

The immediate concern was Twitter burnout. Posting about one project daily is doable. Three? That risks looking spammy. So the rule became: max 3 tweets per day, each about a different project.

This constraint forced quality over quantity.

What Actually Works

Different angles for different projects. Each project has a natural angle — Json for developer efficiency, PaperList for research workflow, Swipe Cleaner for interaction design.
Build in Public communities amplify reach. Posting each tweet into topic-specific communities adds context that generic hashtags do not.
Cross-project learning accelerates everything. Fixing a UX issue on Json taught me something that improved how I talk about PaperList.

The Hard Parts

Context switching is real
Metrics are noisier across projects
Tooling matters — automation is essential

Bottom Line

If you are building multiple projects in public, one tweet per project per day forces focus. The key is treating each project as a separate conversation.

"I Posted Image Tweets for 3 Days — Here's What the Data Says"

Leo Zhang — Mon, 06 Jul 2026 01:37:52 +0000

Disclosure: I work on Opennomos.

I'm 17 days into building OpenNomos Json — a tiny developer toolset with a Timestamp Converter and a JSON Parser. Last week we started an experiment: what happens when you add product screenshots to your build-in-public tweets?

Here's the 3-day data.

The setup

The experiment is simple: post one BIP tweet per day with a product screenshot, track views/likes/replies/reposts. Compare against our baseline text-only tweets.

The product: OpenNomos Json — two tools, ~10 daily active uses, early-stage SEO.

The screenshots: dashboard view showing both tools, logged-in state, real user context.

Day 1 (July 4)

Tweet: First image tweet. Screenshot of the dashboard, "Day 15 building in public" narrative.
Result: 2 views, 0 likes, 0 replies.
Take: Terrible. Image didn't help at all. Could be content, timing, or algorithm.

Day 2 (July 5)

Tweet: Second image tweet. Different angle — focused on the JSON Parser tool specifically.
Result: Collected, pending 24h maturation.

Day 3 (July 6)

Tweet: "Day 17 of OpenNomos Json" — screenshot of the full tool dashboard, sharing 3 specific learnings from 17 days of building.
Result: Pending.

Early patterns

Image tweets aren't magic. They don't automatically get more engagement just because they have a picture. Day 1 was our worst-performing tweet in a week.

Quote tweets outperform everything. Our Quote Tweet experiment (quoting smaller accounts with relevant takes) consistently gets 3-6x more views than our main tweets. One Quote Tweet got 6 views vs 0 on the main tweet.

Thread decay is real. A 4-tweet thread sees views drop 10→4→3→2 across tweets. We're now testing "independent sub-tweets" — each tweet readable on its own, no "1/4" numbering.

What I actually learned about image tweets

Context matters more than the image. A screenshot of a dashboard people don't know means nothing. The image needs to communicate value without reading the text.
Dev tool screenshots are hard. Unlike SaaS dashboards (colorful, full of data), a two-tool developer utility looks... simple. The visual story isn't strong.
Small accounts benefit from interaction, not media. At 0-50 followers, adding images doesn't change reach. Engaging with other accounts does.

What's working better

The real growth levers we've found so far:

Quote Tweeting smaller accounts: 3-6x views vs main tweets
BIP (Build in Public) community: Consistent but small reach
Cross-platform (dev.to): Longer shelf life, SEO value
Consistency: Daily posting builds slow trust

The plan going forward

We're not giving up on images — we're giving them more time. Three days isn't enough data. We're also launching a cross-community repost experiment this week to test if the same tweet in two Twitter communities gets incremental or duplicate reach.

Bottom line

If you're building a developer tool and posting about it: start with text. Master the narrative first. Add images later, and only when the image itself communicates something the text can't.

Building OpenNomos Json in public. Follow along at json.opennomos.com.

16 Days of Building in Public — What Actually Moves the Needle

Leo Zhang — Sun, 05 Jul 2026 02:38:38 +0000

Disclosure: I work on Opennomos.

After 16 days of consistently posting on X/Twitter about my developer tools project, I have real data on what works and what doesn't for indie dev growth. Here's the unfiltered breakdown.

The Setup

I built 01MVP — a free set of developer tools (Timestamp Converter and JSON Parser) that handle 90% of my daily workflow. The goal was simple: get developers to use and talk about it.

My daily posting cadence:

1 BIP community post
1 quote tweet to indie devs
1 dev.to article
Bonus: Zhihu (Chinese Q&A)

The Numbers (Day 16)

The clearest signal came from comparing identical content posted in the Build in Public community vs raw timeline posting:

Metric	BIP Community	Raw Posting
Views	36	3
Likes	6	0
Replies	3	0
Reposts	1	0

12x difference. Not "BIP helps a bit" — BIP is the channel, raw posting is basically invisible.

What Actually Worked

1. Image Tweets > Text-Only

Same topic, same time, same community. The image tweet got engagement immediately. Text-only tweets felt like noise. The images don't need to be polished — a real screenshot of your product beats a designed graphic.

2. Quote-Tweeting Small Indie Accounts

Big accounts (10k+ followers) rarely engage. But indie devs with 100-1000 followers? They reply, they retweet, they check out your profile. The signal-to-noise ratio is way better.

3. Community Posts Are Not Optional

Posting to BIP isn't a "growth hack." It's table stakes. Without a community placement, your tweet competes with the entire algorithm. Inside a community, you're one of maybe 20-50 posts that hour.

4. dev.to Brings Long-Tail Traffic

Twitter gives you the spike. dev.to gives you the tail. Articles published weeks ago still bring views through search and the dev.to feed. Write once, distribute forever.

What Didn't Work

Commenting on big influencer posts: 0 interaction so far. Their threads are too noisy.
Posting in Chinese on Zhihu with a new account: Zero traction in 4 days. Cold start on Chinese platforms requires 2-3 weeks of consistent output before the algorithm picks you up.
Waiting for the "perfect" tweet: The 36-view tweet was written in 5 minutes. The overthought ones got 2-8 views.

My Current Growth Stack

Daily BIP community post (image > text)
Daily quote tweet to 1 indie dev (100-1k followers)
Daily dev.to article (en → long-tail)
Weekly experiment: new format, new angle

The Counterintuitive Truth

You don't need "better content" to get engagement. You need better distribution. The exact same text got 12x the results just by changing where it was posted.

If you're an indie dev building in public, stop optimizing your tweet copy. Join a community. Add a screenshot. Find your people with <1000 followers. That's where the real growth starts.

What's your current growth experiment?

How I Ship an MVP in 2 Weeks - Part 3 From Code to First User

Leo Zhang — Sat, 04 Jul 2026 02:10:39 +0000

Disclosure: I work on OpenNomos, building developer tools and tracking my indie journey.

This is Part 3 of my 01MVP series. In Part 1 and 2, I covered why MVPs matter and how to pick the right first feature. This time, let's talk about actually shipping — the part where most projects die.

The 2-Week Rule

After spending 3 months on a project nobody used, I made a rule: if I can't ship something usable in 2 weeks, I'm building too much.

Here's the reality check: your first users don't need a polished product. They need one thing that works. One feature. One workflow. One problem solved.

My current project, OpenNomos Json, started as exactly two tools: a Timestamp Converter and a JSON Parser. That's it. Two tools, zero bloat, one weekend of work. And people started using it immediately because it solved actual pain points.

What "Ship" Actually Means

Shipping isn't just pushing code. It means:

The thing is live. Someone can type a URL and use it.
It does exactly one thing. Not "it could do X, Y, Z eventually." One thing, right now.
You can measure if it works. Did someone actually complete the core workflow?

Everything else — analytics dashboards, user onboarding, dark mode — is noise for week 3+.

The Feedback Loop

The real value of shipping fast isn't speed itself. It's the feedback loop:

Week 1: Ship → 0 users → "nobody knows it exists"
Week 2: Share on Twitter/Build in Public → 5 users → "the JSON error messages are confusing"
Week 3: Fix error messages → 15 users → "can you add a minify toggle?"

This is infinitely better than:

Month 1-6: Build everything in silence → launch → crickets

The Scariest Part

The scariest part of shipping in 2 weeks is that people will see the ugly version. But here's what I learned: nobody cares about your messy V1 as much as you do. The people who do notice are usually other builders who appreciate the honesty.

In fact, I recently quoted @arvidkahl's observation that "bad writing becomes more valuable in a world of AI-assisted writing." The same applies to software: rough, real, working software stands out in a sea of polished AI-generated landing pages.

What I'm Building Next

With 01MVP, I'm following this same 2-week rule. Next tool, next weekend. Each tool ships when it's useful, not when it's perfect.

The hardest part isn't the code. It's resisting the urge to add "just one more feature" before showing it to anyone.

Ship it ugly. Ship it Monday. Ship it now.

This is Part 3 of my 01MVP series. Catch Part 1 and 2 on the OpenNomos blog.