Building, distribution, and sales
Sell in public
The landing-page roast, small paid milestones, weekly updates, and conversations behind Bangers Only and Slash Skills.
In this guide · 11 sections
On 16 February, I posted the landing page for Bangers Only and asked people to roast it. The next day, a company I had been planning to approach signed up on its own.
The post barely travelled. I still got to write “okay this is wild” the next day. The company was the kind of customer I wanted, and it had arrived before I'd sent the cold message.
That is the kind of thing I mean by selling in public. Put the work where people can see it. Give them a reason to respond. Learn from the response, improve the product, and keep going.
I've done this with Bangers Only, Slash Skills, and my writing work. This guide follows the examples from my Sell in Public presentation. You can also open the original slides.
Find the people and start a conversationTalk about the work before the launch
Building quietly can feel productive. There is always another screen to finish, a setting to fix, or a reason the product isn't ready for someone else.
The problem arrives when you finally launch. Now you have to figure out the product, the pitch, the audience, and distribution at the same time. Those are different problems, and you've postponed three of them.
An earlier post gives you a smaller job. Show one working part. Explain the problem it addresses. Ask someone to use it or tell you where the explanation loses them.
It also gives the work a deadline. “I'll show the new version on Friday” is a more concrete commitment than “I'll launch when it's ready.” You can learn from a small release while the next part is still unfinished.
I put it more bluntly in June:
all the people who never shipped anything have incredible systems for getting ready to ship things.
The point isn't to spend the whole day posting about work you haven't done. Finish something small enough to show. Let the next conversation tell you where to look.
- 01Make
Finish a useful part of the product.
- 02Show
Share the result and a clear next step.
- 03Listen
Read the replies and talk to people who try it.
- 04Return
Improve the work, follow up, and share what changed.
The conversation helps you choose what to build and explain next.
Decide who you need to reach
Before choosing a posting schedule, I want answers to three questions:
- Who is this for? Name the person and the job they need to finish.
- Where do they already spend time? Find the conversations they participate in.
- What are they already paying for? Understand what they consider worth buying.
“People who use AI” doesn't help me decide what to build or explain. Someone writing for several founder accounts has a more specific job, set of frustrations, and reason to care about a writing tool.
Here's how I'd turn those questions into a brief for a tool like Bangers Only:
| Question | What to look for | How it changes the work |
|---|---|---|
| What are they trying to finish? | An actual post, client assignment, or launch announcement. | Demonstrate that task instead of listing every feature. |
| Where does it get difficult? | Finding the angle, sounding like the writer, producing options, or making the final edit. | Improve the part that creates the most friction. |
| What do they use now? | Their own process, another tool, a template collection, or paid help. | Explain what your product changes about that process. |
| Where can you reach them? | Posts, replies, professional groups, or people already discussing the problem. | Share a relevant example in a place where it makes sense. |
Fill this in with things people have said or done. If you don't know where the task gets difficult, watch someone try it. That conversation may change the next feature you build.
In my March post about AI wrappers, I came back to the same work: choose a customer, understand them, keep iterating, and share what you're learning.
The underlying technology may be available to that customer too. They can still pay for a product that packages the job well and saves them from assembling the whole process themselves.
That's the useful part of my earlier distribution argument. Knowing how to reach people should influence the product you build and the example you lead with.
Give people something to respond to
“Excited to announce my new AI-powered…” asks a stranger to care before you've given them anything to do. A working page and a specific request make participation easier.
Here's the post, broken down by what it gave the reader.
just made a quick landing page for bangersonly
please roast it and tell me what i can improve 🙏
Read the 16 February post. The post barely travelled, as I describe in the presentation.
one of the companies i was planning to cold reach out to as an ideal ICP for bangersonly just signed up organically
17 February update. The signup came from a company I wanted to reach. These posts don’t establish every step of its path to signing up.
ICP means ideal customer profile: the kind of customer I thought the product could serve well. That is why this signup mattered to me. The useful response came from someone I had wanted to approach.
You don't have to use “roast it.” Ask for the response you actually need. If you're unsure whether the page makes sense, ask someone what they think the product does. If the workflow is confusing, ask them to try it.
| What you're trying to learn | A request someone can act on |
|---|---|
| Does the page explain the product? | “After reading this, what do you think it helps you do?” |
| Can someone finish the main task? | “Try turning one of your notes into a post. Tell me where you get stuck.” |
| Is the example relevant? | “Would this fit an assignment you actually get? What would you change?” |
| Is the new version better? | “You pointed out this problem last week. I've changed it—does this resolve it?” |
Choose one request. A post asking for design feedback, feature ideas, pricing advice, and a signup makes the reader decide which conversation you're trying to have.
Show the work and keep a recordShow the number and name what it measures
“We're getting traction” hides the useful part. A small number with a clear meaning lets someone understand what has happened.
These are milestones I shared while building Bangers Only. Each belongs to the date of its post:
| Date | What I reported | What the number describes |
|---|---|---|
| 15 April 2026 | 200+ users and 10 paid transactions. | User count and payment events, reported separately. |
| 15 July 2026 | Three paid subscriptions, after adding subscriptions the previous month. | A subscription milestone under the newer payment setup. |
The April update also mentioned the highest weekly image downloads so far. That gave the post a product-use detail alongside signups and payments.
The July reply was simply about three paid subscriptions. It was a small number. It still described something more useful than a sentence about “incredible momentum.”
A transaction, a paying customer, and a subscription are different units. Keep the original name. Ten transactions don't necessarily mean ten people, and three subscriptions don't tell you recurring revenue without the prices.
That precision helps you too. Save the date and the definition beside the number. When you return to it later, you should know what you were counting and what changed in the product.
You don't need a revenue milestone large enough for a launch graphic. A first payment, repeated use of a feature, or a customer finishing the task can give you something specific to discuss.
Keep a log people can follow
A launch is one moment. A log gives people a way to see how the product changes and how you make decisions.
My updates often follow four questions: what shipped, what worked, what didn't, and what I'm doing next. That is enough structure to keep writing without manufacturing a new lesson every time.
In week 12's update, posted on 24 March, I wrote about changing the embedding model, adding email sequences for early drop-offs, and trying an onboarding flow I decided wasn't worth it then.
The abandoned onboarding work belongs in the update. It tells someone how I was choosing where to spend time. A log where every experiment succeeds leaves out a large part of building.
In the update labelled week 18, posted on 2 June, the work had moved on:
- Image cards appeared in the first half of each batch.
- New
/forand/vshubs organised role-specific and comparison pages. - The homepage had static HTML and a fuller SEO footer.
- Signup handling changed to block disposable email addresses.
Those are inspectable changes. A reader can see what moved in the product. “Worked on UX and growth” would hide all four decisions.
In the March update, the embedding model was a dated implementation detail. In the June update, the useful details were what changed in the product. Match the explanation to the decision: name the tool when it helps someone follow the work.
You can make the same update useful to different readers by changing the emphasis. A user cares about what they can now do. Another builder may care about the decision and what you stopped doing.
I made a landing page for Bangers Only. Open it and tell me what you think the product does. I want to know where the explanation loses you.
One object and one question. Someone can respond after looking at the page; you haven’t asked them to invent a feature roadmap.
Read all 4 updates together
- Ask for feedback
- I made a landing page for Bangers Only. Open it and tell me what you think the product does. I want to know where the explanation loses you.One object and one question. Someone can respond after looking at the page; you haven’t asked them to invent a feature roadmap.Original feedback request · 16 February 2026
- Show a milestone
- Bangers Only crossed 200 users and 10 paid transactions. This was also the busiest week for image downloads so far.The image-download detail tells us what people used. Keep it beside the user and payment counts so the update describes activity inside the product too.Original milestone update · 15 April 2026
- Share a decision
- I tried adding an onboarding flow to Bangers Only, then decided it wasn’t worth the work at that point.A useful update can include something you stopped doing. To expand this into a teaching post, explain what you tried and why you stopped; the short update alone doesn’t give that reason.Original week 12 update · 24 March 2026
- Teach the process
- I prototyped Bangers Only in AI Studio, worked on the prompts, then exported the project to continue in a coding tool. Here’s the handoff I would show another builder.The handoff gives this post its subject. Show what was ready to export, what needed more work, and how you continued from there.Original workflow reply · 2 February 2026
Practice drafts adapted from dated posts. The links preserve the original wording and context.
Notice the things you keep making for yourself
Slash Skills began with instructions I kept making and using in my own work. I wasn't starting from a plan to build another directory. I already had something I found useful.
On 25 June, I shared the collection:
i originally made these skills for myself and used them a lot
i realize they might be useful for others too, so i published them here
That is a good place to look for a product: work you repeat, files you keep reaching for, or something people ask you to send them. You can show the useful thing before constructing a large argument for it.
The next step is making it usable outside your own setup. Explain who it is for, how to use it, what someone needs before starting, and what result they should expect.
On 24 July, I announced the move to slashskills.xyz, along with support for Codex and Cursor and guides to help people get started.
The domain was one part of the update. The instructions and support mattered because they helped someone else use a collection that had started as my own working files.
This is also where the content engineering guide connects. A repeatable process can become a skill. A useful collection of skills can become something other people return to.
Teach the process behind the product
I used to worry that giving away the process would make the product less valuable. In practice, showing how I worked gave people a clearer reason to take the work seriously.
The responses included “saving this for when i start building” and “how are you this good at this.” People could see enough of the work to want to learn from it.
In a February reply about useful AI tools, I described the process I had used to build Bangers Only. The presentation preserves these parts of that reply:
- Prototype an idea in Google AI Studio.
- Use ChatGPT to work on the prompts.
- Export the project and continue in a coding tool such as Claude Code or Codex.
A list of those tools would have been easy to scroll past. The sequence gives someone a way to begin: make the prototype, work on the prompts, then carry the project into a tool where you can keep building it.
That reply did more for the product than my polished launch posts. I had answered someone's actual question, shown the process, and mentioned Bangers Only at the end. The product belonged in the answer.
You can go further than listing the stack. Show what you gave the tool, what came back, what you had to fix, and which part you would do differently. That is where another person can learn from your experience.
When I announced the content engineering workshop in May, I connected the teaching to the work behind it: ghostwriting reaching 5M+ monthly impressions, channel growth, and building Bangers Only.
The announcement cited channels reaching 50k, 100k, and 250k+ followers. Those were examples across my work, not one product's growth curve. The work library gives the individual projects their context.
The useful promise was access to the process: distribution, writing systems, AI workflows, and the choices that make someone care enough to keep reading.
Teaching and selling can sit comfortably together. The explanation helps someone understand the job. A product may save them time doing it; a workshop may help them practise; working with you may help them make better decisions.
Show that connection plainly. If an example was made with your product, say so and link to it. The reader should understand why the product belongs in the piece.
Follow through on the responseKeep the conversations going
Some of this work looks very ordinary. Reply to people. Remember who tried the product. Send the example you promised. Tell someone when you've fixed the problem they raised.
In April, I wrote about making friends online and paying attention when they try something. I still like that more than treating every interaction as an audience-growth tactic.
The conversation shouldn't disappear the moment someone stops looking like a buyer. Take an interest in what they're making too. A relationship has more room in it than the current product pitch.
Following up is part of the work. In a June post, I wrote about how it had helped me get paid for completed work, close deals, and convert paying users for Bangers Only.
People get busy. A useful follow-up restores the context and gives them an easy next step. It doesn't need to sound like a sales sequence written by someone who has never met them.
For example, after fixing a reported issue:
You mentioned that the drafts were taking too long to edit. I changed how the examples are selected. Here's a new result from the same input. Does it get closer to what you wanted?
That is a template to adapt to a real conversation. The reason to follow up is the change you made, and the question is small enough to answer.
Keep a short record: who you spoke to, what they were trying to do, what you promised, and when to return. It saves someone from having to explain the same problem every time.
Ask people to pay before deciding they won't
“India doesn't pay for software” didn't match what I was seeing. In July, I reported that all but one of my paying Bangers Only users were Indian.
They saw something useful and paid for it. That was enough to make me question the assumption that I needed a different market before I could sell a small software product.
The post also described Twitter and LinkedIn as useful routes to profile visits, my growing comfort with SEO, and my experience using Dodo Payments. It was an account of what was working for me then.
Start with the buying experience in front of you. Can someone understand the product, try the important part, see what the price includes, and complete the payment?
| Part of the experience | What the buyer needs to understand |
|---|---|
| Product | The job it helps them finish and a result they can inspect. |
| Price | What they pay and what that payment includes. |
| Billing | Whether the payment is one-time or recurring. |
| Access | What happens after paying and how to start using it. |
| Help | Where to go if something doesn't work. |
If someone doesn't buy, there are useful questions to ask. Did they need the product? Did the example make sense? Did they try it? Did the payment fail? “People here don't pay” skips over all of that.
The search case study looks at another part of discovery. Search clicks and paying users are different records; together, they suggest questions to investigate across the journey.
Put something usable behind the post
A waitlist can feel like shipping because there is a page to share and a number to watch. For a small tool that already works, I would rather let someone use it and find out what happens.
My July post about waitlists was impatient. The practical point still holds for these projects: don't make an invitation system the next project when you could be improving the thing people came for.
Give them a working route into the product. If access is limited, explain the limit and when they can expect to use it. An email address on a list tells you less than watching someone attempt the task.
Put a price on the paid part when it's ready to buy. Be clear about what is available now. Then the post, the product, and the offer are talking about the same thing.
Make a week of work you can repeat
You don't need to turn every day into a launch. Pick a small piece of work, finish it, and make the next conversation useful.
| Step | What you finish |
|---|---|
| Choose the person | A sentence naming who the work helps and what they need to do. |
| Make something inspectable | A working feature, page, example, or improvement. |
| Choose the post | A clear result, a decision, a process, or a request for feedback. |
| Make the next step easy | One relevant link and one action someone can take. |
| Respond | Answers to the replies, promised material, and follow-ups on actual problems. |
| Keep the record | What changed, what happened, what didn't work, and what you will try next. |
Use the weekly update worksheet if a blank page gets in the way. Use the scriptwriting guide if the best explanation is a short video.
Do the first part tonight. Keep it small enough to finish. Show the thing, make it usable, and ask someone to take the next step. Next week, you'll have something more specific to say.
Adapted from my Sell in Public presentation, supplied 5 September 2026. Linked posts and milestones are historical examples from the presentation. Read the full slide deck.