So a lot of us are building stuff and competing in the weeklies. Many of us also want to be able to make a living off what we are doing. Some of us are, and some of us are like "How get point c, while still point a?" 😂 There is the obvious stuff like: 1) Putting your work on github 2) Posting here 3) The job board that Jake and Matt are working on. 4) Friends, colleagues I am not a marketing guy, nor am I good at selling myself. Its an alien concept in my brain. So going from where I am to finding customers is an not something that comes natural to me. What are some other good suggestions for getting our work in front of people who might go "Hey, that's something I could use" or "Hey, can you do this?" @David Vogel I already looked for this topic so 😛

I continue to find that many are reinventing the wheel with AI workflows. There are many tools and methods that have been around for decades and in some cases over a century for traditional manufacturing that map cleanly to this new era. One of these I keep mentioning is FMEA or failure mode and effects analysis. FMEA is a risk management methodology that allows you to review your designs and processes prior to implementing them. The process is as follows: - List out the sequential steps of your process, design or workflow - List the potential failures modes one by one at each process step. What can go wrong and how - List the potential causes that could result in that failure - Rate the severity (how bad is it if the failure occurs), occurrence (how often does the failure happen or is likely to happen), and detection (how good is your ability to detect that failure when it occurs or before it occurs). A score combining the three is calculated What this does it assign a numerical value to each risk to prioritize attacking them in order of most to least importance. You can fix any gaps and reevaluate the new workflow. All of this is done before shipping anything. If you make a change to the workflow, adjust the FMEA and make sure there are no gaps. I’ve included an image of what one of these typically looks like. Try it out on your workflows. Do you see any gaps? Any failures you didn’t think of before or something that you can build a feature to catch? Let me know what you think below ⬇️

Everybody’s posting about what to do with ICM. Let’s take a moment to focus on things that may trip you up. There’s a lot of great content in here right now about what you should be doing with ICM. The builds, the workflows, the wins. I love it. But I want to talk about the other side of it for a minute. The stuff that quietly wrecks your workflow. The small things you don’t find out about until you’ve already learned them the hard way. Most of these I learned by doing them wrong first, so take that for whatever it’s worth. 1. Copying builds instead of learning from them: The builds people share in here are incredible. But almost all of them are built for a very specific situation. When you download one and start pulling pieces out to make it fit your world, you leave things behind. Orphaned rules. Edge case handling that made perfect sense in their context and now quietly fights your normal workflow in yours. You don’t see it because these things get intricate. It runs fine right up until it doesn’t, and then you’re hunting a problem you built into it on day one. What I do now is I don’t adopt a build. I study it. I want to understand what it’s doing and why it’s doing it. Then that reasoning becomes part of my toolset, and I build my own thing with it. You’re trying to import the thinking, not the template. 2. Skipping the part where you map your own logic: Before I touch a single folder, I sit down and think about what I would actually do if I were doing the task by hand. If this happens, I do this. If that happens instead, I handle it that way. And if it shows up some third way I didn’t expect, then I need to do this other thing. You write all of that down. That is the work. ICM is about being intentional with your context. You cannot be intentional about something you never thought through. Skip this step and you’re just decorating a guess . 3. Going too fast: This is the fastest way I know to make ICM fall apart. Everything is now now now, go go go, get it done. ICM does not reward that. The whole method leans on you slowing down enough to be deliberate. When you rush, you skip the thinking, you grab somebody’s build, you bolt it together, and you ship something that was never solid underneath. You have to be willing to sit with it.

Hi everyone. I’m a newbie to coding and vibe coding aswell. I just wondered if you could help me and potentially the other members of the group by telling us the biggest and most regular mistakes someone could do while vibe coding, especially when someone like me cannot check the code itself. Please tell me what you have found out and how have you overcome those issues. I would be especially interested in handling, errors and getting rid of hallucinations. Thank you very much in advance. ☺️

The 60/30/10 rule, and why the 10 is the part that matters least in the mix! When I first learned how to actually think about an AI build I was not thinking ratios, ICM change that. Sixty percent infrastructure. Thirty percent orchestration. Ten percent AI. And I’ll be honest, when I first heard it, I assumed the AI would be the big number. That’s the part everybody’s chasing, right? It’s the smallest one on the list. Once that clicked for me, it changed how I look at everything I build. Here’s how I understand each piece. The 60% is infrastructure: This is the foundation. Your folder structure, where your information lives, how it moves, the plain deterministic scaffolding that holds the whole thing up. None of it is glamorous. It’s the part people want to rush past because it feels like setup instead of real building. But this is the building. Get this part wrong and nothing you stack on top of it stays standing. Almost every time something I’ve built keeps falling over, I trace it back here. The 30% is orchestration: This is how it all moves. The workflow logic, the order of the steps, where the gates are, where your quality checks happen, how one step hands off to the next. The if this then that. This is where your actual thinking lives. The infrastructure gives you the shape. The orchestration is what makes the shape do something. The 10% is AI: This is the piece everybody obsesses over, and it’s the smallest slice of the whole thing. It’s the generation, the analysis, the part that runs at the very end once everything underneath it is already solid. When the ninety percent below it is sound, the AI looks brilliant. When it isn’t, there is no prompt on earth that saves you. So which matters more, the 60 or the 30 I went back and forth on this for a while, trying to decide whether the structure or the logic carried more weight. I finally realized that’s the wrong question. The 60 and the 30 are both the real work. They’re the deterministic part, the stuff you actually have to sit down and think through. The honest divide isn’t 60 against 30. It’s the 90 against the 10.