Most teams spend days sizing 9% tax credits. Watch me do it in minutes. Sizing a 9% LIHTC (Low-Income Housing Tax Credit) deal means running the same math over and over. You pull the development budget, you strip out land and other costs that do not count. You find the share of low-income units. You multiply by the credit rate. Then you do it again for the next deal. The process is complex and lengthy, that is not my opinion. The Congressional Research Service says the process of allocating, awarding, and claiming the credit is complex and lengthy. The 9% credit is also competitive. States hand out a limited amount each year. Here is the math in plain words. The annual credit is the qualified basis times the 9% rate. Qualified basis is the eligible basis times the applicable fraction. Eligible basis is the total development cost minus the items that do not count, like land. The applicable fraction is the lower of the share of low-income units or the share of low-income square footage. The credit is claimed once a year for 10 years. Some sites get a 30% boost. These are called qualified census tracts and difficult development areas. A simple example: a $1 million qualified basis at 9% gives $90,000 a year in credits, or $900,000 over 10 years. When you size manually, you move slow. Slow sizing makes you miss good deals, because the window to say yes closes while you are still in the spreadsheet. That is the problem and here is the fix. I built a ready-made 9% LIHTC sizing sheet. It runs the full chain for you: eligible basis, applicable fraction, qualified basis, annual credit, 10-year total, equity proceeds, and a sources equals uses balance check. You upload your deal documents, and it shows the math step by step. It runs in a single chat with any AI assistant. You still check the numbers, the tool just does the heavy lifting. This is for affordable housing developers who want to say YES or no faster. If you size 9% deals by hand, this workspace can save you days on every deal. Watch the video below.

hi guys im back been a busy bee buildercore is finished just at the hardening stage and ive put my proposed company website up still working on it buts its live and could really use the communities help. Could you spend five minutes looking through https://innovaite.co.uk and give me completely honest feedback? Please tell me: 1. What do you think InnovAIte does after viewing the homepage? 2. Which part interested you most? 3. Was anything confusing, repetitive or too long? 4. Did the work examples and BuilderCore make the company feel credible? 5. If you needed a website, software product or Business Discovery, would you contact us? If not, what would stop you? 6. Did anything look broken or awkward on your phone? 7. What is the single biggest improvement you would make? Please don’t worry about being polite—I’m looking for useful criticism.

https://www.skool.com/cliefnotes/real-estate-agent-local-folder-icm-crm?p=2eaba03b previous post Update on how its all going. ‼️ Made many upgrades and added new features ect. Works a treat, (the CRM side is great) but what ive found is, its not as agentic as i would like, i find myself still telling claude to do a lot of the things - its thinking and suggesting is top tier, but acting on it seems to be the bottle neck. Yes I could just add triggers to act on the things, but the decision making isnt great. What I seem to miss and didnt understand at the time, is the training and reasoning. I thought a daily wrap up of decisions made into memory would be enough but it wasnt. I've had deep discussions with claude and have pushed it through other LLMs to discuss. Essentially the problem is I "mushed" a CRM and an ai assistant into one. I've been planning, reviewing and discussing for over 2 weeks now, feels like im going around in circles. So I'm now thinking, so starting a fresh (will still be using the old system) but building it like training an ai model, still using the ICM method as I want to future proof as ai power increases. The goal is to have an actualy AI assistant rather than hiring an actually assitant for $5k a month. 2 questions I have for the brave - would love peoples opinions. 1. I want to pull the old data information as I'm sitting on months of gold, the problem I can see, is that I would just pull that data and it would disease the new system. Would I use a RAG system or should I just pull the raw data? Contact cards, raw transcriptions, mistakes-log, plays-that-worked, objections-log? would it still disease? I dont want to waste all the good stuff without geting the shit stuff. 2. is my direction thinking here correct? Screenshots of Old system layout, new layout and the foundation. If you would like the full context of what I'm doing i've attached a full context MD file, feel free to run it through your LLM for more deeper insights.

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. 📋 THE CHALLENGE Build a folder-based AI diagnostician that reads something broken and tells you WHY it's broken. Not how to fix it. Why it failed. This week's deliverable is one diagnostician folder that someone could drop into a Claude project and use to figure out why something in their world isn't working. 🎯PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick a failure you've actually seen happen. A few sparks to get you thinking: - 📉 Why a landing page isn't converting - 📧 Why cold emails to a specific buyer aren't getting replies - 📋 Why a product spec keeps getting pushed back by engineering - 📄 Why a resume isn't getting callbacks in a specific industry - 🚪 Why users drop off at one step of an onboarding flow - 💸 Why a pricing page isn't converting trials - 🎥 Why a YouTube video underperformed the channel average - 🤝 Why a sales deal stalled after the demo - 📱 Why an app's retention craters in week two The more specific, the better. "Diagnoses marketing problems" is too broad. "Diagnoses why cold emails to enterprise IT buyers get opened but never answered" is right. 🗂️THE METHODOLOGY If this is your first comp, welcome. Here's what you need to know: This week (and every week) you're learning interpretable context methodology. Folders as architecture. Each file does one job well. Your diagnostician is a folder with five things: - 📄 identity.md (who the diagnostician is, what they diagnose) - 📐 rules.md (how they diagnose: what they look at, how they separate cause from symptom) - 💬 examples.md (2-3 example diagnoses showing the reasoning) - 📚 reference/ (common failure modes, diagnostic frameworks, benchmarks) - 📖 README.md (how to use it, what to feed it) Drop the folder into a Claude project. Claude becomes the diagnostician. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK A diagnostician is NOT an editor. Last comp was The Editor. That one critiques craft. It looks at a draft and says "this part is weak, go fix it."

I have a hypothetical workflow with 3 stages. The first stage plans, the second writes, and the third reviews. It works great if it there's no issues found in the review. But what if it finds problems? Should it undo all the content it wrote and start over, or should it keep what it wrote and make a revision?