DEV Community: Alex Cloudstar

How to write a product description that gets approved

Alex Cloudstar — Fri, 31 Jul 2026 16:56:22 +0000

Most directory rejections are not about the product. They are about the description.

You know what you built. The reviewer and the visitor do not. You have a few sentences to close that gap. Get them wrong and your submission sits in limbo. Get them right and approval, clicks, and SEO value follow.

This guide covers the description formats directories expect, the formula that works, real examples, and a checklist you can reuse on every submission including makers.page.

Why product descriptions matter for SEO and approval

Directory descriptions serve three audiences at once:

Human reviewers deciding whether to approve your listing
Visitors browsing category pages deciding whether to click
Search engines indexing the listing page and associating keywords with your domain

Curated directories in 2026 increasingly use internal search. If your description says "AI-powered platform" but never names your category or audience, you are invisible in directory search and unclear to reviewers.

Industry guides on SaaS and startup directory submissions recommend preparing multiple description lengths upfront:

Format	Length	Used for
Tagline	Under 100 characters	Headlines, card titles
Short description	50 to 100 words	Most submission forms
Long description	150 to 300 words	Featured listings, SEO depth
Extended	500+ words	Premium directories only

makers.page uses a short description on the submit form. Nail the short version first. Expand from there for other platforms.

The formula that gets approved

Every strong description answers four questions:

What does it do? (plain language, no jargon)
Who is it for? (specific audience)
What outcome do they get? (concrete benefit)
What makes it different? (one differentiator, not ten)

Compact template:

[Product name] is a [category] for [specific user] who [pain or goal]. It [core action] so you can [outcome]. Unlike [alternative], it [one differentiator].

Bad vs good examples

Bad:

"Revolutionary AI-powered platform leveraging cutting-edge technology to transform how modern teams collaborate."

Problems: no audience, no action, buzzwords, could describe anything.

Good:

"ReplyQuest is a Chrome extension for founders who want to post consistently on X. It gamifies replies and posts with XP, streaks, and leaderboards so daily engagement becomes a habit instead of a chore."

Why it works: names the product type, audience, core mechanic, and outcome.

Bad:

"The all-in-one solution for startup growth."

Good:

"SubmitWell manually submits your startup to 50 curated directories with screenshot proof. Built for solo founders who want backlinks without spending a weekend on forms."

Prepare four description tiers (once, reuse everywhere)

Founders who write fresh copy for every submission produce inconsistent listings and burn out. Prepare a kit once:

Tier 1: Tagline (under 100 characters)

One sentence. Product type + audience + outcome.

Example: "Chrome extension that gamifies X growth for indie founders."

Tier 2: Short description (50 to 100 words)

Two to three sentences expanding the tagline. Include pricing signal if relevant ("free during beta", "free tier available").

Example:

"ReplyQuest turns posting on X into a game. Earn XP for posts and replies, build streaks, unlock achievements, and climb leaderboards. Built for solo founders and creators who know consistency matters but struggle to show up daily. Free during beta."

Tier 3: Long description (150 to 300 words)

Structure:

Paragraph 1: The problem from the user's perspective
Paragraph 2: How your product solves it (workflow first, features second)
Bullet list: 3 to 4 benefits with outcomes, not feature dumps
Close: Pricing, CTA, or who it is NOT for (disqualifying audiences builds trust)

Tier 4: Extended (only when required)

Some directories allow 500 to 2,500 characters. Use for premium listings. Do not write 2,000 words if 200 will do. Curators value density over length.

Keywords without keyword stuffing

Directories are lightweight SEO surfaces. Place your primary keyword naturally:

Once in the tagline
Once in the short description
One to two times in the long description

Primary keyword examples for indie products:

"project management tool for agencies"
"Chrome extension for X growth"
"indie startup directory"
"invoice software for freelancers"

Avoid stuffing. Repeating the same phrase six times hurts readability and lowers trust with reviewers. Google demotes obvious stuffing patterns on directory pages too.

Match language to how your users search, not how your pitch deck speaks.

Phrases that get submissions rejected

Cut these from directory copy:

Phrase	Why it fails
"Revolutionary" / "game-changing"	Unverifiable superlative
"We leverage AI to..."	Vague, overused
"All-in-one solution"	Describes nothing
"Best in class"	Empty claim
"Disrupting the industry"	Investor pitch, not user copy
"For everyone"	No audience self-selection

Indie reviewers read dozens of submissions weekly. Specific beats hype every time.

Categories: the hidden part of your description

On makers.page, categories are separate from the description but equally important for discovery.

Pick every category that honestly fits. Common mappings:

Jira productivity extension → Productivity, Developer Tools
X growth Chrome extension → Browser Extension, Social Media
Billing API for SaaS → SaaS, Developer Tools
Community platform for makers → Community, SaaS

Wrong categories force reviewers to guess. Guessing slows approval.

Match the product stage honestly

Live product

Say what users can do today:

"Sign up and create your first project in under 2 minutes"
"Install the extension and see your XP dashboard immediately"
"Connect Stripe and send your first invoice"

Beta or waitlist

Say that clearly:

"Free beta. Chrome extension live in the Web Store."
"Waitlist open. Launching August 2026."

Submitting a concept page with no product behind it is a common rejection reason across directories.

The makers.page submit form

The submit form asks for:

Founder name
Email
Product name
Website URL
Short description
Categories (multi-select)
X handle (optional)

Your description is the highest-leverage field. Two sentences using the who/what/outcome formula is enough if they are specific.

After approval, your description appears on your public profile in Products and in the site sitemap for search indexing.

Adapt descriptions per directory (without starting from scratch)

Use the same core message. Adjust emphasis:

Investor-facing directories: traction, market, team
Developer directories: stack, integrations, open source
Indie maker directories: builder story, free tier, who it helps
Review platforms: comparisons, pricing tiers, screenshots

Never copy-paste identical paragraphs to 50 sites. Light adaptation per audience beats robotic duplication.

Pre-submission checklist

[ ] Tagline under 100 characters
[ ] Short description names audience and outcome
[ ] No unverifiable superlatives
[ ] Primary keyword appears naturally once
[ ] Pricing or "free" mentioned if applicable
[ ] Categories match the product
[ ] URL works on mobile
[ ] Description read aloud passes the "friend test"

Friend test: read your description to someone who does not know your product. If they cannot explain it back, rewrite.

Frequently asked questions

How long should my makers.page description be?

One to three sentences is enough. Clarity matters more than length.

Should I include pricing?

Yes if you have a free tier or free beta. "Free" builds trust and helps directories filter listings.

Can I use the same description as my homepage?

Use the same core message but tighten it. Homepage copy often assumes context a directory visitor lacks.

What if my product is hard to explain?

Lead with the problem and one concrete example: "Before/after" or "instead of X, you do Y."

Do emojis help?

Skip them unless the directory explicitly encourages them. Most curated sites prefer clean prose.

Write it once, submit everywhere

A strong product description is a reusable asset. Write your tiers once, adapt lightly per platform, and approval rates go up across the board.

Start with makers.page. A clear description is the fastest path to an indexed profile and dofollow link.

Related reading:

Originally published on makers.page. Want a free indie listing with human review? Submit your product.

Where to list your indie product (and what to skip)

Alex Cloudstar — Fri, 31 Jul 2026 16:55:41 +0000

Launch day makes you want to submit everywhere. That instinct wastes time.

Listing on 40 sites in one afternoon gives you forty thin mentions, duplicate descriptions, and zero momentum. A focused distribution plan beats a spray-and-pray spreadsheet every time.

This guide ranks where indie founders should list their product in 2026, what each channel is actually good for, and which directories are not worth your Tuesday afternoon.

Why listing strategy matters more than listing volume

Startup directory research in 2026 converges on the same advice:

Quality over quantity: 10 to 20 relevant listings beat 100 spam submissions
Verify link types: many "dofollow" claims are paywalled or wrong on the free tier
Unique descriptions: identical copy across directories creates a weak SEO footprint
Manual submission: automated blast tools trigger spam signals and low approval rates

Your goal is not to appear everywhere. It is to appear in the right places with the right message for each audience.

The three tiers of listing channels

Tier 1: Do these first (foundation)

These channels build permanence, clarity, and early authority.

Your own website

Obvious but skipped constantly. Before any directory:

One clear sentence above the fold
Title tag with product name
Meta description with your primary keyword
Working signup or install on mobile

Links to a vague homepage waste every directory listing you earn.

One curated indie directory with a dofollow profile

Pick a site that gives you a permanent indexed page, not a tweet-sized blurb that rotates off the homepage in 24 hours.

makers.page fits here: free submission, human review, public profile on Products, dofollow link when approved, and inclusion in the sitemap. Built specifically for indie founders, not enterprise SaaS upsells.

Your personal X and LinkedIn

Not directories, but where discovery actually happens for indie products. Post what you shipped, who it is for, one screenshot, and a direct link. Build-in-public posts outperform launch announcements for sustained signups.

Tier 2: Worth it when you have time (amplification)

Product Hunt

Best for: launch-day traffic spike, social proof badge, often dofollow profile link.

Not best for: sustainable weekly growth. Treat it as a milestone, not a strategy. Prepare assets, hunter network, and a first comment before you launch.

Indie Hackers

Best for: build-in-public community, founder feedback, honest milestone posts.

Tip: posts that teach something outperform "I built X" announcements. Share numbers, lessons, or a specific problem you solved.

Niche subreddits and communities

Best for: qualified feedback and early users who match your ICP.

Rules matter. Spend two weeks reading before you post. Answer questions helpfully. Mention your product only when it genuinely solves the problem in thread.

Relevant subs often include r/SaaS, r/startups, r/SideProject, and category-specific communities.

SaaS and dev directories (verify dofollow)

Platforms like SaaSHub, AlternativeTo, StackShare, and G2 appear on many backlink guides. Value varies by product type and approval strictness. Always verify the live link attribute before counting on SEO pass.

BetaList

Best for: pre-launch waitlists and early adopter email collection. Link type varies by tier. Useful before you have a full product, less useful after.

Tier 3: Usually skip (traps and diminishing returns)

Paid "featured startup" listings with no traffic proof
Directory lists of 500+ sites promoting mass submission
Sites requiring reciprocal backlinks before listing
Directories unchanged since 2019 with spammy outbound links
Submission services that guarantee rankings (red flag)
Paywalled dofollow where free tier is nofollow but marketing hides that fact

Founders who test submissions firsthand report that verifying rel="nofollow" on live listings saves money and disappointment. PitchWall, TinyLaunch, and some review platforms paywall or condition dofollow status.

How to verify a directory is worth your time

Before you submit, check five things:

Is the site indexed? Search site:directory.com your-competitor on Google
Does the listing page persist? Or does it rotate off the homepage daily?
What is the link type? Inspect HTML on an existing free listing
Is the audience relevant? Indie tool vs enterprise procurement buyer
Does approval require editorial review? Curated lists tend to pass more trust than auto-approve spam buckets

If three or more checks fail, skip it.

A 30-day listing schedule (not a one-day blast)

Spreading submissions looks natural and gives you time to adapt copy.

Week	Focus	Actions
Week 1	Foundation	Fix homepage, submit to makers.page, post on X
Week 2	Community	Join 2 niche communities, answer 5 questions
Week 3	Directories	Submit to 3 to 5 verified SaaS/dev directories
Week 4	Launch milestone	Product Hunt or Show HN if product is ready

Adjust pace based on feedback. If reviewers keep asking the same question, fix the product or description before submitting elsewhere.

Where makers.page fits in your stack

Think of makers.page as a permanent profile layer, not a one-day launch spike:

Submit with a clear description (how to write one)
Get reviewed by someone who signs up and uses the product
If approved, profile goes live with a dofollow link
Optional: shot at an honest YouTube review from alexcloudstar

No paywall. No upgrade tier for visibility. Always free.

