Hi All! I made an app for my mom, didn't charge her obviously, and my dad slipped me R1000 ($61) anyway. I got paid, whoop whoop! Sweet gesture - but now I've got a friend asking for a quote for actual paid work, and I genuinely don't know what to tell her. It's not a super simple bit of work either, it's actually got some real layers to it, but SUPER cool and SUPER interesting to build. The credits/hosting/sundries side I can work out, that's just cost. What I'm stuck on is pricing my work: the actual skill, the time, the layers that go into a build. So much of it is my data skills and understanding how to structure the data and put it all together, technically a lot of this is just pure data in a nice wrapper. So the question: when you price a build, once-off or subscription, are you working from hours × a rate, pricing against what a comparable service/tool would cost the client, or something else? How do you put a price on labour if you have nothing to compare it to? I'm a teacher with a few cool skills in data and making things look nice, and I like systems, which maybe makes it feel easier to me than it actually is, so I know that's not the most reliable measure of what it's worth. But she's not the only one asking, people keep reaching out, so I'm trying to build an actual system here, not just take any offer and hope for the best next time. (this is all going towards my Lyceum seat - not even sure if it is available anymore but I am working to get that seat so please help me figure this out.) Thank you in advance!!

📣 I enjoy finding truth and education in humor. 🟢 See all 10 live in the classroom now: https://www.skool.com/cliefnotes/classroom/b5143824?md=367fe0cb353f44f28e1eb493dbe40054 ❓Did you learn something new? If you have a better one comment it below 👇

A question for those using ICM to provide software or consulting services: When you work with multiple customers, does one ICM system support all of them, with separate customer configurations, requirements, data, and outputs? Or do you create and maintain a separate ICM structure for each customer or software product? I’ve been thinking about this through the way I create my own products. I reuse many of the same standards, checks, scripts, and production methods, but different product types may still need different schemas and workflows. A devotional is not built exactly like a prayer card set, even though they share part of the same underlying system. I’m curious whether software providers (or consultants) approach this similarly. Do you maintain a common core and adapt it for each customer, keep every customer implementation completely separate, or use some combination of the two? I’m still learning how others structure this, so I would genuinely appreciate hearing what has worked for you—and where separation becomes important.

One chat. One agent. One long context that fills with tool dumps, half-ideas, and "sure, let's build that." You call it brainstorming. The context window says otherwise... The problem When design and doing share one seat: - Context floods. Digests never form. - Weak approaches never die. They just get rewritten. - You "approve" a vibe, not a design. - Build starts before the frame can defend itself. Pretty threads. Soft decisions. Expensive rework. The idea: a design swarm I shipped a skill pack for this: brainstorming-swarm v1.0.0. Not a build swarm. A design swarm. 1. Fan independent lenses (failure, stakeholder, constraint, temporal, experiential). 2. Return digests only. Schema caps. No raw dumps into the conductor seat. 3. Hold hard gates for the human (redirect discovery, pick the winner). 4. Stop at a written design. Do not build from this skill. If your harness can run multi-seat, multi-tab, or multi-chat: dispatch-first. If it cannot: serial fallback with the same stages and honest labels. Floor is not default. The habit: orchestrator, not doer The main chat advises, routes, and synthesizes. Heavy work leaves the seat. Brief in. Digest out. Same turn when the work qualifies. Workers execute. They do not own taste or rewrite the method. You keep the gates. That is the job. Micro example Goal: redesign a personal reading list app. - Five lens digests, each capped. - Three competing approaches under different axioms. - Critique kills two, salvages one hybrid. - You pick. Spec writes. Session halts. No code in that run. That is the point. Get it Deep Dive (method + diagrams): https://aris-space.com/documents/workflows/brainstorming-swarm Members on Ari's Space: download the skill pack zip (v1.0.0). Load SKILL.md. Point it at a hard problem. Prefer dispatch-first. Stop at written design. Argue first. Code second. //A<3

You know the drill. Submit your votes results and final round to follow today! //A<3