Session 30: C3 Town Hall — Four Cohort Products Under the Knife, Outcome Selling, and the Rest of the Programme

His history of the last two years in four moves. We started with PROMPTING — craft the words, get the answer. Then WORKFLOW AUTOMATION — drag nodes in n8n, wire them together, the process runs. Then SKILLS — agents got smart enough that the workflow could be written in plain English as a skills.md and handed to Claude Code or Codex, which is why he says "nobody really wants to get into n8n when something can be done in plain English and Claude Code." And now OUTCOME SELLING.

The reason the fourth rung exists is that the third one does not sell. Most skills are free on GitHub; a one-off skill sells only to a rare buyer; and the people with money have no appetite for the setup. "They'll be like, you just get the thing done for me — don't teach me what a skill is, don't tell me to get a Claude Code subscription, don't tell me all of these things, because I don't have the time. Just automate my work." So the tuned skill becomes internal machinery and what you list for sale is the finished outcome.

The engineering upside he points out is that the skill file is also the cheapest way to prototype the product: map the whole workflow as step one, step two, step three, test it yourself end to end with skill files, and only then build the application around the part that worked.

He is careful that front-end and back-end here mean business functions, not code. BACK-END departments are operations, fulfilment, admin, HR — plus the specific jobs he names: bookkeeping, invoice reconciliation. FRONT-END departments are sales and marketing.

Front-end automation is easy to sell because the promise is arithmetic the buyer already understands: more reach, more impressions, more leads, more sales. There is a clear ROI and it points at revenue. Back-end automation has to prove a saving instead, and the claim strains credulity the moment it gets big: "nobody's going to really trust you if you say that with just ten executives in your operations department you will be able to handle millions of dollars worth of business."

His evidence is the funding pattern — most funded automation startups are solving something that gets another business more money, more users or more eyeballs. His conclusion for his own company: default to front-end automations. He is careful to add that this is an observation about ease of sale, not a claim that back-office work is worthless.

SOURCE ONE — proven playbooks. Open the Y Combinator list filtered to workflow-automation startups, and Product Hunt alongside it. Each company on that list took roughly half a million dollars to automate one workflow. Read them and two things fall out: every single one solves for a specific niche rather than generally, and the founder almost always came from that niche — "if somebody is doing something in finance, they were a software engineer at Bloomberg." He notes there may be a hundred YC companies built around go-to-market alone. The move is to map one of those workflows yourself in Claude Code skills, confirm it works, and only then build.

SOURCE TWO — where practitioners actually talk. "What to build requires you to spend time reading in places where other people would not." A good X thread, a Reddit thread, a Hacker News post, and then the comment section, read all the way down, for the pain people name and the hacks they have invented for themselves.

His worked example is the sharpest thing in the segment. A friend with no knowledge whatsoever of cosmetics went into a Reddit community where women were sharing their own lipstick-selection process — go to this site, then this one, then this — built the application from their stated playbook, and started getting signups. Then he pitched it in the community, the members took it as marketing, and he was banned. His response was not to find another community: he spent $50 on Reddit ads targeted at that same community, and the signups kept coming.

Syed opens with a show of hands: who installed a skill or plugin into Claude Code or Cursor this month without reading the skill.md? Most of the room, himself included. Then the threat model: the card on screen carries two lines — a curl piped to a shell from a raw IP, and an HTML comment instructing the agent to hide it. You never see the comment. The agent reads it. His cited numbers, from a February audit of nearly 4,000 skills: about a third had problems, and 76 were actively stealing credentials. "This is NPM all over again, but the package now drives an agent."

SkillPort's answer is a four-stage pipeline on every version: package validation, deterministic static analysis (hidden text, dangerous phrasing, scripts), an LLM pass that runs with no tools so it cannot be talked into anything, and a human reading the source with the findings pinned to the lines. Approval is tied to the exact bytes, installs are checksum-checked, and a version can be pulled instantly. And the discipline that makes it honest: "I will say scanned and reviewed at this version on this day. I will never say safe, and nobody can."

The host's critique is the generalisable part. Inside a cohort that knows you, your word carries. Outside it, it does not: "currently it is just your word against mine — why would I trust your word? Everyone writes secure; these terms are being used very loosely these days." What converts a claim into trust is published evidence — named benchmarks, what was tested, against which use cases, with the stats on the page.