It pairs well with:

Product Hunt for launch day
Indie Hackers for ongoing community
Niche Reddit/Discord for hand-to-hand user acquisition
Content SEO for long-term compounding (first 100 users guide)

Directory submission kit (prepare once)

Build this before you submit anywhere:

[ ] Logo (PNG, transparent, 200x200 minimum)
[ ] 3 to 5 product screenshots (real UI, not stock art)
[ ] Tagline under 100 characters
[ ] Short description (50 to 100 words)
[ ] Long description (150 to 300 words)
[ ] Founder name and X handle
[ ] Pricing model (free, freemium, paid)
[ ] Category tags (3 to 5 specific labels)
[ ] UTM-tagged URLs for tracking (?utm_source=directoryname)

Reuse the kit. Adapt emphasis per platform.

Common listing mistakes

Identical copy everywhere (duplicate content, low approval)
Wrong category (reviewer confusion, poor internal search placement)
Broken demo links (instant rejection)
Listing before the product works (damages credibility)
Chasing DR spreadsheets instead of audience fit
Ignoring nofollow platforms that send real traffic (Reddit, HN)

Comparison: launch platform vs curated directory

Factor	Launch platform (PH, HN)	Curated directory (makers.page)
Traffic pattern	Spike, then drop	Steady, low baseline
Link permanence	Profile often persists	Profile persists
Review process	Community vote / moderation	Editorial review
Best timing	Product ready, assets prepared	Any time product is usable
Primary value	Visibility burst	Indexed profile + dofollow SEO

Use both. They solve different problems.

Frequently asked questions

How many directories should I submit to?

Start with 5 to 10 quality targets in month one. Expand based on what drives signups, not what drives backlink count.

Should I pay for submission services?

Some founders use them to save time. Audit the list yourself. Verify dofollow claims. Avoid spam networks.

Is Product Hunt enough?

No. Launch spikes fade. Pair PH with permanent profiles and community channels.

Can I list a pre-launch product?

Some directories accept waitlists. makers.page works best when reviewers can actually use the product. Be honest about stage.

How do I track which listings work?

Use UTM parameters on every URL. Check referral traffic in analytics weekly.

Start with the right first listing

You do not need forty directories. You need the right ones with clear copy and a working product.

Submit to makers.page for free. Then expand to launch platforms and communities from a solid foundation.

Related reading:

Originally published on makers.page. Want a free indie listing with human review? Submit your product.

Structured outputs for LLMs: a developer guide (2026)

Alex Cloudstar — Fri, 31 Jul 2026 16:55:30 +0000

Getting a language model to return prose is easy. Getting it to reliably return {"status": "approved", "confidence": 0.87} every single time, with no stray text, no missing fields, and no invalid types, used to be the hard part of shipping LLM features to production.

By 2026 this problem is mostly solved at the API level. Most frontier providers support schema-constrained generation directly, meaning the model is not just asked nicely to return JSON, it is structurally prevented from returning anything else. That changes how you should architect the parsing, validation, and error handling in your app.

This guide covers the current state of structured outputs, how the major approaches differ, and how to pick the right one for a given feature.

What "structured output" actually means

Structured output is any technique that constrains an LLM's response to a predictable, machine-parseable shape, typically JSON that matches a schema you define, rather than free-form text.

There are three broad approaches in production today, and they are not interchangeable:

Prompted JSON: you ask the model to return JSON in the prompt. The model tries its best. Nothing enforces the shape.
Constrained decoding / JSON mode: the provider enforces valid JSON syntax, and in the strict variants, enforces your exact schema, at the token-sampling level.
Tool or function calling: the model chooses to invoke a defined function with typed arguments, and the provider validates the arguments against your schema before returning them.

Each solves a different part of the problem, and the differences matter once you are past a demo.

Approach 1: Prompted JSON (the fallback, not the plan)

This is "please respond only in JSON" in your system prompt, with no provider-side enforcement.

It works most of the time with capable models. It also occasionally returns:

JSON wrapped in a markdown code fence
A sentence of preamble before the JSON ("Sure, here's the JSON you requested:")
Missing fields the model decided were not important
Valid JSON with the wrong types (a number as a string, a null where you expected an array)

None of these failures are common with strong models in 2026, but "occasionally" at scale means real requests failing in production. Prompted JSON should be treated as a fallback path for providers or models that do not support stronger guarantees, not the primary strategy for anything customer-facing.

If you must use it, always wrap parsing in a try/catch, strip markdown fences defensively, and validate the parsed object against a schema before trusting it.

Approach 2: Constrained decoding and JSON mode

Constrained decoding works at a lower level than the prompt. Instead of hoping the model produces valid JSON, the provider restricts which tokens the model is allowed to sample at each step, so it is structurally impossible to produce invalid syntax.

Two tiers exist depending on the provider and model:

JSON mode: guarantees syntactically valid JSON. Does not guarantee it matches your schema. You can still get {} or a JSON object with the wrong keys.
Schema-constrained JSON (strict mode): guarantees both valid JSON and conformance to a schema you supply, typically JSON Schema. Required fields will be present, types will match, and enums will be respected.

