The quiet infrastructure story behind a Product Hunt launch — and what it says about how creators should be building their own stack
Most Product Hunt launches are forgettable because they optimize for the upvote, not the operator. The interesting ones are the launches where the maker accidentally shows you their whole workflow. Markly is one of those. On the surface it’s a macOS Markdown editor for people who keep their notes in a folder of .md files — a niche, developer-flavored tool that has almost nothing to do with Instagram Reels or TikTok hooks. But the launch comment thread is more useful than the product page, because the maker, Muh Ghazali Akbar, walked through exactly how he shipped the landing page: a Next.js 16 app deployed on Vercel, Git-push deploys, preview URLs, ISR-revalidated release badges, and a dynamically generated share image. That is the same stack a lot of solo creators and two-person social teams are quietly running in 2025, and it’s worth unpacking — because the way you ship your landing page now shapes what you can actually test, iterate, and monetize.
This essay is not a review of Markly. I haven’t run it as my daily editor, and I’m not going to pretend otherwise. What I want to do is use the Markly launch as a case study for a bigger thesis: the creator-economy conversation has gotten obsessed with content tooling — schedulers, repurposers, AI caption generators — while ignoring the boring infrastructure layer underneath it. The makers who win the next two years of the creator economy will be the ones who treat their link-in-bio page, their newsletter landing, their course sales page, and their media kit as deployable software, not as a Canva export.
Let me explain why that matters, and where I think the launch story is genuinely instructive versus where it’s just indie-maker cosplay.
What Markly actually is, and the problem it names precisely
Strip away the Product Hunt framing and Markly is a native macOS Markdown editor with a very specific opinion: your notes already exist as files, and the app should edit them in place rather than import them into a proprietary library or database. The maker’s own framing is that “most Markdown apps wanted me to import everything into their own library or database, and the lightweight ones felt like a text box with a preview bolted on.” That’s a real complaint, and it’s the same complaint knowledge workers have been making about note apps since the Evernote-to-Notion migration wave a decade ago.
The feature list is short and specific: point it at any folder and it edits your .md files in place; files changed elsewhere (by git or another editor) reload automatically; markers like ** and # collapse on lines you’re not editing and reappear when the caret moves there; one-click Git sync from the sidebar that handles commit, pull (rebase), and push scoped to your notes folder; focus-on-paragraph mode; typewriter scrolling; a GitHub-style preview with KaTeX math; and HTML/PDF export. It’s fully native (SwiftUI, AppKit, Apple’s Liquid Glass), works offline, and has no accounts, analytics, or tracking. It requires macOS 26 Tahoe, ships universal for Apple silicon and Intel, and is MIT licensed. The maker says it’s free and always will be. Roadmap items are image paste/drag, an outline panel, and full-text search — all “not yet shipped” as of the launch.
Why creators should care about a file-format argument
Here’s the part most social media managers will skip past, and shouldn’t. The file-format question — do your notes live in a proprietary database or as plain .md files in a folder you control — is the same question you should be asking about every piece of your content operation. Where do your captions live? Your hooks? Your content calendar? Your UTM parameter spreadsheet? If the answer is “inside the tool,” you have a portability problem the day that tool changes its pricing, gets acquired, or shuts down. If the answer is “in a folder I own, that any tool can read,” you have optionality.
I’ve watched this play out in the scheduling layer for years. Buffer and Hootsuite both let you export some data, but neither gives you a clean, portable, human-readable archive of every post you’ve ever scheduled. Later is great for visual planning; its data is not something you can grep. That’s not a knock on any of them — it’s the tradeoff of a hosted product. But it means the smartest operators I know keep a parallel plain-text or spreadsheet source of truth for the things that actually matter: hooks, CTAs, evergreen post IDs, and the mapping between a piece of content and the platform it’s optimized for. Markly’s whole pitch is that this parallel source of truth should be the primary one, and the editor should adapt to it.
I’d bet that’s the right instinct for a certain kind of creator — the newsletter writer, the technical founder who posts on X and LinkedIn, the YouTuber who scripts in Markdown before recording. It’s probably the wrong instinct for a pure Instagram or TikTok visual creator whose “notes” are really a camera roll and a CapCut project file. That distinction matters more than the product itself.
The launch-page stack is the actual story for social operators
Now the part I actually want to talk about, because it’s where the launch comment thread earns its keep. Ghali described the Markly site as a Next.js 16 app deployed on Vercel, with Git-push deploys and preview URLs that let him iterate on the interactive editor demo and the copy “without touching any infrastructure.” The site is prerendered and served from Vercel’s CDN, the latest release version badge is fetched from GitHub and revalidated hourly with ISR, and the 1200×630 share image is generated on the fly with next/og.
Read that again and notice how many of those capabilities map directly onto what a creator’s landing page needs:
- Preview URLs mean you can show a client, a sponsor, or a collaborator a staging version of a page before it goes live. If you’ve ever sent a screenshot of a media kit to a brand and then had to rebuild it because they wanted one number changed, you understand why this matters.
- ISR-revalidated release badges are the same pattern as a “latest YouTube video” or “latest podcast episode” embed that updates itself without you redeploying. The mechanic — fetch from an API, cache it, revalidate on a schedule — is the difference between a landing page that’s stale in a week and one that maintains itself.
- On-the-fly OG image generation is the single most underrated growth lever for creators. Your share image is what shows up in the X card, the LinkedIn preview, the Slack unfurl, the iMessage link preview. If you’re generating it dynamically from the page’s title and metadata, every new post you publish gets a decent share card for free. If you’re uploading a static PNG, every new post looks the same and gets ignored.
Why TikTok creators should care more than LinkedIn ones
Counterintuitive take: the creator who benefits most from this kind of infrastructure is not the LinkedIn thought leader. It’s the TikTok or Reels creator who’s trying to convert short-form attention into something they own — an email list, a Discord, a paid community. Short-form platforms give you almost no native way to capture a lead. Your bio link is the entire funnel. And a bio link that’s just a Linktree with five buttons is leaving money on the table compared to a self-hosted page that can A/B test a headline, swap a CTA based on which video drove the click, and fire a UTM-tagged event into your analytics.
LinkedIn creators, by contrast, get a lot of native distribution and native lead capture — DMs, comments, profile views. The marginal value of a custom landing page is lower. So if you’re a short-form-first creator, the Vercel-plus-Next.js pattern Ghali described is genuinely worth learning, even at a shallow level. You don’t need to be a developer. You need to understand the mechanics well enough to brief one, or to use a no-code layer on top of it.
Where the math breaks
I want to be honest about the failure mode here, because I’ve fallen into it. The trap is spending a weekend building a beautiful custom landing page and then never driving traffic to it. Infrastructure is not distribution. A dynamically generated OG image does nothing if nobody shares the link. Preview URLs don’t matter if you never ship a second version. I’ve watched creators — myself included — treat “I built the page” as the accomplishment, when the actual accomplishment is “I tested three headlines and doubled my email capture rate.” The stack is a means, not an end. If you can’t articulate the experiment the stack enables, don’t build the stack.
What the Markly launch teaches about content repurposing workflows
There’s a second, subtler lesson in the launch that I think social operators should steal: the maker’s own content workflow. He’s writing in Markdown, in files, in git. That means his writing is version-controlled, diffable, and portable. Every draft has a history. Every edit is attributable.
Compare that to how most social teams actually work. A caption gets drafted in a Google Doc, pasted into Metricool or Later, scheduled, and then — six months later — nobody can find the original, nobody knows which version performed best, and the “content library” is a graveyard of screenshots in a Slack channel. The repurposing workflow that actually scales is the one where the source text lives somewhere durable and the platform-specific adaptations are generated from it, not typed fresh each time.
I’ve started recommending a simple pattern to teams I work with: keep a single Markdown file per content pillar, with the canonical long-form version at the top and platform variants below it, each tagged with the platform and the date it ran. When you want to repurpose, you’re editing a file, not re-inventing a post. An editor like Markly — or any of the Obsidian, iA Writer, or Typora alternatives — is fine for this. The tool matters far less than the discipline of keeping the source portable.
The AI-repurposing tools are solving the wrong half of the problem
This is where I’ll be blunt. The current wave of AI content tools — the ones that promise to turn one YouTube video into 30 social posts — are mostly solving the generation half and ignoring the retrieval half. They can produce a TikTok caption from a transcript. They cannot tell you that you already posted a near-identical caption eight months ago and it flopped. They cannot maintain a canonical source of truth. They cannot version your hooks.
The reason is structural: those tools want your content to live inside their product, because that’s how they justify a subscription. A file-based workflow inverts that. Your content lives with you; the AI is a stateless service you call. I’d bet the next meaningful shift in creator tooling is toward exactly this — AI features bolted onto portable, user-owned content stores, rather than AI features that require you to migrate your library into someone else’s database. The Markly launch is a small signal in that direction, even though Markly itself has no AI features at all.
Where my judgment says this falls short
Let me be balanced, because the launch has real limitations and the maker would probably agree with most of them.
Platform lock-in is the obvious one. Markly is macOS 26 Tahoe only. That’s an extremely recent OS requirement, it excludes Windows and Linux entirely, and it excludes any Mac older than a couple of years. For a solo creator on a 2019 MacBook Air, this is a non-starter until they upgrade. The maker is transparent about it, but it’s a real constraint, and it’s the kind of constraint that quietly kills adoption for tools that are otherwise well-built.
“Free and always will be” is a promise, not a business model. The maker says Markly is MIT licensed and free forever. That’s generous and I believe the intent. But it also means there’s no revenue to fund the roadmap items he listed — image paste/drag, an outline panel, full-text search. Open-source projects with no funding mechanism often stall exactly at the point where the fun parts are done and the tedious parts begin. Not a criticism of this maker; a pattern I’ve seen repeatedly. If you’re going to depend on a free tool for your workflow, have a fallback.
Git sync is a power-user feature dressed as a convenience feature. One-click commit/pull/push from a sidebar sounds simple. In practice, git conflicts are confusing, rebase is scary for non-developers, and the moment two devices edit the same file offline, you’re in merge-conflict territory that a social media manager should not have to debug. I like that it’s there. I would not recommend it to a non-technical creator without a warning.
The product is not for most social media managers. If your job is running Instagram, TikTok, and Pinterest for a brand, Markly does nothing for you. It’s not a scheduler, it’s not a design tool, it’s not an analytics dashboard, it’s not a repurposing engine. It’s a text editor with strong opinions. The value for social operators is indirect — it’s the workflow philosophy, not the app.
Who this is actually for
The honest answer: developers who write, technical founders who post, newsletter writers who script in Markdown, and the small subset of creators who already keep their content in git. If you’re in that group, the file-in-place model and the offline/no-tracking stance are genuinely appealing. If you’re not, the launch is still worth reading — but read it for the deployment story, not the editor.
What I’d watch / test next
Three concrete things an operator can do this week, in increasing order of effort.
First, audit your portability. Pick your single most valuable piece of content — the post that drove the most signups, the video that drove the most email subscribers — and try to find its original source file, its canonical caption, and its performance data in under five minutes. If you can’t, your content operation has a retrieval problem, and no amount of new AI tooling will fix it. Move that one piece into a plain-text or Markdown file this week and start the habit.
Second, generate a dynamic OG image for your link-in-bio page or your newsletter landing. If you’re on Vercel with Next.js, next/og is the path the Markly maker used. If you’re not technical, most modern landing-page builders now have a template-based version of this. The point is that every new piece of content you publish should get a share card that reflects its actual title, not a static logo.
Third, run one honest A/B test on your bio link. Two headlines, two weeks, UTM-tagged, one metric — email capture rate or click-through to your offer. I’d bet most creators reading this have never actually tested their bio link, despite it being the single highest-leverage page in their funnel. The infrastructure conversation only matters if it ends in an experiment. Otherwise it’s just a nicer-looking dead end.