The critique is blunt and it generalises. "You've built so much... but if you show your users a list of features they will not be able to resonate with you. You are just giving me a list of features which are put together. You have to stitch all of those features into a story that you can sell to that particular customer — and that story changes for every single customer."

Which leads to the practical instruction: narrow to two or three features and start from the smallest niche possible. Not consultants — consultants in one field. Not healthcare consultants — the sub-speciality inside healthcare. "If you narrow it down further, it becomes easier. You will scope it down, you'll work on that one single thing, and that will be enough to give you great amounts of business." He cites Paul Graham's observation that founders who start broad struggle to sell early. Against an incumbent like SAP, breadth is the losing axis. "Instead of going wide, go deep."

And the corollary that surprises people: one product can have ten landing pages. "I can have ten landing pages for the same product for different types of customers. I can tell each one — this is what I'm building — selling the same thing, but different, so that they can resonate."

A smaller note from the same critique, worth keeping: dense interfaces lose people. He names his own ADHD and says that a screen with too much text and too many entry points leaves him unsure what he is supposed to do.

Palak is the proof. RoleCompass has ~70 signups and real payments, and the first customer came from a community gathering in April — she mentioned she was building it, they remembered, they called at 9pm, the call ran to 11:30, and the sale closed on that call. She talks to her users every two or three days. The host's reading: "if you're getting payments, that actually tells you something — there is some form of validation that exists in the market."

Everyone else is upstream of that. Rohan has a working product, a $4.1bn market and no go-to-market at all — his only unprompted user is someone in Russia who found it; the host's prescription is a partner with a finance network, discovery calls with the incumbents, and a YC application. Sarah's receptionist works, but the one demo she gave to a real prospect hallucinated a phone number, and she has not sold it since; the advice is that voice agents are never sold from a landing page — it takes multiple meetings, a live demo framed in the buyer's own business, and, from his own agency's experience, 150 to 200 test calls before a voice agent goes to beta. Stephen has 21 years of ERP experience and seven-day weeks of building; the host's advice is to invert it — use the experience to get the client, hire an intern to build, "maybe in the mornings you find clients and in the evening you build."

The line that ties it together, said to the whole room: "If you'll just continue to build, you will just continue to pay for your subscriptions. I'm telling you this — you'll see that." And: "once you get that first customer, you get the direction."

"This idea works only if it's a B2C product — a consumer product. When I say consumer product, essentially I'm trying to build something that helps my users flaunt that thing on their social media. Something that is worth sharing for my users." Distribution stops being a separate marketing job and becomes a feature you build.

His live example is a personal side project: a way to collect links into buckets — YouTube videos, Substack posts, articles, X threads — grouped by topic, with an MCP attached so he can ask Claude Code what he saved on a subject and get a summary, instead of the usual fate of saved links, which is never being opened again. The buckets are called spaces. The feature he is adding is not more collection; it is a share link, so a curated space can be handed to other people. Around it he lists the ecosystem hooks that make a shared artefact spread: ratings, comments, the social layer.

The honest caveat he gives himself: this is a strategy for consumer products. It does not transfer to B2B, where the buyer has no interest in flaunting your tool.

He opens the segment by saying the programme they designed is not the programme they are now running: "when we started this program the curriculum looked very different, and now as we are progressing everything is changing" — new tools, new playbooks, new strategies for what to build and how to sell it. Last week they collected feedback from a subset of the cohort; this is the answer.

Two to three sessions on ADVANCED / AGENTIC APP BUILDING, using LangGraph, which the cohort asked for by name — plus observability and evals with LangSmith. One session on MOBILE APP DEVELOPMENT through Expo, covering iOS and Android in one pass, chosen because most of the cohort could not build in Xcode and Android Studio. One or two dedicated sessions on DISTRIBUTION, which was the most-requested gap. A session on PRODUCT READINESS, with a skills-based checklist to run before deploying. And four FOUNDERS TIME episodes — startup and agency founders walking through how they built, how they sell, how they solved distribution, how they got clients and how they scaled.

Syed had asked for exactly this list earlier in the call — evaluations, guardrails, observability, production readiness — and the host confirmed it was already scheduled. The LMS curriculum is being updated to match, and a second town hall closes the programme.