Strict schema-constrained generation is the strongest guarantee available without a second validation pass, because the constraint happens during generation, not after. As of 2026, this is broadly supported across frontier model APIs (OpenAI's Structured Outputs, Anthropic's tool-based schema enforcement, and Google's response schema parameter on Gemini), though exact feature names and support levels vary by model tier, so check current provider docs before assuming parity across every model in a family.

When to use it

Use schema-constrained generation whenever the output feeds directly into your application logic without a human reading it first: classification results, extracted entities, form-filling, routing decisions, or anything stored directly in a database column with a fixed type.

Approach 3: Function and tool calling

Function calling frames the model's job differently: instead of "write JSON," the model is told "you have access to these functions, decide if and how to call them." The model returns a structured call with arguments matching your function's parameter schema.

This is the right model when:

The model needs to decide whether to produce structured output at all (should it answer in text, or call a tool?)
You are chaining multiple possible actions and want the model to pick one or several
You want the same schema enforcement as strict JSON mode, but framed as an action rather than a data blob

Function calling and schema-constrained JSON solve overlapping problems from different angles. If your use case is "always produce this exact shape," plain schema-constrained output is simpler. If your use case is "decide what to do, then produce arguments for it," function calling is the better fit.

Comparing the approaches

Approach	Syntax guaranteed	Schema guaranteed	Best for
Prompted JSON	No	No	Prototypes, non-critical paths
JSON mode	Yes	No	Loose structured text extraction
Strict schema-constrained JSON	Yes	Yes	Data pipelines, classification, extraction
Function / tool calling	Yes	Yes	Agentic decisions, multi-action flows

Most production systems in 2026 use a mix: function calling for agent decision points, strict schema-constrained output for deterministic extraction and classification tasks, and prompted JSON only where a provider or model genuinely lacks stronger support.

Design your schema like an API contract

Whichever approach you use, the schema itself is doing real engineering work. Treat it with the same care as a public API contract, because the model is effectively an unreliable caller of that contract.

A few practices that consistently reduce failures:

Keep required fields minimal. Every required field is a chance for the model to hallucinate a value when it does not actually have one. Make fields optional when "unknown" is a valid state.
Use enums instead of free strings wherever possible. "status": "approved" | "rejected" | "pending" is far more reliable than an open string field you then have to normalize.
Avoid deeply nested structures when you can flatten. Deep nesting increases the chance of a subtly wrong shape, even under strict constraints, and makes downstream parsing more fragile.
Add a confidence or reasoning field for anything high-stakes. Even with a guaranteed shape, you often want a signal for when to route to human review versus auto-accept.
Version your schemas. Treat schema changes like breaking API changes. If you add a required field, old cached completions or retries built against the old schema will fail validation.

Validate even when the provider guarantees the schema

Provider-side schema enforcement is strong, but it is not a substitute for validation in your own code, for a few concrete reasons:

Provider outages or fallback models may not support the same guarantee tier. If your code silently trusts the shape without checking, a degraded fallback path can push malformed data downstream.
Semantic correctness is not syntactic correctness. The model can return a syntactically perfect object with a nonsensical value, like a "confidence": 1.4 when your range is 0 to 1, or a date field with an internally inconsistent value.
Multi-provider setups are common by 2026 for cost and reliability reasons. A schema that is strictly enforced on one provider may only be loosely enforced (or unsupported) on another you fail over to.

Run every structured response through a runtime validator (Zod, Pydantic, or your language's equivalent) before it touches business logic. This is a small amount of code that prevents an entire class of production incidents.

Handling failures gracefully

Even with strict schema enforcement, you should design for the failure case, because it will happen: a rate limit forces a fallback to a weaker model, a provider has an incident, or a genuinely ambiguous input produces a technically valid but useless response.

A reasonable failure strategy:

Validate the response against your schema on receipt.
On validation failure, retry once with a slightly more explicit prompt or a stricter enforcement mode if you were not already using one.
If it fails twice, fall back to a safe default or route to a human review queue rather than surfacing a broken state to the end user.
Log the raw response for failed validations. These logs are the fastest way to spot schema issues or model regressions before users report them.

Treat structured output failures the same way you would treat a flaky third-party API: expected occasionally, handled explicitly, never silently swallowed.

Structured outputs in agentic workflows

Agent systems lean on structured outputs even more heavily than single-turn features, because each step in a multi-step agent typically needs to produce a machine-readable decision that feeds the next step.

A few patterns specific to agents:

Use function calling for the routing layer. Let the model choose which tool to call next, with arguments validated against each tool's schema.
Keep intermediate structured outputs small. Agents that pass large structured blobs between steps accumulate context and cost quickly. Extract only what the next step needs.
Log every structured decision in the chain. When an agent produces a wrong final answer, the structured intermediate outputs are what let you debug which step went wrong, rather than guessing from a final unstructured response.

A simple decision guide

If you are unsure which approach to reach for on a new feature, this order of questions helps:

Does the model need to decide whether to act, or just extract/classify? If it is deciding among actions, use function calling.
Is the output going straight into application logic or a database? If yes, use strict schema-constrained JSON, not prompted JSON.
Is this a low-stakes prototype or an experiment? Prompted JSON with a validation layer is fine to move fast, but plan to upgrade before shipping broadly.
Are you running on multiple providers or models? Confirm schema enforcement support on every model in your fallback chain, not just the primary one.

Frequently asked questions

Do I still need a JSON schema if the model rarely gets it wrong?

Yes. "Rarely" at scale is still a real failure rate, and the cost of an unvalidated malformed object reaching your database or a user-facing screen is usually far higher than the cost of adding a validation step.

Is function calling slower than plain JSON mode?

Latency differences are typically small and depend more on model choice and response length than on the mechanism itself. Benchmark your specific use case rather than assuming one approach is inherently faster.

Can I mix structured and unstructured output in one response?

Some providers support this (structured tool calls alongside free-text explanation), but it adds complexity to parsing. If you need both, it is often cleaner to make a separate call, or a separate field, for the explanation.

What happens if I add a new required field to my schema later?

Treat it as a breaking change. Any cached responses, retries, or logs generated against the old schema may not satisfy the new required field. Version your schemas or make new fields optional with sensible defaults.

Which provider has the best structured output support in 2026?

Support has converged considerably across major providers, and the practical answer depends on which models you are already using for quality and cost reasons. Check the current documentation for your specific provider and model tier, since support tiers still vary by model size.

The honest summary

Structured outputs stopped being a prompting trick and became an API-level guarantee. That is a genuine reliability upgrade, but it does not remove the need for good schema design, runtime validation, and explicit failure handling in your own code.

Use schema-constrained generation as the default for anything that feeds application logic. Use function calling when the model needs to decide what to do, not just how to format an answer. Validate everything anyway, log failures, and design a graceful fallback path. Do that, and structured outputs become one of the more boring, reliable parts of an LLM-powered feature, which is exactly what you want from infrastructure.

If you are building a developer tool or AI product and want early feedback plus a free, indexed profile, submit it to makers.page. Real usage, real feedback, and a dofollow link if it is a fit.

Related reading:

Originally published on makers.page. Want a free indie listing with human review? Submit your product.

My setup: a step-by-step journey building makers.page

Alex Cloudstar — Fri, 31 Jul 2026 16:54:51 +0000

People ask what my setup looks like more often than I expect for a project this small. Not because the stack is exotic, it is a fairly standard Next.js app on Vercel with a Postgres database, but because the process behind shipping it is the part that is harder to see from the outside.

This is the honest, step-by-step version: what I used, what I skipped, what broke, and what I would do differently if I started makers.page again today.

Step 1: Starting from a problem I actually had

makers.page did not start as a business plan. It started because I review indie products on YouTube and kept getting the same message: "how do I get you to look at my product?" There was no organized way to submit something, no queue, no public record of what got reviewed.

The first version was not a product. It was a form. Literally a Google Form linked from my YouTube description, feeding into a spreadsheet I checked manually.

That matters for the "setup" question, because the real first tool in my stack was not code. It was a way to validate that people would actually submit something before I spent a weekend building infrastructure for zero users.

Step 2: The actual stack

Once the form proved people would submit, I moved to a real app. The stack settled on:

Next.js (App Router) for the frontend and API routes in one project, deployed on Vercel
Tailwind for styling, because I do not want to context-switch into a separate CSS file for every component
shadcn for base UI primitives I did not want to build from scratch (buttons, dialogs, form inputs)
Neon Postgres for the database, mainly because serverless Postgres fits a Vercel deployment without me managing a server
Drizzle as the ORM, chosen over a heavier alternative because I wanted SQL-shaped queries I could actually read six months later

None of this is a special or clever choice. The main lesson from picking it was: boring, well-documented tools let me ship features instead of debugging my own infrastructure decisions.

Step 3: Building the submission and review flow first

The core loop of makers.page is simple: someone submits, I review it, approved products get a public profile. I built that loop first, before anything else, including before the homepage looked good.

Concretely, in order:

A public /submit form that writes to the database
An internal view (not fancy, just a filtered table) for me to see new submissions
An approval action that flips a status and generates a public profile page
The public /products directory and individual product pages

I did not build user accounts, payments, or admin dashboards in this phase. The entire point was: can one person submit, and can I approve it, end to end. Everything else was premature.

Step 4: Writing the description and SEO layer

Once the core loop worked, the next problem was discovery. A submission form nobody finds does not help anyone.

This is where the site picked up:

Structured metadata and JSON-LD on product pages so approved profiles are eligible for rich results
A sitemap and RSS feed generated from the actual content, not hand-maintained
Dofollow links on approved profiles, because nofollow links quietly hurt new founders more than most directories admit
A blog covering the exact problems the audience already searches for, like getting a product description approved or finding your first 100 users

None of this happened in week one. It happened after the core loop was proven, because SEO content written before you know your actual audience tends to guess wrong about what they search for.

Step 5: The daily workflow now

The day-to-day process looks less like "building a startup" and more like a routine:

Mornings: review new submissions, sign up for the product, actually try it, decide approve or pass
A block of deep work: fix bugs, ship one improvement, sometimes write a blog post
A short public update: one honest post about what shipped or what broke that day
Occasional YouTube review: for approved products that fit the channel, filmed as a real first-use, not a highlight reel

That daily update habit is the same discipline I wrote about in building in public without burning out. Separating the building block from the posting block keeps both sustainable.

What broke along the way

Being honest about the setup means being honest about what did not work on the first try:

The first version of the review flow had no status history, so I could not tell if a submission had already been reviewed and rejected before. Fixed by adding a proper status field instead of a boolean.
Early SEO metadata was copy-pasted across pages, which meant duplicate titles across products. Fixed by generating metadata per product from the actual submission content.
I underestimated how much time reviewing products actually takes. A queue that looks manageable at 10 submissions a week does not stay manageable at 50 without a lighter internal review view.
The original middleware.ts redirect logic needed migrating as the framework evolved, a reminder that even boring infrastructure needs occasional maintenance, not just feature work.

What I would change if I started over

If I rebuilt makers.page from scratch today, knowing what I know now:

I would build the internal review tooling earlier. It stayed a rough table for too long relative to how often I use it.
I would write the first two or three SEO blog posts before launch, not months after, since they take time to get indexed and start ranking.
I would keep the "one core loop first" discipline, which worked, and resist adding secondary features (accounts, notifications, anything non-essential) even earlier than I already did.

Frequently asked questions

What stack do you recommend for a project like this?

Whatever stack you already know well enough to move fast in. The specific tools (Next.js, Postgres, Tailwind) matter less than picking boring, documented technology you are not simultaneously learning and shipping with.

How long did it take to go from idea to a real product?

The Google Form version existed for a few weeks before the first real app version shipped. The core submission-to-approval loop took about a weekend of focused work once I committed to building it properly.

Do you use any project management tools?

Nothing elaborate. A simple task list and the submissions table itself function as the backlog. Overhead scales with team size, and this is a one-person operation.

How do you decide what to build next?

Whatever removes friction from the core loop (submit, review, approve, publish) comes first. Everything else waits until that loop is solid.

The honest summary

There is no secret tool behind makers.page. The setup that mattered was building the smallest possible version of the core loop first, being honest about what broke, and keeping the daily process simple enough to sustain for months instead of one exciting week.

If you are building something similar and want a low-effort distribution channel while you focus on your own core loop, submit your startup to makers.page. I try every product myself before anything goes live.

Related reading:

Originally published on makers.page. Want a free indie listing with human review? Submit your product.

How to get your first 100 users without a marketing budget

Alex Cloudstar — Fri, 31 Jul 2026 16:54:42 +0000

The first 100 users are the hardest. After that you have social proof, word of mouth, and enough data to know what is working. But users 1 through 100? You are selling from zero.

Paid ads, viral loops, and referral programs do not work at zero. They amplify signal that already exists. On day one, there is no signal to amplify.

Research on indie and SaaS growth in 2026 consistently points to the same truth: the first hundred users come from unscalable, hands-on channels. Direct outreach. Community participation. One well-timed launch. Directory presence. Content that compounds slowly.

This playbook breaks down what actually works when you have no budget, no audience, and no brand recognition.

Why the first 100 users are different

Distribution compounds. But compounding from zero is still zero.

On launch day you typically have:

No email list
No domain authority for SEO
No reviews or testimonials
No referral loop data
No ad conversion benchmarks

That is why generic growth advice fails early. "Run Facebook ads" burns budget testing messaging you could test for free in DMs. "Post on Product Hunt" without a working product wastes your one shot. "Build an SEO strategy" pays off in months, not days.

The first 100 require channels that work without an existing audience and teach you something about your market along the way.

The channel stack that works at zero

Rank channels by time-to-payoff and audience requirement:

Channel	Time to results	Needs existing audience?	Cost
Direct outreach (DMs, email)	Days	No	Free
Founder communities	1 to 4 weeks	No	Free
Curated directory listings	1 to 2 weeks	No	Free
Content / SEO	2 to 9 months	No	Free
Product Hunt / Show HN	1 day spike	Helpful	Free
Paid ads	Immediate spend	No	Expensive

Skip paid ads and slow SEO-only strategies until you have exhausted the fast, free, hands-on channels.

Phase 1: Users 1 to 10 (week 1 to 2)

Goal: learn whether real humans want this, not whether you can drive traffic.

Direct outreach to people you can name

List 20 specific people who match your ideal user profile. Not "founders." Not "marketers." Actual names.

DM 10 of them with a personal message:

Reference something specific they posted
Explain the problem you noticed
Offer free access in exchange for 10 minutes of feedback
Do not send a generic "check out my product" link

Conversion here is low and that is fine. One thoughtful conversation teaches more than 1,000 landing page visits.

Fix onboarding before you scale anything

Watch the first 5 users attempt signup. Note every point they hesitate, every error, every "wait, what do I do now?"

Fix those three friction points before you post anywhere public. Traffic to a broken funnel teaches nothing except that your funnel is broken.

Submit to one curated directory

Early users trust third-party listings. A profile on a reviewed directory says someone else looked at your product.

Submit to makers.page for a free indexed profile with a dofollow link if approved. Pair it with a clear description (writing guide).

Phase 2: Users 10 to 30 (week 3 to 4)

Goal: find repeatable language and one community that responds.

Community participation (not promotion)

Join 2 to 3 communities where your users already hang out:

Indie Hackers
Niche subreddits
Discord or Slack groups in your vertical
Dev.to or relevant forums for developer tools

Spend two weeks helping before you mention your product.

Answer questions. Share lessons. Post teardowns of problems in your space. The ratio that works in 2026 founder communities is roughly 90% value, 10% product mention.

When you do mention your tool, tie it to a specific problem in the thread. Not "I built X, check it out."

Publish one "what I learned" post

Posts that teach outperform posts that announce. Formats that work:

"I spent 3 months solving X. Here is what failed."
"How I reduced [pain] by [specific amount]"
"The mistake I made building [category tool]"

Publish on Indie Hackers, Dev.to, your own blog, or LinkedIn. Link to your product naturally at the end, not in the headline.

Talk to every user

At 10 to 30 users, you can still speak to everyone personally. Do it.

Ask:

What almost stopped you from signing up?
What would you tell a friend this product does?
Who else do you know with this problem?

Their exact words become your homepage copy, directory descriptions, and ad headlines later.

Phase 3: Users 30 to 60 (week 5 to 8)

Goal: add passive discovery channels while keeping hands-on effort.

Directory and listing expansion

Submit to 3 to 5 additional quality directories beyond makers.page. Use your description kit. Verify dofollow claims on live listings.

See the full tier list: Where to list your indie product

Start SEO content (parallel, not primary)

SEO will not get you to 30 users. Start it anyway so it pays off at 100+.

Write 2 to 3 posts targeting problems your buyers already search:

"How to [solve specific pain]"
"[Your category] for [specific audience]"
"[Competitor] alternative for [niche]"

Publish on your site blog. Internal link to your product page. These posts compound for months.

Examples on makers.page:

One launch milestone (optional)

If the product is solid and you have 20+ happy users who might upvote or comment, consider Product Hunt or Show HN.

Treat this as a milestone, not your entire strategy. Launch spikes fade. Community and SEO persist.

Ask for referrals manually

At 30 users, ask your best 5 customers:

"Who is one person you know who has this problem? Would you intro me?"

Referrals at this stage are manual. Automated referral programs come later.

Phase 4: Users 60 to 100 (week 9 to 12)

Goal: compound what worked. Kill what did not.

Double down on the one channel that sent signups

Review UTM data and user interviews. If Indie Hackers sent 15 users and Reddit sent zero, post more on IH. Do not spread evenly across ten channels out of guilt.

Competitor research outreach

Find 1-star reviews of competitors on G2, App Store, or Capterra. Read the specific complaints. If your product solves that complaint, reach out to the reviewer with a genuine note.

This is tedious. It works because the pain is already articulated.

Improve conversion on what you have

At 60 users, you have enough data to test:

Homepage headline variants
Signup flow simplification
Pricing page clarity
Onboarding email sequence

A 2x conversion improvement on existing traffic beats 2x traffic with the same broken funnel.

Layer directory SEO with content SEO

By week 12, you want:

An approved makers.page profile with dofollow link
2 to 3 blog posts indexed on your domain
Consistent presence in one community

These compound while you sleep. They will not replace outreach, but they stop you from resetting to zero every Monday.

What not to do (common traps)

Paid ads before product-market fit
You do not know your messaging, audience, or payback period. You will fund Google's learning phase with money you do not have.

Mass directory spam
100 low-quality listings with identical copy hurt more than 5 good ones. See directory strategy guide.

Launching before the product works
One-shot launch platforms punish unfinished products publicly.

Building in silence until "launch day"
The founders who hit 100 fastest ship in public, collect feedback early, and treat launch as a milestone in an ongoing story.

Optimizing for vanity metrics
Twitter impressions and Product Hunt rank do not pay rent. Track signups, activation, and conversations.

Metrics that matter at zero

Forget everything that scales past 1,000 users. Track:

Metric	Why it matters
Weekly signups	Raw growth pulse
Activation rate	Did they do the core action?
Time to first value	How fast do they "get it"?
User conversations per week	Qualitative signal
Referral intros	Product worth mentioning?
Channel attribution (UTM)	Where to double down

One real conversation beats 100 analytics events.

Sample 12-week calendar

Week	Focus	Target signups
1	10 personal DMs, fix onboarding	3 to 5
2	Submit makers.page, 1 community intro	5 to 8
3	Value post on IH or Reddit	8 to 12
4	5 more DMs, user interviews	12 to 18
5	3 directory submissions	18 to 25
6	First SEO blog post published	25 to 32
7	Community help + soft mention	32 to 40
8	Optional PH/HN launch	40 to 55
9	Referral asks to top 5 users	55 to 65
10	Second SEO post, homepage rewrite	65 to 75
11	Competitor review outreach	75 to 88
12	Double down on best channel	88 to 100+

Adjust based on your product type. B2B dev tools skew community and content. Consumer apps may skew social and referrals.

How makers.page fits the first 100 playbook

makers.page is not a viral growth hack. It is a free distribution layer that works while you do the hands-on work:

Submit in 2 minutes at /submit
Get a permanent profile if approved
Earn a dofollow backlink for SEO compounding
Reach founders browsing Products
Optional YouTube review from alexcloudstar

Use it in week 1 or 2 alongside outreach. Not instead of outreach.

Frequently asked questions

Can I really get 100 users with zero budget?

Yes, but expect 8 to 12 weeks of consistent manual effort. There is no shortcut, only a sequence.

What is the single highest-leverage channel?

Direct outreach for users 1 to 10. Community participation for 10 to 50. Content and directories for compounding after that.

When should I start paid ads?

After 100+ users when you know your CAC, LTV, and conversion funnel. Not before.

Is Product Hunt necessary?

No. Helpful as a milestone if your product is ready. Not a replacement for daily distribution work.

How does SEO help if it takes months?

Start early so traffic trickles in at user 100 while you focus on outreach. SEO is parallel, not primary, at zero.

The honest summary

The first 100 users come from work that does not scale:

Personal messages to people who match your ICP
Genuine help in communities where they gather
Clear listings on curated directories
Content that targets problems they already search for
Conversations with every early user

By user 100, you will know your market better than competitors who bought their way to vanity metrics. That knowledge is worth more than the users themselves.

Start today. Submit your startup to makers.page. Send 5 DMs. Post one useful thing in one community. Repeat tomorrow.

Related reading:

Originally published on makers.page. Want a free indie listing with human review? Submit your product.

How to get your indie startup featured

Alex Cloudstar — Fri, 31 Jul 2026 16:54:04 +0000

You built something. Now you need the right people to find it.

Getting featured is not about having the biggest pitch deck or the most funding. It is about having a real product, explaining it clearly, and showing up where indie founders and early adopters already look.

This guide walks through what makers.page offers, what the review process looks like, and how to give your submission the best shot at approval.

Why indie founders submit to startup directories

A new domain has almost no search authority. Google does not know who you are yet. Directories and curated listings help in three ways:

Discovery: people browsing category pages find products they would never hit from a cold Google search
Backlinks: a dofollow link from an indexed profile passes trust signals to your site
Social proof: a third-party listing says someone else looked at your product and put their name on it

Research on startup directory submissions in 2026 consistently shows the same pattern: quality beats quantity. Founders who submit to 10 to 20 relevant directories with unique descriptions outperform those who blast 100+ sites with identical copy. Spammy mass submission can hurt more than it helps.

makers.page sits in the curated, indie-focused camp. Submissions are free. Profiles link out with dofollow when approved. Every listing is reviewed by a real person who signs up and tries the product.

What you get when your startup is approved

If your product is a fit, approval unlocks:

A public product profile

Your listing goes live on Products with your product name, founder name, description, categories, and a link to your website. These pages are indexed, included in the sitemap, and built to rank over time for branded searches like "your product name makers.page."

A dofollow backlink

Many startup directories nofollow outbound links by default. Some paywall dofollow status behind a paid tier. On makers.page, approved profiles include a dofollow link to your website. That matters early on when you are building your first meaningful backlink profile.

A shot at a YouTube product review

Beyond the directory listing, approved products may be reviewed on YouTube by alexcloudstar. The review is honest: the product gets used, not just screenshotted. That is different from a directory that auto-approves everything and never opens your app.

There is no guarantee every approved product gets a video. The directory profile and dofollow link are the baseline. The review is a bonus for products that fit the channel.

What reviewers actually look for

Most rejections are not about the product being bad. They are about clarity, readiness, or fit. Here is what matters:

1. A real product people can use today

Landing pages for products that do not exist yet are hard to review fairly. Waitlists are fine if you say so upfront. The strongest submissions point to something a reviewer can sign up for, install, or try in under five minutes.

Ask yourself: if a stranger clicked your URL right now, could they understand and use the product without a demo call?

2. A clear use case

The best descriptions follow a simple pattern: who it is for + what it does + what outcome they get.

Vague copy like "AI-powered platform for modern teams" tells a reviewer nothing. Specific copy like "Chrome extension that gamifies posting on X for solo founders who want consistency" tells them exactly where you fit.

Need help writing yours? See How to write a product description that gets approved.

3. Indie builder energy

makers.page is built for solo founders, small teams, and side projects shipping in public. You do not need revenue, funding, or a LinkedIn full of credentials. You need something genuine that solves a real problem for a defined audience.

Side projects welcome. Half-baked MVPs with honest descriptions often beat polished landing pages with nothing behind them.

4. Accurate categories

Pick categories that match how people search, not how you wish they searched. A Jira productivity extension belongs in Productivity and Developer Tools. A social growth tool belongs in Social Media or Browser Extension. Wrong categories slow review because the reviewer has to reverse-engineer what you built.

How to submit (step by step)

Submission takes about two minutes. Here is the full flow:

Go to the submit page
Enter your name and email
Add your product name and website URL
Write a short description (one or two sentences is enough to start)
Select all categories that fit
Add your X handle if you have one
Hit send

That is it. No credit card. No upgrade tier. No "pay to skip the queue."

What to prepare before you submit

Even though the form is short, a little prep improves approval odds:

Homepage clarity: one sentence above the fold that says who it is for
Working signup or install flow: test it on mobile
Description draft: use the who/what/outcome formula
Correct URL: link to the product page, not a broken staging site

What happens after you submit

Here is the timeline most founders can expect:

Review

A real person signs up for your product and uses it. That is the whole point. Directory listings where nobody opens the app are worthless for everyone.

Approval

If it is a fit for the directory (and potentially the YouTube channel), your profile goes live on Products. You get a public URL, indexed page, and dofollow link.

Feedback if it is not a fit yet

Not every product belongs on every directory. If yours is not approved, you should still get useful feedback rather than silence. Use it to tighten your positioning, fix onboarding, or resubmit when the product is further along.

How makers.page compares to other listing options

Founders often ask how this differs from Product Hunt, Indie Hackers, or paid submission services.

Channel	Best for	Link type	Cost
Product Hunt	Launch day spike	Often dofollow	Free
Indie Hackers	Build-in-public community	Mixed	Free
Paid submission agencies	Volume listings	Varies	$35 to $500+
makers.page	Permanent indie profile + review shot	Dofollow if approved	Free

The smart play is not either/or. Use a launch platform for momentum, communities for feedback, and a curated directory like makers.page for a permanent indexed profile with a dofollow link.

More context: Where to list your indie product (and what to skip)

Common mistakes that slow approval

Buzzword descriptions with no specific user or outcome
Broken or password-gated demos the reviewer cannot access
Wrong categories that hide what the product actually does
Identical copy pasted from your homepage tagline with zero context
Submitting too early before the core action works

Fix these before you submit and you are already ahead of most listings in the queue.

Frequently asked questions

Is submission really free?

Yes. Always. There is no paid tier for visibility, dofollow status, or placement.

How long does review take?

It depends on queue volume. Reviews require signing up and using the product, so timing varies. Submit once with a clear description rather than resubmitting the same product repeatedly.

Do I need traction or revenue?

No. Early-stage and pre-revenue products are welcome if the product works and the use case is clear.

Can I submit a side project?

Yes. Side projects and solo-founder tools are exactly what makers.page is for.

What if I am not ready for YouTube?

That is fine. The directory profile and dofollow link are valuable on their own. The YouTube review is optional, not required.

Can I update my listing later?

Contact through your submission email if your product name, URL, or description changes significantly after approval.

One small ask before you submit

Running a free directory and review channel takes time. Before you submit, consider subscribing on YouTube and following on X. Fair trade for a free submission, a dofollow profile, and honest feedback.

Ready to submit?

If you have a real product, a clear description, and two minutes, you are ready.

Submit your startup for free. Yours could be next on the list.

Originally published on makers.page. Want a free indie listing with human review? Submit your product.

How to buy a micro SaaS: a practical acquisition guide

Alex Cloudstar — Fri, 31 Jul 2026 16:54:00 +0000

Buying a small, profitable SaaS is often faster than building one from zero. You skip the part where you guess whether anyone wants the product, because paying customers already answered that question. The trade-off is you inherit someone else's code, someone else's churn, and sometimes someone else's technical debt.

This guide walks through where micro SaaS businesses actually get listed, how to evaluate a deal before you fall in love with the revenue number, what due diligence to run, and how to negotiate without overpaying for a business that might not survive the transition.

What counts as a micro SaaS acquisition

There is no strict cutoff, but in practice "micro SaaS" acquisitions in 2026 typically mean:

Monthly recurring revenue from a few hundred dollars up to roughly $20,000
A small, often solo-maintained codebase
One founder or a tiny team running support, sales, and development
A sale price commonly in the 2x to 4x annual revenue range, though this varies a lot by growth rate, churn, and how much of the business depends on the founder personally

Above that range you are closer to a small business acquisition with lawyers, escrow services, and formal due diligence on both sides. Below it, the deal often looks more like buying a side project than buying a company.

Where micro SaaS businesses get listed

Deal flow comes from a handful of consistent sources:

Dedicated acquisition marketplaces. Platforms built specifically for buying and selling small SaaS and content businesses, where sellers list revenue, traffic, and asking price upfront.
Indie founder communities. Indie Hackers, niche Slack and Discord groups, and X threads where founders mention they are ready to sell, often before a listing goes anywhere public.
Direct outreach to founders who seem to have stalled. A product with a stale changelog, an unanswered support inbox, or a founder who has publicly said they are burned out is sometimes open to an offer nobody asked them for.
Broker-assisted sales. For larger micro SaaS deals, brokers who specialize in small SaaS transactions can filter for legitimacy and handle structuring in exchange for a commission.

Public marketplaces are the easiest starting point because the numbers are disclosed upfront. Direct outreach tends to produce better prices because there is no bidding pressure, but it takes longer and requires more legwork.

What actually predicts whether a micro SaaS is worth buying

Revenue is the headline number. It is not the number that predicts whether you will regret the purchase in six months. Weigh these instead:

Revenue concentration and churn

A product earning $3,000 a month from 300 customers paying $10 is a fundamentally different asset than one earning $3,000 a month from three customers paying $1,000. Ask for a customer list with tenure and payment history, not just a revenue chart. High concentration means your entire business depends on whether two or three people stay happy.

Churn matters more than the current MRR. A product losing 8% of revenue monthly needs constant new signups just to stay flat. Ask for at least 12 months of churn data, not a snapshot.

How much depends on the founder

Some products run themselves. Others run because the founder personally handles every support ticket, manually onboards every customer, or is the reason people trust the brand on social media. Ask directly: what happens to signups, support response time, and churn if the founder disappears for a month? If the honest answer is "it falls apart," you are not buying a business, you are buying a job.

Codebase health, not just feature count

A long feature list built by one person over three years, with no tests, no documentation, and dependencies several major versions behind, is a liability disguised as an asset. Get read access to the repository before you commit to a price, not after. If the seller resists a code review, treat that as a signal.

Traffic and acquisition channel dependency

If most signups come from one channel (a single SEO ranking, one App Store category, or one influencer partnership), that revenue is more fragile than it looks. Ask for traffic source breakdowns over the last 12 months, and check whether any single channel accounts for more than half of new signups.

Due diligence checklist before you make an offer

Run through this before any money changes hands:

Financials: request bank or payment processor statements, not just dashboard screenshots. Screenshots can be edited or cherry-picked.
Customer list: verify real customers exist by reaching out (with permission) to a handful directly, or ask the seller to send a short survey on your behalf.
Codebase: get repository access, check commit history for a single point of failure, and confirm there is no undisclosed technical debt (unpatched security issues, expired API keys tied to the founder's personal accounts, or a dependency on a service being shut down).
Legal ownership: confirm the seller actually owns the domain, trademarks if any, and all code, including any contractor-written portions that might carry separate licensing terms.
Contracts and obligations: check for any outstanding customer contracts, refund obligations, or reseller agreements that transfer to you.
Support load: ask for average tickets per week and current response time. A backlog you inherit on day one is a hidden cost.

Do not skip this checklist because a deal feels time-pressured. A seller pushing hard for a fast close with limited access to real data is one of the more reliable warning signs in small acquisitions.

How to think about valuation

Micro SaaS deals commonly trade in a rough multiple-of-annual-revenue range, but the multiple should move based on the risk factors above, not just the topline number.

Factor	Pushes multiple up	Pushes multiple down
Churn	Low, stable	High, trending worse
Customer concentration	Broad base	Two or three accounts
Founder dependency	Fully automatable	Founder is the product
Growth trend	Growing steadily	Flat or declining
Codebase quality	Clean, tested, documented	Undocumented, fragile
Traffic source	Diversified	Single channel

A product with strong metrics on every row can justify a higher multiple. A product with green revenue but red flags on churn, concentration, or founder dependency should trade lower, even if the seller's initial ask does not reflect that.

Negotiating the deal

A few practices that consistently lead to fairer outcomes on both sides:

Anchor on verified numbers, not the seller's marketing pitch. Negotiate off the bank statements and churn data you confirmed, not the highlight reel in the listing.
Structure part of the payment as an earnout. Paying a portion upfront and the rest over 3 to 12 months tied to retained revenue protects you if the business underperforms right after the handoff, and it signals the seller believes in what they are selling.
Ask for a transition period. A few weeks of the founder staying available for support and knowledge transfer reduces the risk of the "founder dependency" problem above turning into a real crisis.
Put it in writing. Even a simple asset purchase agreement covering what is transferred, payment terms, and post-sale support expectations prevents disputes later. Use a lawyer for anything above a few thousand dollars.

Common mistakes buyers make

Falling for revenue without checking churn. A high MRR with high churn is a treadmill, not an asset.
Skipping the codebase review. You cannot price technical debt you have not seen.
Underestimating founder dependency. The seller's charm and support responsiveness do not transfer with the sale.
Overpaying for growth that was paid-acquisition-driven. If growth came from ad spend the new owner has to keep funding, the growth rate alone tells you little about organic durability.
Rushing the close because of seller pressure. Legitimate sellers with clean businesses can usually accommodate a reasonable diligence timeline.

After the acquisition: the first 90 days

Buying the product is the easy part. Keeping customers through a handoff is where deals succeed or quietly fail.

Communicate the transition early and honestly, ideally with the previous founder introducing you rather than a surprise email from an unfamiliar name.
Do not change pricing, branding, or core features in the first month. Stability during the handoff matters more than any quick win you are tempted to ship.
Watch churn weekly, not monthly, for the first quarter. Early warning signs of a bad transition show up fast.
Keep the support response time consistent with what customers were used to. A slower response time post-acquisition is one of the most common triggers for early churn.

Frequently asked questions

How much revenue do I need to consider buying a micro SaaS?

There is no minimum. Deals exist from a few hundred dollars a month up to tens of thousands. Smaller deals carry lower financial risk but often more founder-dependency risk, since tiny products are frequently run entirely by one person.

What multiple should I expect to pay?

Roughly 2x to 4x annual revenue is common for healthy micro SaaS businesses, but the right multiple depends heavily on churn, concentration, and founder dependency, not just the topline number.

Should I use a broker?

For larger deals, a broker who specializes in small SaaS transactions can add legitimacy and handle structuring. For smaller deals, many buyers negotiate directly with the seller and use a lawyer only for the final agreement.

What is the biggest risk in a micro SaaS acquisition?

Founder dependency. A product that looks automated on paper but actually runs on one person's daily manual effort can fall apart within weeks of a handoff if that is not addressed in the deal structure.

Can I finance a micro SaaS acquisition?

Some buyers use seller financing (paying part of the price over time from the business's own cash flow) or earnouts tied to retained revenue. Traditional bank financing is less common at this deal size but not unheard of for larger acquisitions.

The honest summary

A good micro SaaS acquisition is not the one with the biggest revenue number. It is the one where churn is low, the customer base is not concentrated in two accounts, the codebase does not require a full rewrite, and the founder is not secretly the entire product. Verify all four before you negotiate price, structure part of the payment as an earnout when you can, and protect the first 90 days after close more carefully than you protected the deal itself.

If you end up building or buying something in the micro SaaS space, submit it to makers.page for a free profile and a shot at an honest product review.

Related reading:

Originally published on makers.page. Want a free indie listing with human review? Submit your product.

Why dofollow backlinks still matter for indie startups

Alex Cloudstar — Fri, 31 Jul 2026 16:53:31 +0000

You listed your product on five directories last month. Traffic spiked for two days. Your Google rankings did not move.

That gap usually comes down to link type, link quality, or both. Not every directory backlink helps SEO. Some help discovery. Some help trust. Only some pass ranking authority.

This guide explains dofollow vs nofollow links, what makes a backlink worth pursuing, and how indie founders should think about directory SEO in 2026.

What is a dofollow backlink?

When Site A links to Site B, Google reads that link as a signal. A dofollow link (technically, a link without a rel="nofollow" attribute) tells search engines to pass authority from the linking page to your site.

A nofollow link tells Google not to pass that authority. The link can still drive clicks, brand mentions, and discovery. It just does not count the same way for rankings.

Most large platforms default to nofollow on user-generated or outbound links to control spam. That is why Product Hunt, Reddit, Hacker News, and many review sites often nofollow free-tier listings even when they send real traffic.

For a brand-new indie domain with zero domain rating, even one or two relevant dofollow links from indexed pages can matter more than fifty nofollow mentions on low-quality sites.

Why new startups need backlinks at all

Search engines discover and rank pages partly based on links from other sites. A new startup domain has:

No domain authority
No indexed history
No external references

Directory submission is one of the few legitimate ways to earn early backlinks without buying links or spamming forums. Industry guides for 2026 consistently recommend focusing on 10 to 20 quality, relevant directories rather than mass-submitting to hundreds of low-authority lists.

The goal is not backlink count. It is relevance, crawlability, and trust.

Dofollow vs nofollow: when each one matters

Link type	SEO authority	Referral traffic	Brand discovery	Best use case
Dofollow	Passes ranking signals	Yes	Yes	Building early domain trust
Nofollow	Minimal direct SEO pass	Yes	Yes	Launch traffic, community discovery
Mixed platforms	Varies by page/tier	Yes	Yes	Verify live listing before counting on SEO

Smart founders use both. Dofollow directories build foundational authority. Nofollow platforms like Reddit or Hacker News drive spikes and conversations. Treating every link the same leads to wasted effort on listings that never move SEO.

The paywall trap

Several directories advertise backlinks but nofollow the free tier. Some require payment for dofollow. Others only grant dofollow if you embed their badge or finish top three on launch day.

Always verify the rel attribute on a live listing before assuming SEO value. Marketing pages lie. HTML does not.

What makes a good backlink for an indie product

Not all dofollow links are equal. Google evaluates:

1. Relevance

A link from a startup or SaaS directory helps a indie tool more than a link from a generic business directory in an unrelated niche.

2. Crawlability

The linking page must be indexed. Check that the directory includes listings in its sitemap, allows crawling in robots.txt, and does not hide profiles behind login walls.

3. Context

Your product name, description, and category tags near the link help search engines understand what your site is about. A naked URL on a link farm page helps nobody.

4. Authority (without obsessing over DR)

Domain Rating and Domain Authority are useful heuristics, not gospel. A moderate-DR niche directory with real editorial review often beats a high-DR page with thousands of spam listings.

5. Permanence

Launch-day spikes fade. A permanent profile page that stays indexed year after year compounds slowly but reliably.

Where indie founders waste backlink effort

These patterns show up constantly in founder forums and SEO guides:

Mass submission to 100+ directories with identical descriptions (duplicate content footprint, low approval rates)
Chasing DR numbers on irrelevant or spammy sites
Paying for "guaranteed dofollow" packages from networks Google already devalues
Ignoring nofollow entirely and missing high-traffic community platforms
Submitting before the product works, getting rejected, and never updating the listing

Quality and consistency beat volume every time.

A practical backlink strategy for week one

If you are launching an indie product with no SEO history, start here:

Step 1: Fix your own site first

Before chasing backlinks, make sure your homepage has:

A clear title tag with your product name
A meta description with your primary keyword
One sentence explaining who it is for
A working signup or install flow

Links to a confusing page waste the authority they pass.

Step 2: Pick 10 to 15 targets

Mix dofollow directories, community platforms, and one launch channel. Prioritize sites where your actual users browse, not just sites with high DR on a spreadsheet.

Step 3: Prepare unique descriptions

Use the same core message but adapt length and emphasis per platform. Identical copy-paste across every directory creates a thin duplicate content pattern. See How to write a product description that gets approved for templates.

Step 4: Submit manually over 2 to 4 weeks

Spacing submissions looks more natural than blasting 50 forms in one afternoon. Track which listings go live and verify link attributes.

Step 5: Layer content and community

Backlinks alone do not build a business. Pair directory listings with community participation and content that earns links organically over time.

How makers.page handles backlinks

makers.page is built for indie founders who want a permanent, indexed profile with a dofollow link when approved.

What that means in practice:

Your product gets a dedicated URL on makers.page
The page is included in the site sitemap
Approved listings link to your website with a dofollow outbound link
Profiles include your description, categories, and founder name for context
Submission is free with no paid tier for link equity

It is not a mass directory. Submissions are reviewed. That editorial filter is exactly what makes the link trustworthy to both users and search engines.

Browse live examples on Products.

Dofollow directories worth knowing about (2026 landscape)

Every platform changes policies. Treat this as a starting research list, not a guarantee:

Platform type	Typical link type	Notes
Curated indie directories	Often dofollow	Verify per listing
SaaS review sites (G2, Capterra)	Mixed	High intent, strict approval
Launch platforms (Product Hunt)	Often dofollow	One-day spike, long-tail profile
Community posts (Reddit, HN)	Usually nofollow	Traffic and discovery
Generic free directory lists	Often low quality	Avoid spam networks

Founders who test submissions firsthand report that verifying live rel attributes matters more than trusting "dofollow" badges in directory marketing copy.

makers.page belongs in the curated indie bucket: free submission, human review, dofollow on approval.

Backlinks and AI search (2026)

Search is shifting. AI overviews and answer engines cite brands with clear entity signals: consistent name, URL, description, and third-party mentions across the web.

Directory listings help here even when SEO impact is hard to measure. They create indexed mentions of your product name linked to your domain. That consistency helps search engines and AI systems understand what you are.

Think of directory SEO as entity building, not just PageRank chasing.

Checklist: before you submit anywhere

[ ] Product URL loads and core action works
[ ] Description follows who/what/outcome format
[ ] Categories match the product honestly
[ ] You prepared short and long description variants
[ ] You checked the directory's link policy on a live listing
[ ] You plan to update the listing when pricing or features change

Frequently asked questions

Are dofollow links still important in 2026?

Yes, especially for new domains building initial authority. They are one signal among many, but they still matter for early-stage SEO.

How many dofollow links do I need?

There is no magic number. Five to ten quality, relevant links often outperform fifty low-quality ones for a new indie product.

Can nofollow links hurt me?

No. They just pass less direct ranking authority. They can still drive traffic and brand awareness.

Should I pay for directory submission services?

Some founders use them to save time. If you do, audit the directory list for quality and verify dofollow claims yourself. Never pay for spam networks.

How long until backlinks affect rankings?

Weeks to months. SEO compounds slowly. Directory links are a foundation, not an overnight ranking trick.

Start with one good link

Backlink building for indie startups is a patience game. Start with one curated, dofollow, indexed profile on a site that actually reviews your product.

Submit to makers.page for free. Build from there.

Originally published on makers.page. Want a free indie listing with human review? Submit your product.

Building in public without burning out

Alex Cloudstar — Fri, 31 Jul 2026 16:53:27 +0000

Building in public sounds simple: ship, post, repeat. In practice, it turns into a second job. You are coding all day, then performing your progress all night. Six months in, a lot of founders quietly stop posting, not because the product failed, but because the public part burned them out first.

Building in public is a distribution channel, not an identity. Treat it that way and it becomes sustainable. Treat it as a personality and it becomes a source of anxiety that outlasts most products.

This guide covers how to share progress publicly without letting the audience run your schedule, your mood, or your roadmap.

Why building in public burns founders out

The appeal is obvious: free distribution, accountability, and a community that roots for you. The cost is less obvious until you are a few months in.

Three patterns cause most of the burnout:

Metrics become the product. You start optimizing for likes and replies instead of the thing you are actually building.
Every day becomes a content day. Shipping code and shipping a post about the code both need to happen, every day, forever.
Silence starts to feel like failure. A quiet week on X feels like falling behind, even if the product moved forward more than usual.

None of these are inherent to building in public. They are side effects of doing it without boundaries.

Separate "building" from "public"

The healthiest founders treat these as two different jobs with two different schedules.

Building is deep work: writing code, talking to users, fixing bugs, thinking through the roadmap. It needs long uninterrupted blocks and almost no audience awareness.

Public is communication: turning what you built into a post, a screenshot, a short thread. It needs short, scheduled blocks and can happen after the building is done for the day.

Mixing the two means you are context-switching between "solve this hard technical problem" and "how do I phrase this for maximum engagement" all day long. That is exhausting in a way that neither task alone is.

Block time for each. A common split that works: build in the morning with notifications off, write and post in the afternoon for 20 to 30 minutes, then close the laptop on the public side entirely.

Post on your schedule, not the algorithm's schedule

Platforms reward frequency. Founders who post daily often out-perform founders who post weekly, at least in short-term reach. That does not mean daily posting is required, or healthy, for you.

A few ways to lower the pressure without disappearing:

Batch content on a good day. Write three or four posts when you are energized, queue them for the week.
Post progress, not performance. A one-line update ("fixed the onboarding bug that was losing 20% of signups") is honest and low-effort. It does not need a hook, a thread, or a call to action every time.
Skip days without announcing it. You do not owe your audience an explanation for a quiet Tuesday. Silent gaps are normal. Apology posts about silent gaps train you to feel guilty about rest.

Consistency over months beats intensity over weeks. Aim for a pace you can hold in December, not just in launch week.

Detach your mood from engagement numbers

This is the hardest habit to build and the one that determines whether building in public is sustainable for you.

A post with 3 likes and a post with 300 likes can represent the same amount of work and the same amount of progress. The number reflects timing, platform mood, and luck as much as it reflects quality.

Practical ways to reduce the emotional grip of metrics:

Check analytics once a week, not per post. Real signal shows up over weeks, not in the first hour.
Track leading indicators instead. Signups, activation rate, and real conversations tell you more about the business than likes do. See the first 100 users playbook for the metrics that actually matter early on.
Write the post before you check the last one's numbers. Starting your day by reviewing yesterday's engagement anchors your mood to something you do not control.

If a specific platform consistently makes you anxious to open, that is useful data. Post less there, not more.

Build a support system outside your audience

Public followers are not the same as friends, co-founders, or peers. They see your highlight reel. They rarely see the 2am bug you cannot reproduce or the rejection email from a customer you were counting on.

Founders who last longer in public building tend to have:

One or two people who know the real numbers. Not the audience-facing version. The actual MRR, churn, and stress level.
A community of peers building similar things. Indie Hackers, niche Discords, or small group chats where the conversation is "here is what actually happened" rather than a highlight.
Something completely unrelated to the product. A hobby, a sport, a person, anything that does not know or care what your signup count is this week.

If your only outlet for frustration is the same platform you post your wins to, you will either bottle it up or perform your struggles too, which just becomes another form of content labor.

Set a content floor, not a content ceiling

Most advice about building in public is about how to post more. The advice that actually prevents burnout is about deciding the minimum you will do, then treating anything beyond that as a bonus rather than an obligation.

A sustainable floor might look like:

One update post per week, minimum
One longer reflection per month
Replying to comments when you have the energy, not as a rule

Anything you do above that floor is a good week, not a baseline you now have to defend every week going forward. Ratcheting your own expectations up after a single viral post is one of the fastest paths to burnout, because you are now competing with your own outlier.

Use "in public" for leverage, not obligation

The actual value of building in public is compounding distribution: each post is a small, permanent asset that can bring people to your product months later through search, shares, or someone scrolling back through your history.

That means low-effort, honest posts written over a year add up to more distribution than a burst of high-effort posts written over a burnout-inducing month and then abandoned.

Ways to get leverage without grinding:

Turn build logs into evergreen content. A post about a specific bug fix can become a blog post that ranks in search long after the tweet is buried.
Reuse the same update across formats. One update becomes a tweet, a line in a changelog, and a sentence in your next newsletter. Write it once.
Let directories and listings work while you sleep. A makers.page profile with a dofollow link keeps working for discovery even on weeks you post nothing publicly.

Signs you need to step back

Building in public should feel like sharing progress, not managing a second audience-facing business. Watch for these signs:

You feel relief, not disappointment, when a post underperforms because it means less pressure to keep the streak going
You are writing posts about problems before you have actually solved them, just to have something to say
You dread opening the app you built because you associate it with the performance around it, not the product itself
You have not shipped a real feature in weeks because content creation absorbed the time

If any of those are true, cut posting frequency in half for a month. The audience that matters will still be there. The one that only cared about the streak was never going to convert anyway.

A realistic weekly rhythm

Here is a rhythm that keeps the public side sustainable without disappearing entirely:

Day	Building focus	Public output
Mon	Deep work, no distractions	None
Tue	Deep work	One short update
Wed	User calls, feedback	None
Thu	Deep work	One short update
Fri	Ship, review week	One reflection post
Sat	Off, or light bug fixes	None
Sun	Off	None, or queue next week

Adjust to your own energy. The point is a rhythm you can repeat for a year, not a schedule copied from someone whose situation is different from yours.

Frequently asked questions

Do I have to post every day to get traction?

No. Consistency over months matters more than frequency in any single week. A steady weekly cadence beats a daily streak that collapses after six weeks.

What if nobody engages with my posts?

Low engagement early on is normal and rarely means the product is bad. Keep the floor low, keep showing up, and focus on leading indicators like signups and user conversations instead of likes.

Is it okay to take a break from posting publicly?

Yes. A quiet week does not undo months of consistent presence. Audiences that disappear over a short break were not going to be long-term customers anyway.

How do I stop caring about metrics?

You will not stop caring entirely, but you can reduce the frequency you check them and separate your daily mood from any single post's performance. Weekly reviews instead of per-post checks help.

What is a low-effort way to keep building in public without burning out?

Batch a few short, honest updates when you have energy, queue them, and let evergreen assets like blog posts and directory listings do additional distribution work in the background.

The honest summary

Building in public works as a distribution channel precisely because it is real: real progress, real setbacks, real numbers. The moment it becomes a performance you cannot sustain, it stops being honest and starts being a second job you did not sign up for.

Protect the building. Schedule the public. Detach your mood from the metrics. Set a floor, not a ceiling. Do that, and building in public becomes something you can keep doing for years, not something you burn out on in six months.

If you want one low-effort distribution asset that works while you focus on building, submit your startup to makers.page for a free profile and a shot at an honest review.

Related reading:

Originally published on makers.page. Want a free indie listing with human review? Submit your product.

I Just Shipped My First Chrome Extension (And It Was Harder Than the Code)

Alex Cloudstar — Mon, 27 Jul 2026 10:29:13 +0000

I just shipped my first Chrome extension.

Not a tutorial toy. Not a "hello world" that never left chrome://extensions. A real Manifest V3 product with Sign in with X, local XP tracking, cloud sync, a privacy policy, and a listing live on the Chrome Web Store.

The product is called XPilot. It turns your activity on X into a game: XP for posts, replies, likes, and reposts. Levels. Streaks. A popup that shows your progress in one click.

And yes: it is free. Add it from the Chrome Web Store, sign in with X, and start earning XP on the stuff you already do. No waitlist. No credit card.

This post is the story of what I expected, what actually broke, and what I would tell myself on day one.

If you are about to build your first extension, steal the lessons. Skip the landmines. If you just want the product: install XPilot free.

Why an extension (and not another web app)

I care about growth on X. Most tools in that space try to write for you. That was never the itch.

The real problem, for me and for a lot of founders I talk to, is consistency. You know you should reply more. You know streaks matter. You still flake when the day gets loud.

So the bet was simple:

Make X feel like a game people already understand: XP, levels, streaks.

And the distribution bet was equally simple:

Put the product where the habit already happens. Inside Chrome. On x.com.

A dashboard you have to remember to open loses to a popup that opens when you are already posting.

That is why XPilot is an extension first, website second.

The stack (keep it boring)

I did not invent a framework.

Extension: WXT + TypeScript, Manifest V3.

UI: plain HTML, CSS, and JS in the popup. Fast, no React tax for v0.1.

Content script: detect my own activity on x.com and twitter.com.

Backend: Next.js on Vercel.

Auth: X OAuth 2.0 with PKCE, then an app JWT.

DB: Postgres on Neon, Drizzle ORM.

Sync: local-first, with a backup about every 12 hours.

WXT was the right call. It handles the annoying MV3 packaging, hot reload in development, and zip for the store. If you are starting today, do not hand-roll Webpack for an extension unless you enjoy pain.

What "done" meant for v0.1

I forced a tiny definition of done:

Sign in with X works
Popup shows XP, level, streak
Activity on X awards XP
Progress survives a reload
Privacy + Terms exist (store requirement)
A ZIP builds without localhost host permissions
A stranger can install from the store and log in

Everything else was a later problem. Opportunity radar, AI coach, seasons: later. Shipping was the boss fight.

Hard part 1: Manifest V3 is not "Chrome apps 2.0"

If your last mental model of extensions is Manifest V2, throw it away.

MV3 service workers go idle. You cannot assume a long-lived background page. Alarms exist for a reason. Persistent connections are not free.

Permissions matter more than you think. Every host permission is a trust tax on the listing review and on users. I kept production hosts to:

x.com / twitter.com (where the game runs)
xpilot.so / www.xpilot.so (where the API lives)

Dev-only: localhost:3000.

That last detail almost bit me in production. More on that below.

Hard part 2: Sign in with X inside Chrome

Browser OAuth is familiar. Extension OAuth is a different animal.

XPilot uses chrome.identity.launchWebAuthFlow. The flow looks clean on a whiteboard:

Extension opens your site's /api/auth/x
Site redirects to X
X redirects back to your callback
Callback redirects to https://<extension-id>.chromiumapp.org/?code=...
Extension exchanges the code for a JWT

In practice, three things tried to murder me.

1. Callback URL must match `APP_URL` exactly

Our production site redirects xpilot.so → www.xpilot.so.

If your OAuth redirect_uri is registered as one host and your app builds the other, X shows a vague "you weren't able to give access to the App" page. No stack trace. No mercy.

Fix: pick one canonical origin. Put it in APP_URL. Register that exact callback on developer.x.com. Stop arguing with DNS.

2. Do not put the exchange code in a URL hash

I originally returned the short-lived exchange code as a hash fragment (#code=...). Fragments are cute until redirects strip them and chrome.identity hands you an empty URL.

Fix: put the code in the query string (?code=...). Parse query first, hash as fallback.

3. Host permissions and CORS will gaslight you

Vercel logs told the truth:

OPTIONS /api/auth/exchange → 204
No POST after it

The store build talked to www, while the manifest only allowed the apex. Chrome fell back to CORS. Preflight "succeeded." The real POST never flew. The popup still showed Sign in with X like nothing happened.

Fix:

Default the production API base to https://www.xpilot.so
Allow both apex and www in host permissions
Add CORS for your published extension ID on the exchange and sync routes as a belt-and-suspenders layer
Pin ALLOWED_EXTENSION_IDS in production so random extensions cannot finish OAuth

Also: the popup often closes when the auth window opens. Your background script must finish login even if the UI is gone. When the user reopens the popup, auth should already be in chrome.storage.

Hard part 3: Detecting activity on a hostile DOM

X's frontend is not an API contract. It is a living organism.

Content scripts that award XP for replies have to survive:

Timeline composers
Modal composers
Cmd/Ctrl+Enter submits
Buttons that unmount before your observer finishes
False positives when someone cancels

I shipped a fail-closed version that broke real replies. Then a looser version that missed intermittent posts. Then a multi-signal version: busy state, clear state, dialog stack, keyboard submit.

If you are building anything on top of a third-party SPA, budget time for "the UI changed and nothing is wrong in your TypeScript."

Hard part 4: Local-first is why a free tier can stay free

I did not want a backend call on every like. I also did not want "free" to mean "runs my GPU bill into the ground."

So XP lives in the extension first. Sync is a backup, not the gameplay loop.

Rules that kept costs and complexity down:

Score actions locally
Sync when due (about every 12 hours), on startup, and after login
Cap what a sync can inflate on the server
Never make the free product depend on continuous API traffic

That architecture is why I can ship v0.1 as a free Chrome extension without feeling like every install is a liability. The game still feels instant when the network is sad. The expensive ideas (AI opportunity radar, deep coaching) can wait until people are actually addicted to the loop.

Hard part 5: The Chrome Web Store is a product surface

Shipping code is half the job. The listing is the other half.

Things that mattered more than I wanted them to:

Privacy policy URL (live on the site, not a Google Doc)
Terms of service
Clear permission justifications
Screenshots that show the actual popup
Category that matches how people browse (we used Social Networking)
A ZIP built for production (no localhost permission leftovers)
Version bumps when you fix auth (0.1.0 → 0.1.1 was not vanity)

Also: trader verification and regional phone issues can block you in weird ways. Budget calendar time for account admin, not just engineering.

What I would do differently next time

Canonical domain on day one. Decide www vs apex before OAuth.
Ship the store ZIP earlier to a private tester. Unpacked success is not store success.
Log the OAuth exchange path. "Still signed out" usually means the token never landed, not that the UI is haunted.
Write privacy/terms while the product is small. It is easier when the data story is short.
Keep v0.1 brutally small. Gamification of real actions beat five AI features I did not ship.

The emotional part (because shipping is emotional)

There is a specific moment when the listing flips from draft to public and the install link works for someone who is not you.

That moment hit harder than any green CI check.

I have shipped websites before. An extension feels different. It lives in the browser chrome. It asks for trust. It sits next to passwords and ad blockers. When someone clicks Add to Chrome, they are not bouncing through a landing page. They are installing you into their daily toolbelt.

That is terrifying. It is also the point.

If you want to try XPilot (it is free)

XPilot is live on the Chrome Web Store. Free to install. Free to use for XP, levels, and streaks.

Add to Chrome (free): chromewebstore.google.com/detail/xpilot/jnnegeiinddcfcphdbndilbllhgjkamd
Site: xpilot.so

One minute setup:

Click Add to Chrome
Sign in with X
Use X like you already do
Open the popup when you want to see XP, level, and streak

No waitlist. No "book a demo." No paid wall in front of the core loop.

I am building the game layer for people who are done growing on guilt. v0.1 is the foundation and it is free on purpose: if the habit is not sticky when it costs nothing, it will not be sticky when it costs €29.

Quick FAQ for builders

Do I need React for a Chrome extension?

No. For a small popup, plain HTML is fine. Use React when the UI complexity earns it.

Should I use the official browser APIs or a framework?

Use a framework like WXT unless you have a reason not to. Packaging and MV3 details are not where your product moat lives.

Is scraping a social network's DOM a good idea?

It is fragile and you must stay on the right side of ToS and user expectations. Track the user's own actions in their session. Do not build a stealth scraper and call it a growth tool.

What blocks store approval most often?

Missing privacy policy, unclear permissions, remote code, broken auth, and listings that do not match the binary.

How long did this take?

Longer than the happy-path tutorial. Shorter than "rewrite everything because MV3." Most of the calendar time was OAuth, store packaging, and edge cases on X's UI, not the XP math.

Closing

If you have been waiting to build your first Chrome extension, start.

Pick a problem that only makes sense inside the browser. Keep the first version insultingly small. Assume OAuth and packaging will take longer than your ego wants. Ship anyway.

I just did. The extension is free. The lessons above are free too.

Add XPilot to Chrome and let the game begin.

Written by Alex Cloudstar (@alexcloudstar). Building XPilot — free on Chrome.

I'm Starting a YouTube Series Where I Code With Zero AI. Here's Why That Feels Radical in 2026.

Alex Cloudstar — Wed, 22 Jul 2026 15:21:36 +0000

A few months ago I caught myself staring at a merge conflict for a solid two minutes, completely stuck, before I remembered that resolving merge conflicts is not actually hard. I had just forgotten how to do it without a suggestion popping up first.

That moment stuck with me. I've been a full-stack developer for years, running my own company, shipping products, writing code every single day. And somewhere in the last couple of years, a huge chunk of the actual thinking got outsourced without me really noticing. Autocomplete finishes the sentence. Autocomplete finishes the function. Autocomplete finishes the architecture decision. At some point you're not writing code anymore, you're proofreading someone else's.

I'm not writing this to dunk on AI tools. I use them, I ship faster because of them, and I'm not going back to typing every line by hand as some kind of purity test. But I noticed a real erosion happening, and I don't think I'm the only one. Ask a developer under 30 to explain what's actually happening in a piece of generated code and you'll get a shrug more often than you'd expect. Not because they're not smart. Because the muscle never got built in the first place.

The Bet

So I'm running an experiment on my channel. The premise is simple: build real software, start to finish, with no AI involved anywhere in the process. Not for the writing, not for the planning, not even for a quick "what's this error mean" lookup. Just me, a text editor, and whatever documentation existed before 2022.

A few ground rules I'm holding myself to:

No AI, full stop. Planning, design, and code all come from scratch.
No tooling lock-in. One day it might be Neovim, the next it might be Zed. The point isn't the editor, it's the thinking.
Daily-ish uploads, but I'm treating this as a long run, not a sprint. Burnout kills more content series than bad ideas ever do.

I'll be posting behind-the-scenes bits of each episode on X, and the full builds will go up on YouTube under the channel alexcloudstar.

Why This Matters Beyond Content

Here's the thing I actually want to find out, and it's bigger than "can I still code." Programming skill has always been about holding a problem in your head long enough to see its shape. AI tools are incredible at generating solutions, but they're just as good at letting you skip the part where you actually understand the problem. That gap doesn't show up on a good day. It shows up when the tool is wrong, or down, or when you're debugging something novel at 2am with no clean pattern to match against.

I don't have a tidy conclusion for this yet. That's kind of the point of running it as a series instead of writing a hot take. I want to see, honestly, whether a few months of deliberate no-AI building sharpens things back up, or whether it turns out the muscle is gone for good and has to be rebuilt from zero.

If you're a developer who's felt that same low hum of "wait, could I actually still do this without the assist," I think you'll get something out of watching along. And if you've got a language or a project idea you want to see tackled the hard way, I'm taking requests in the comments.

The trailer drops today, with the full series coming soon after. To catch it:

Subscribe on YouTube: alexcloudstar
Follow me on X for behind-the-scenes of every episode

Let's see how rusty I really am.

Claude Fable 5 Is Here: Mythos-Class Power for Everyone, and Whether It's Worth 2x the Price

Alex Cloudstar — Wed, 10 Jun 2026 07:49:36 +0000

When I reviewed Claude Opus 4.8 two weeks ago, I flagged one sentence in the announcement as the most interesting thing in it. Anthropic said Mythos-class models were coming to all customers in the coming weeks, gated on safety work rather than capability. That was the tell. The gap between what these labs can build and what they choose to ship was loosening.

Yesterday, June 9, the other shoe dropped. Claude Fable 5 shipped, and it is a Mythos-class model. Same release playbook as always. No waitlist, no staged rollout. It landed in the Claude API, on Bedrock, in GitHub Copilot, and on the consumer plans on the same day, with the model ID claude-fable-5 ready to drop into config.

So I spent the day doing what I do with every release. I threw my hardest real tasks at it, dug through the announcement and the third-party benchmarks, and tried to separate what genuinely changed from the launch-day shine. This one is different from the last few. Not because the benchmarks moved a few points, but because Claude Fable 5 is the first time Anthropic has handed the public a model from the tier they previously decided was too capable to release.

Here is what I found.

What Fable 5 and Mythos 5 Actually Are

The naming is doing a lot of work here, so it is worth slowing down. There are two models in this release, and they are the same model.

Claude Fable 5 is the Mythos-class model with safety classifiers turned on. This is the one you and I get. It is available right now through the API, the cloud providers, and the subscription plans.

Claude Mythos 5 is the identical underlying model with certain safeguards removed. It is not generally available. Right now it is restricted to cybersecurity professionals and infrastructure providers through something Anthropic is calling Project Glasswing, with a trusted-access program for biology researchers planned next.

I wrote about Claude Mythos back when it was a locked research preview, the model that scored absurdly high on coding and cyber benchmarks and that Anthropic explicitly chose not to ship. Fable 5 is the answer to the obvious question that post raised: what happens when they finally decide it is safe enough to release? The answer is that they release it with a set of classifiers bolted on, keep the unfiltered version behind a vetting process, and call the two halves by different names.

That split matters more than it looks, and I will come back to it. But first, the part everyone actually wants to know.

The Benchmarks That Matter

Anthropic claims Fable 5 is state-of-the-art on nearly every capability benchmark they tested, and for once the third-party numbers back the marketing instead of softening it. The pattern from the Opus 4.8 release, where the gains were real but incremental, does not hold here. These are step changes.

Here are the numbers worth knowing.

Benchmark	What it measures	Fable 5	For comparison
SWE-Bench Pro	Real-world software engineering	80.3%	Opus 4.8: 69.2%, GPT-5.5: 58.6%
FrontierCode	Production-grade code quality	29.3%	Opus 4.8: 13.4%
GDP.pdf	Vision reasoning over documents, no tools	29.8%	GPT-5.5: 24.9%
ExploitBench (Mythos 5)	Cybersecurity, guardrails off	78.0%	Opus 4.8: 40.0%
Core analytics	Complex analytical tasks	First model over 90%	Previous frontier under the line

The SWE-Bench Pro jump is the one that stopped me. Going from 69% to 80% does not sound like much until you remember what that benchmark is. It is not toy problems. It is real engineering tasks pulled from real repositories, the kind where the model has to understand a codebase, make a change that spans multiple files, and not break anything else. An eleven-point gain at that altitude is the difference between a model that gets most things right and one that gets the hard things right too.

FrontierCode is the other eye-opener. More than doubling Opus 4.8's score on a benchmark designed to test whether code meets production standards, not just whether it runs, lines up with what I felt in actual use. The output reads less like generated code and more like code a careful engineer wrote.

The ExploitBench number belongs to Mythos 5, the unfiltered sibling, which is why it nearly doubles Opus 4.8. That gap is the entire reason the unfiltered version is locked behind Project Glasswing. A model that scores 78% on offensive security tasks is exactly the dual-use capability that makes a lab nervous, and it is worth holding that number in your head when we get to the safety section.

What 80% on SWE-Bench Pro Feels Like in Practice

Benchmarks tell you the model is capable. They do not tell you what the capability feels like when you are the one driving. So I gave it the work I actually do.

The first test was a refactor I had been avoiding. A tangled service layer in one of my projects, about a dozen files, with state management that had grown organically and badly over a year. The kind of thing where the agentic coding loop usually drifts. One agent, one file at a time, me re-explaining the convention every few files as context slips.

Fable 5 handled it in a way that felt qualitatively different. It read the whole service layer, identified the actual structural problem rather than just the surface symptoms, and proposed a refactor that I would have been happy to write myself. Not every choice was mine. But the reasoning was sound enough that the disagreements were about taste, not correctness.

The claim Anthropic leans on hardest is sustained reasoning. The line in the announcement is that the longer and more complex the task, the larger Fable 5's lead. Early testers reported that apps which needed a hundred prompts a year ago now one-shot. I cannot fully verify the hundred-prompt claim, but the direction is right. The model holds focus across a long task better than anything I have used. It does not lose the thread halfway through a migration the way every previous model eventually does.

The headline customer story is Stripe, who said Fable 5 compressed months of engineering into days, completing a 50-million-line Ruby codebase migration in a single day that would normally take a team two months. I cannot test a 50-million-line migration. But having watched it chew through my own multi-file refactor without me babysitting context, I find the shape of that claim plausible in a way I would have rolled my eyes at six months ago.

This is where the self-correction work from Opus 4.8 compounds. Fable 5 inherits the honesty improvements and pairs them with raw capability. It catches its own mistakes more reliably and the mistakes it makes are rarer to begin with.

The Price Doubled, and That Changes the Math

Here is the part that is going to reshape how you use it. Claude Fable 5 costs $10 per million input tokens and $50 per million output tokens. That is double Opus 4.8, which sits at $5 and $25.

For the last several releases, the story was capability going up while price held flat. I made a whole point of it in the Opus 4.8 review, because flat pricing is the quiet engine behind the improving economics of building AI features. Fable 5 breaks that pattern. The price went up because the model is genuinely more expensive to run, and Anthropic is not hiding it.

To be fair, they frame it as a discount. Fable 5 is less than half the price of the old Mythos Preview, so relative to the Mythos tier this is a price cut. But relative to your actual bill, the one you pay today on Opus 4.8, it is a doubling.

So the calculus is no longer "use the best model for everything." It is back to routing.

Model	Input (per 1M)	Output (per 1M)	Use it for
Opus 4.8	$5	$25	Daily coding, most agent work, anything high-volume
Fable 5	$10	$50	The hard tasks where the extra capability pays for itself

The honest framing is that Fable 5 is not a replacement for your default model. It is a tool for the top of the difficulty curve. The gnarly migration, the architecture decision with real tradeoffs, the debugging session that spans three systems and has resisted every cheaper attempt. For those, paying double is trivial against the time saved. For your everyday loop of small edits and lookups, you are lighting money on fire if you route all of it through Fable 5.

If you are mapping out spend across plans and API usage, my Claude pricing survival guide walks through how to think about the tradeoffs, and this release adds a new top tier to that decision. It also makes a strong case for getting serious about token cost management if you have not already, because the cost of being lazy about model selection just doubled.

On the plans side, Anthropic is doing the usual launch promotion. Fable 5 is included at no extra cost on Pro, Max, Team, and Enterprise through June 22, after which usage credits kick in pending capacity. So you have about two weeks to hammer on it for free before the meter starts.

Mythos 5: The Same Brain With the Guardrails Off

The most genuinely novel thing in this release is not Fable 5. It is the decision to ship its unfiltered twin at all, even to a restricted group.

Mythos 5 is Fable 5 with the safety classifiers removed. Same weights, same intelligence, none of the blocking. Anthropic is only giving it to cybersecurity professionals and infrastructure providers through Project Glasswing right now, with a biology-researcher program coming that will lift the bio safeguards while keeping the cyber ones in place.

The reasoning is straightforward once you look at the ExploitBench number. The unfiltered model scores 78% on offensive security work, nearly double Opus 4.8. That is a capability you want defenders to have and attackers not to. Gating it behind a vetted program is Anthropic trying to thread that needle, putting the sharp version in the hands of people who use it to harden systems while keeping it away from everyone else.

For the security testing I am authorized to do, the existence of a model this capable on the defensive side is a real shift. The flip side is the one I keep thinking about. If the only thing standing between the public model and the offensive model is a set of classifiers, then the safety of the whole arrangement rests entirely on how good those classifiers are. Which brings us to the part of this release that should bother you a little.

The Safeguards, and the Part That Should Bother You

Fable 5 ships with three classifier systems. One blocks offensive cybersecurity and exploitation tasks. One blocks dual-use biology and chemistry research. One prevents distillation, the extraction of the model's capabilities into a smaller model.

The implementation is interesting. When a safeguard triggers, Fable 5 does not refuse. It silently falls back to Opus 4.8 and answers from there. Anthropic says this happens in less than 5% of sessions on average, and that the system is tuned conservatively, so it sometimes blocks benign requests. External red-teaming reportedly found zero successful harmful single-turn requests against 30 public jailbreak techniques, which is a strong result if it holds up.

So far, so reasonable. A model that downgrades instead of refusing is a better user experience than a hard wall, and a transparent classifier that tells you when it fired is fine.

The problem, and Nathan Lambert at Interconnects laid this out sharply, is that not all of the downgrading is transparent. He distinguishes between the disclosed safeguards, cyber and bio and distillation, which notify you when they kick in, and undisclosed modifications around frontier AI research that change the model's behavior without telling you. His line is worth quoting directly: "An AI model that gets less intelligent automatically without notifying me is categorically misaligned AI."

I think he is right to be annoyed, and the reason cuts straight to how I work. If I am using a model for serious engineering and it can quietly become a different, dumber model mid-session without telling me, my eval suite cannot account for it. The model I tested is not reliably the model I am running. Lambert goes further and says he cannot trust Fable 5 for frontier ML development work for exactly this reason, and reads the opacity as more about protecting Anthropic's competitive position than about safety.

Whether or not you buy the competitive-entrenchment read, the practical takeaway for developers is concrete. If you are building on Fable 5, assume a small fraction of your requests may be answered by Opus 4.8 instead, and assume you may not always be told. Build your evals and your output validation to be robust to that, because the model behind the API is not a fixed quantity. This is the first frontier release where I would call non-determinism in which model answers a first-class concern rather than a footnote.

One more operational detail: Mythos-class traffic now carries a mandatory 30-day data retention policy. Anthropic says the data is not used for training or non-safety purposes and is deleted after 30 days in most cases, with human access logged. If you work under strict data-handling requirements, read that policy before you route production traffic through Fable 5.

The Science Results Are the Real Story

The coding numbers will get the headlines because that is what most of us buy these models for. But the results that actually made me sit up are in science, and they came from Mythos 5.

On molecular biology, the model generated novel hypotheses that scientists preferred about 80% of the time over Opus-class models. In genomics, it ran a research task largely on its own for over a week, analyzing millions of cells across 138 animal species, and reportedly outperformed a recent Science journal publication despite being a fraction of the size. In drug design, internal protein experts said it accelerated their work by roughly ten times, with nine of fourteen protein targets yielding strong candidates.

I am not a biologist and I cannot evaluate those claims on the merits. But the pattern is the one worth noticing. The thing that separates Fable 5 from the models before it is not that it writes slightly better code. It is that it can sustain genuinely autonomous work over long horizons. A week of unsupervised genomics research is a different category of capability than a clever answer to a single prompt.

That same capability is what powers the coding story. The reason the migrations work is the same reason the genomics works. The model holds the thread. If you have wrestled with agent reliability over long-running tasks, this is the first model where the long-horizon part feels solved enough to lean on rather than babysit.

Should You Switch From Opus 4.8?

Here is how I would think about it depending on where you sit.

If you do daily coding on a Pro or Max plan: Try Fable 5 on your hardest current task in the next two weeks while it is free on the plans. The capability jump is real and you should feel it on genuinely difficult work. But do not make it your default. When the credits kick in after June 22, the doubled price means Opus 4.8 should stay your workhorse and Fable 5 should be the tool you reach for when the cheaper model is struggling.

If you run Opus 4.8 in production via the API: Do not flip the model ID blindly. The price doubling alone means you need to be deliberate about which paths justify it, and the silent-fallback behavior means your outputs are now non-deterministic in a new way. Run your eval suite, then route only the high-value, hard tasks to claude-fable-5 while keeping volume traffic on Opus 4.8. This is a routing decision, not a swap.

If you are on GPT-5.5 or Gemini for primary work: The gaps in coding, vision, and agentic work just widened in Claude's favor, and by more than the Opus 4.8 release did. When I last did a full Claude vs GPT vs Gemini breakdown, the models converged on baseline and diverged on strengths. Fable 5 stretches Claude's lead in its strong areas rather than reshuffling the board. If you have been on the fence about Claude for serious engineering, this is the strongest case yet.

If you do authorized security or scientific research: Look into whether you qualify for Project Glasswing or the upcoming trusted-access programs. The unfiltered Mythos 5 is a meaningfully different tool than the public Fable 5, and for defensive security and research work that is exactly the point.

The Bigger Picture

What strikes me about Claude Fable 5 is not the SWE-Bench number, impressive as it is. It is what the release tells you about where the constraint now sits.

For the last year, the story was capability rising while price held flat, and the binding question was how much smarter the next model would be. Fable 5 flips both halves of that. The price went up, and the binding question is no longer capability. It is safety and trust. Anthropic built a model good enough that they split it in two, shipped the filtered half to everyone, locked the unfiltered half behind a vetting program, and bolted on classifiers that can quietly swap in a weaker model behind your back.

That is a different kind of release. The capability is so far ahead that the interesting decisions are now about governance, access, and disclosure rather than raw benchmarks. The most important sentence in the Opus 4.8 announcement was the one teasing Mythos-class availability. The most important fact about Fable 5 is not how smart it is. It is that "how smart is it" stopped being the hard question.

For the work I do every day, Fable 5 is the most capable tool I have ever pointed at a hard problem, and I will be reaching for it exactly when a problem is hard enough to earn the price. For everything else, Opus 4.8 is still my default. And the part I will be watching most carefully is not the next benchmark. It is whether the model answering my request is actually the model I think it is.