# Michael Rispoli > Michael Rispoli is a no bullsh*t, forward-deployed CTO for founders who need software shipped, rescued, or made real. ## Forward-deployed CTO The no bullsh*t CTO for founders who need software shipped, rescued, or made real. I'm Mike Rispoli. I help nontechnical founders turn messy ideas, stalled builds, and AI-generated prototypes into production-grade software with product, design, and engineering leadership in one seat. My work sits between fractional CTO, CPTO, and forward-deployed engineer: I translate founder vision into product direction, technical architecture, and the shipping discipline required to cross the final mile into reality. ## When Founders Call Me ### The prototype got you 70% there AI tools, no-code platforms, or a fast freelancer helped you prove the shape of the idea, but the product is not ready for real customers. ### The handoff is messy The agency, contractor, or internal team left behind unclear architecture, brittle code, missing context, or a roadmap nobody fully trusts. ### The questions are getting expensive Investors, customers, or your own team are asking technical questions that need clear product, architecture, and delivery judgment. ## How I Engage ### Product Rescue Audit A direct diagnosis of what is stuck, what is worth saving, and whether the right move is repair, rebuild, or a sharper product cut. ### Forward-Deployed CTO Retainer Weekly CTO leadership across product direction, architecture, vendor decisions, team cadence, and the work required to get software shipped. ### Ship Room Sprint A focused 2-6 week push to turn a stuck build, AI prototype, or urgent product bet into something demoable, fundable, sellable, or production-ready. ## CTO Confidential I host [Strictly from Nowhere](https://www.youtube.com/@strictlyfromnowherepodcast) and my segment, [CTO Confidential](https://www.youtube.com/playlist?list=PL1UgPUZuyEBCUwsDZtRBfC08utG-4YMmB), where I talk through leadership, product, engineering, founder reality, delivery pressure, and the parts of building software people usually sanitize. ## Latest Writing - [Inspiration Sold Separately](/blog/inspiration-sold-separately/): AI can help you build faster. But it can't manufacture the earned inspiration that comes from sitting with the work itself. - [You Can't Reverse Engineer Taste](/blog/you-cant-reverse-engineer-taste/): AI can help you imitate what already works, but developing your own point of view requires living, making things, getting lost, and trusting your eye. - [Is AI the End of Engineering, or Just the Beginning?](/blog/is-ai-the-end-of-engineering-or-just-the-beginning/): AI is eating some old software work, but it is also creating a new category of engineering: turning half-working AI systems into durable business tools. ## Selected Writing Elsewhere - [Why Developers Need to Understand the Business](https://www.causeofakind.com/the-salon/why-developers-need-to-understand-the-business) - [Misunderstanding Tech Debt](https://www.causeofakind.com/the-salon/misunderstanding-tech-debt) - [The Cure for Client Anxiety](https://www.causeofakind.com/the-salon/the-cure-for-client-anxiety) - [Delivery Issues](https://www.causeofakind.com/the-salon/delivery-issues) - [In Defense of Developer Experience](https://www.causeofakind.com/the-salon/in-defense-of-developer-experience) ## Contact Stuck software is usually messier than a polished intake form. Send the context: what exists, what is broken, what is at stake, and what needs to be true next. - [LinkedIn](https://www.linkedin.com/in/michael-rispoli-cto/) - [YouTube](https://www.youtube.com/@strictlyfromnowherepodcast) - [HEY](https://world.hey.com/mrispoli) - [X](https://X.com/michael_rispoli) --- # Blog Writing on fractional CTO work, AI-first product engineering, software delivery, and product leadership. Practical essays for founders and technical leaders who need to make better decisions before the code, the team, or the roadmap gets expensive. ## Posts - [Inspiration Sold Separately](/blog/inspiration-sold-separately/) - Published: July 24, 2026 - Description: AI can help you build faster. But it can't manufacture the earned inspiration that comes from sitting with the work itself. - Tags: AI, Creativity, Product Building - [You Can't Reverse Engineer Taste](/blog/you-cant-reverse-engineer-taste/) - Published: July 10, 2026 - Description: AI can help you imitate what already works, but developing your own point of view requires living, making things, getting lost, and trusting your eye. - Tags: AI, Creativity, Product Building - [Is AI the End of Engineering, or Just the Beginning?](/blog/is-ai-the-end-of-engineering-or-just-the-beginning/) - Published: June 27, 2026 - Description: AI is eating some old software work, but it is also creating a new category of engineering: turning half-working AI systems into durable business tools. - Tags: AI, Engineering, Product Engineering - [The Problem With Abundance](/blog/the-problem-with-abundance/) - Published: June 26, 2026 - Description: AI may make digital things cheaper and easier to produce, but the scarce things people actually want will still be controlled, priced, and protected. - Tags: AI, Opinion, Society - [Cracking the AI Code Interview](/blog/cracking-the-ai-code-interview/) - Published: June 17, 2026 - Description: The engineering interview has to change. In the AI era, the work is not just writing code faster. It is judgment, cost, quality, communication, and knowing what should be built at all. - Tags: AI, Engineering, Hiring - [I Don't Need More Horsepower. I Need More Road.](/blog/i-dont-need-more-horsepower-i-need-more-road/) - Published: June 17, 2026 - Description: AI has made software teams faster than the feedback loop. The harder business problem now is growth, trust, distribution, and having enough road for all that horsepower. - Tags: AI, Product Engineering, Growth - [The Agent Told Me It Was HIPAA Compliant](/blog/the-agent-told-me-it-was-hipaa-compliant/) - Published: June 15, 2026 - Description: AI can generate convincing healthcare software. It cannot declare your product safe, legal, or compliant just because the checklist looks complete. - Tags: AI, Healthcare, Cybersecurity, Compliance - [The Software Factory Works Best After You Know What You're Making](/blog/the-software-factory-works-best-after-you-know-what-youre-making/) - Published: June 12, 2026 - Description: Agent loops are powerful for mature systems with known patterns. Product discovery still needs human judgment close to the work. - Tags: AI, Product Strategy, Software Delivery - [The Rise of Mediocrity and the Death of the Real Turd](/blog/the-rise-of-mediocrity-and-the-death-of-the-real-turd/) - Published: June 10, 2026 - Description: AI did not make everything worse. It made bad harder to see. - Tags: AI, Opinion, Creative Work - [The magic in the meeting](/blog/the-magic-in-the-meeting/) - Published: June 9, 2026 - Description: AI can make execution cheap, but the real product judgment still happens when the right people stay with the problem together. - Tags: AI, Product, Leadership - [Cast the Ring Into the Fire: Why Founders Must Resist the Temptation to Add One More Feature](/blog/cast-the-ring-into-the-fire/) - Published: June 8, 2026 - Description: Early products need one powerful story. Every extra persona, workflow, and feature can weaken the focus that makes the first users care. - Tags: Product Strategy, Founders, Fractional CTO - [A Runtime for Non-Deterministic UI](/blog/json-lisp-ai-written-interfaces/) - Published: June 5, 2026 - Description: JSON Lisp started with a question: what if AI could stream the right interface for one user instead of forcing everyone through the winning side of an A/B test? - Tags: Case Study, AI, Interface Design - [Building AI-Assisted Workflows Inside a Regulated Environment](/blog/karvenience-regulated-ai-workflows/) - Published: June 5, 2026 - Description: Karvenience shows why sensitive data changes the AI conversation: credit applications, documents, integrations, and operational trust all need boundaries. - Tags: Case Study, AI, Regulated Software - [Production CTO for the AI-Prototype Era](/blog/fractional-cto-in-the-ai-era/) - Published: June 4, 2026 - Description: Founders can get farther than ever with AI tools. The hard part is crossing the final mile into software customers can trust. - Tags: Fractional CTO, AI, Product Engineering - [What to Do When Your AI Prototype Gets Stuck](/blog/what-to-do-when-your-ai-prototype-gets-stuck/) - Published: June 2, 2026 - Description: The demo proved something. Now you need to figure out whether it is a product, a workflow, a throwaway prototype, or a technical trap. - Tags: AI Prototypes, Product Rescue, Founders - [Turning a Homegrown Lead Tool Into a SaaS Opportunity](/blog/gault-family-lead-management-system/) - Published: June 1, 2026 - Description: Gault Family Companies had an aging lead system, deep home-services expertise, and a chance to modernize internal software into a product for businesses like theirs. - Tags: Case Study, Internal Tools, Product Engineering - [Rebuild or Repair Your MVP?](/blog/rebuild-or-repair-your-mvp/) - Published: May 30, 2026 - Description: A messy MVP does not automatically need a rewrite. The right call depends on what the current system is costing the business. - Tags: MVP, Technical Debt, Product Rescue - [How to Rescue a Failed Agency Build](/blog/how-to-rescue-a-failed-agency-build/) - Published: May 27, 2026 - Description: A bad agency handoff can leave founders with code, invoices, and no confidence. The rescue starts by separating blame from diagnosis. - Tags: Agency Handoff, Product Rescue, Founders - [What a Product Rescue Audit Should Tell You](/blog/what-a-product-rescue-audit-should-tell-you/) - Published: May 24, 2026 - Description: A useful audit should not just list problems. It should tell a founder what to do next, what to avoid, and what risk the business is carrying. - Tags: Product Rescue, Fractional CTO, Due Diligence - [The Worst Kind of Failure Looks Like Success](/blog/the-worst-kind-of-failure-looks-like-success/) - Published: May 22, 2026 - Description: A team can hit the deadline, ship the feature, and still avoid the thing the business needed to learn. - Tags: Delivery, Product, Leadership - [Do Hard Things Before You Automate Them](/blog/do-hard-things-before-you-automate/) - Published: May 8, 2026 - Description: AI and automation are most useful after you understand the work well enough to know what should disappear. - Tags: AI, Operations, Product Strategy - [When the Rewrite Is the Responsible Move](/blog/best-app-traumatic-brain-injury-accessibility/) - Published: May 1, 2026 - Description: BEST App Suite started as a mobile migration. Years of real user behavior taught us why a Rails PWA was the better product for people with traumatic brain injury. - Tags: Case Study, Accessibility, Healthcare - [Misunderstanding Technical Debt](/blog/misunderstanding-technical-debt/) - Published: April 18, 2026 - Description: Technical debt is not automatically bad. The real problem is when nobody remembers what the debt bought or when it has come due. - Tags: Technical Debt, Engineering Leadership, Startups - [Client Anxiety Is Product Signal](/blog/client-anxiety-is-product-signal/) - Published: March 29, 2026 - Description: An anxious customer is not always a delivery problem. Sometimes they are showing you where the product, process, or promise is unclear. - Tags: Clients, Product, Delivery - [Marketplaces Do Not Start as Marketplaces](/blog/marketplaces-do-not-start-as-marketplaces/) - Published: February 17, 2026 - Description: The cold start problem is not a technical problem first. It is the part of the business most founders have to solve by hand. - Tags: Marketplaces, Product Strategy, Startups - [When an AI Project Needs a Rules Engine](/blog/conduiit-incentiviiz-ai-tax-incentives/) - Published: December 12, 2025 - Description: Incentiviiz started with an LLM thesis. The real product needed a hands-on fractional CTO, deterministic software, and AI used in the right place. - Tags: Case Study, AI, Product Engineering - [Modernizing a Service Admin UI Without a Rewrite](/blog/service-admin-ui-modernization/) - Published: September 18, 2025 - Description: A service admin panel had become hard to change. The fix was not a full rewrite, but an AI-assisted strangler migration from strange React patterns to predictable code. - Tags: Case Study, Product Rescue, React --- # Michael Rispoli East Meadow, New York Fractional CTO and CPTO with 15+ years across design, product, and engineering. I help founders turn messy software, stalled builds, and AI prototypes into production-grade products by bringing product judgment, technical architecture, design taste, and hands-on development into one seat. ## Links - [mrispoli@hey.com](mailto:mrispoli@hey.com) - [https://www.linkedin.com/in/michael-rispoli-cto/](https://www.linkedin.com/in/michael-rispoli-cto/) ## Core Strengths - Fractional CTO leadership - UX/UI design - AI product development - AI engineering - Agentic workflows - Software architecture - Forward-deployed engineering - SOC 2 and HIPAA readiness - Agency and vendor leadership - Technical due diligence ## Experience ### Co-Founder & CTO Cause of a Kind May 2017 - Present | Long Island, NY Co-founded and lead technology for a software development studio solving complex business problems for entrepreneurs, innovators, and mission-driven organizations. Guide product strategy, UX/UI direction, architecture, AI engineering, technical delivery, and hands-on implementation across products that need to move from idea or prototype into production. ### Chief Technology Officer Conduiit, Inc. October 2023 - Present Lead technology for Incentiviiz, an AI-assisted platform that helps film production accountants manage, identify, budget, and predict tax incentives. Turned a painstaking manual workflow into a faster, more predictable product using AI, workflow automation, and an advanced rules engine that tracks incentive laws across markets. ### Co-director of Web Innovation, Software and AI TIPtech Art June 2024 - Present | New York, NY Lead web innovation, software, and AI work for an experiential technology company blending physical and digital environments. Support immersive products and custom installations with software architecture, AI-assisted workflows, interface design, and systems that connect proprietary technology, science, art, and spatial experience design. ### Chief Technology Officer Pack Elephant January 2022 - December 2022 Served as fractional CTO, architecting and designing the initial product while managing the build team. Helped shape the product roadmap, advised on technical direction, supported investor conversations as technical expert, and helped the company launch a large marketplace while raising funding. ### Lead Software Engineer The Knot Worldwide August 2019 - January 2022 | New York, NY Led software engineering work inside a large consumer marketplace environment, contributing to production systems, cross-functional delivery, and product engineering execution at scale. ### Head Of Technology Quiddity October 2018 - August 2019 | New York, NY Led technology direction for a product and software team, balancing architecture, delivery, team leadership, and client-facing technical strategy. ### Engineering Director Hungry January 2017 - October 2018 Directed engineering at a full-service digital creative and technology agency, helping teams deliver software across client products, websites, and digital platforms. ### Forward Deployed Engineer Bluecore September 2014 - January 2017 | Greater New York City Area Worked directly with enterprise retailers on a digital marketing personalization platform. Helped turn large onsite datasets into automated, highly personalized outreach and implementation workflows. ### Integration Engineer Olapic, Inc. November 2013 - September 2014 | Greater New York City Area Integrated user-generated content into online retail experiences, including product pages and large-scale hashtag campaigns for ecommerce brands. ### Frontend Developer Sysgen Media LLC July 2012 - November 2013 | Huntington, NY Built websites and ecommerce experiences for a full-service digital agency specializing in Joomla, WordPress, and Magento. ### Frontend Developer New Dynamx LLC March 2012 - November 2012 | Hicksville, NY Built frontend web experiences using HTML, CSS, JavaScript, jQuery, BigCommerce, WordPress, Weebly, ecommerce solutions, software demonstrations, internet marketing, and information architecture. ## Education & Credentials ### State University of New York at New Paltz BA, Geography, Geology; Magna Cum Laude; Outstanding Graduate 2005 - 2008 ### Designlab UX Design 2016 - 2017 --- # Contact Michael Rispoli Send me the messy version. Stuck software is usually messier than a polished intake form. Send the context: what exists, what is broken, what is at stake, and what needs to be true next. - [LinkedIn](https://www.linkedin.com/in/michael-rispoli-cto/) - [YouTube](https://www.youtube.com/@strictlyfromnowherepodcast) - [HEY](https://world.hey.com/mrispoli) - [X](https://X.com/michael_rispoli) --- # Inspiration Sold Separately AI can help you build faster. But it can't manufacture the earned inspiration that comes from sitting with the work itself. Published: July 24, 2026 Tags: AI, Creativity, Product Building Canonical URL: https://michaelrispoli.com/blog/inspiration-sold-separately/ The first time AI builds something for you, it feels like cheating. You describe a thing, it writes the code, your app appears on the screen. You never struggle with the syntax. You don't battle how to organize the code. What you had in your head is now on the screen. If making things is solved, all that's left is deciding *what* to make. Sounds empowering without all that learning in the way. But the struggle we're skipping may be the same struggle that taught us what was worth making. The problem is that those annoying little activities--wrestling with the blank page, reworking the code in your IDE for the tenth time, staring at the thing until it starts to make sense--were the education. They made you better at seeing the problem. Writing code sucks until you become fluent in it. Not everyone feels this way. But I did. Most things worth doing are like this. Nobody picks up a guitar wanting to struggle through "Hot Cross Buns." They go to bed dreaming of the day they can play "Stairway to Heaven" from memory. The ambitious ones dream of writing their own. But until that day, you struggle. You practice. The thing starts to come together. One day you don't have to look up every chord. The next, you can turn them into familiar riffs. At some point, playing isn't the thing holding you back anymore. This is what pure vibe coders often miss. Those first lines of code were hard for us too. We kept going because the reward came later. You can't judge a craft by how it feels in the first few days. Eventually, writing code stops being the hard part. Then you learn a new language and get humbled all over again. Even that gets easier with experience. Once you develop fluency, the fun part begins. You can make what you see in your head. So I get why people love vibe coding. They get to skip the hard part and jump straight to the thing they imagined. The first time it works, you understand the feeling a programmer gets when they first see "hello, world" appear on the screen. And sure, some coders are probably bitter that nobody has to suffer the indignity of playing "Hot Cross Buns" a hundred times anymore. But with enough practice, code stops being in your way. It becomes something you can use from memory. AI makes that faster. But it can't manufacture earned inspiration. After enough time with AI, I can see that writing the code served another purpose. It slowed us down. We spent more time sitting with the problem, testing what we were building, and using it as it took shape. Planning, building, testing, and refining kept our hands on the strings. When we solved problems we had not lived ourselves, that work showed us where the pain lived. The best engineers I knew got better at caring about that experience as they built. The worst ones got lost in the code and forgot the person using it. This will be true for vibe coders too. Many are solving problems they know well. They have a job, a problem they wish they had the time or money to fix, and now they can. That is great. If you have years of experience in another field, AI can give you leverage you did not have before. But you can't experience problems through AI alone. If you're new to the workforce, or if you make your living like I do helping other people solve problems with software, the work used to put you closer to the pain. I spent more than a decade writing code for other people. Before that, I worked a lot of different jobs in a lot of different industries. I grew up in a world where friction was not optional. Those things showed me problems worth solving. Learning the tools taught me how to solve them. Slowing down gave us time to think, observe, and refine. It gave us time to sit with the same riff, playing it over and over, slowing it down, speeding it up, then slowing it down again, listening for what came next. The challenge now isn't whether it's necessary to code. It's how you make room for unproductive waiting in a world that wants you racing forward. --- # You Can't Reverse Engineer Taste AI can help you imitate what already works, but developing your own point of view requires living, making things, getting lost, and trusting your eye. Published: July 10, 2026 Tags: AI, Creativity, Product Building Canonical URL: https://michaelrispoli.com/blog/you-cant-reverse-engineer-taste/ When I was in college, I was at a bar with a friend and a Kings of Leon song came on. She said, “Oh my God, I hate that I love this song.” I said something like, “Well, it’s pretty popular, so it must be pretty good.” Man, she almost tore my head off. Popularity had almost nothing to do with whether something was good to her. If anything, it worked against the song. Part of her taste was built around liking things that not a lot of other people liked. You see this constantly in music, books, art, film, and even software. Some people love things precisely because they do not feel mass-market. Being a little strange, a little inaccessible, or a little difficult to explain at a dinner party is part of the appeal. I had a friend who absolutely loved Primus. I have listened to Primus and I don't get it. It just is not for me. But the people who love Primus *really* love Primus. Then I saw Les Claypool play a solo show, and loved it. When I found out he was the bassist and frontman of Primus, I was blown away. Same musician, different context, different experience. Good is not a clean, cut-and-dry thing you can define in a dashboard. It depends on the aesthetic, the context, and the audience. Sometimes it depends on how many other people already like the thing. Sometimes it depends on whether you encountered it at the right time, in the right room, with the right people. Products work the same way. An interface that feels obvious to one audience can feel sterile to another. A tool that seems too strange for the mass market can be exactly right for a smaller group of people who have been waiting for someone to make it. Everybody is talking about taste right now. In AI, product building, software, design, and whatever else we are all pretending to have figured out this week, it has become the final remaining human advantage. The thing the machine cannot do. The thing separating the person who can use AI from the person who can make something good with it. But the conversation is a little too clean. We talk about taste as if it is a fixed trait. Some people have it. Some people do not. Some people were born with a better eye, a better ear, a better sense of what belongs where, and everyone else is stuck trying to reverse engineer it from mood boards, Twitter threads, and YouTube videos about building better products. At AIE Miami, someone asked how you cultivate taste. One of the better answers was that you cultivate it by living life. Not by locking yourself in a room and obsessing over your specialty forever, but by doing almost anything else. Reading books. Listening to music. Going to brunch with friends. Traveling. Having conversations. Getting out into the world. Actually being a person. It reminded me of a story Trevor Noah tells about meeting Chris Rock. Trevor told him he was doing comedy seven nights a week, and Chris basically said, “Wow, you are going to be terrible at comedy.” Trevor didn't understand. Isn’t that what you are supposed to do? Work harder? Do more reps? Get on stage every night? Chris Rock's point was that comedy comes from living. If comedy is all you do, you have no real material to work with. You may get better at being on stage, but then being on stage is all you have left to talk about. Sometimes you have to step away from the art to do a service to the art. Software has the same trap. You still have to make things and get your reps in. But if you only stare at software, read about software, listen to software people talk about software, and then build software inspired by other software, your view of what is good becomes very narrow. You become optimized for the opinions of people trapped inside the same room. The audience can also arrive late. Van Gogh found little commercial success and remained largely unknown during his lifetime. Other artists admired his work, but the broad public acclaim came later. The paintings did not change after he died. The audience did. Sometimes people reject your work because it is bad. Sometimes it is just not for them. You may not have found the right audience, or you may be early. Plenty of ignored things are ignored because they are not good, but applause is still a shallow substitute for judgment. Online, we look at what gets attention, what gets shared, what looks impressive, and what fits the current aesthetic, then try to move toward it. Chasing the appearance of good taste is one of the easiest ways to avoid developing your own. Before the work leaves your hands, it still has to please *you*. You release it, people respond, and you learn from what happens. But the response cannot become the source of the work. If the imagined judgment of the internet is sitting on your shoulder from the beginning, you are not developing judgment. You are chasing approval. You're learning to win popularity contests, not produce great work. You have to make things you are proud of and sit with them long enough to know whether they feel right before the internet tells you what they are supposed to be. You cannot control how the work will be received. You can control whether you made the thing you meant to make. Lately, I have caught myself consuming more than I was making. Because of AI, I probably consume more examples of other people’s work than I ever have before. I am always looking at what everyone is doing: the tools they use, the workflows they build, how they use agents, how they think about loops, state machines, coding assistants, software factories, and all the other strange new machinery surrounding us. Some of that is useful. You should know what is happening in the world. But at a certain point, I was reading too much, watching too much, and absorbing everyone else’s framing before I had spent enough time with my own. So I decided to do the opposite. I started working on my own workflow tool around loops, state machines, and software development. Instead of reading every blog post I could find and choosing the best open-source version of someone else’s idea, I decided to build my own from first principles. Yes, I am still building it with AI. But I am not using AI to replace my sense of what the thing should be. I know the developer experience I am after. I know the feeling I want from the tool and the kinds of workflows it should support. I know what feels too heavy, too abstract, too clever, or like something I would never actually use. The only way to learn any of that is to go slower, sit with the thing longer, and resist polluting the work with everyone else’s conclusions before I have reached my own. The line between inspiration and pollution is thin. Consume too much before you make and you start inheriting other people’s assumptions. You see the problem through their categories. Their solution begins to look like the natural shape of the thing. Then you never wander, and wandering is where a lot of the good stuff happens. When you rebuild something from first principles without checking where everyone else has already been, you give yourself permission to get lost. You stumble into little problems. You make weird choices. You take the long way. You misunderstand something. You invent a worse version of an existing thing. And sometimes, along the way, you find one small idea that is yours. There is no correct answer. You make something true, release it, and sometimes watch people misunderstand it. Your judgment has to survive that. AI makes this harder even as it makes producing easier. It can write the code, generate the mockup, draft the copy, build the prototype, and polish the result until it looks more finished than it has any right to be. It can also pull you toward the average. It makes it easier to imitate what already exists, smoothing and polishing your work while quietly sanding off the part that made it yours. Better prompts, more automation, and faster releases do nothing to protect your point of view. Live enough life that you have something to say. Build enough things to develop judgment. Consume enough to be literate, but not so much that you become derivative. Wander long enough to stumble into something you would not have found by following the map everyone else already made. I still build products for other people. I want the work to land. I want people to use it, love it, tell their friends about it, and feel like somebody made the thing the right way. Making something for people can be generous. Making it by committee is how you end up with garbage nobody cares about. Not the committee, not the audience, and not even you. I was wrong in that bar, but not for the reason my friend thought. Popularity does not make something good. Obscurity does not make it good either. At some point, you have to stop borrowing answers, trust your own eye, and make the thing the way you see it. --- # Is AI the End of Engineering, or Just the Beginning? AI is eating some old software work, but it is also creating a new category of engineering: turning half-working AI systems into durable business tools. Published: June 27, 2026 Tags: AI, Engineering, Product Engineering Canonical URL: https://michaelrispoli.com/blog/is-ai-the-end-of-engineering-or-just-the-beginning/ There's a pattern that keeps showing up in the businesses I talk to that want to implement AI. Someone inside the organization, usually not an engineer, builds something they probably would have paid me to build in the past. Maybe they spin up a little data dashboard. Maybe they put together a landing page. Maybe they fix some part of an existing project, or revive some abandoned thing that never quite got finished. Either way, it is usually a product manager, designer, marketer, operations person, or founder doing something they did not have the power to do before. And then the thing starts to work. Not fully. Not perfectly. But enough. It gets just useful enough that the team starts depending on it. The team starts to ask for new features. Managers and IT staff start to ask about how it works. It needs to meet security requirements. It needs to connect to the right systems. It needs to stop randomly breaking. It needs polish. That is usually where I enter the conversation. A lot of engineers look at this and understandably say, "Well, this could be the end." If these models keep getting better, maybe they will eventually handle the engineering part that these people are currently getting stuck on. I understand that fear. A lot of the easy work is disappearing. People are not paying as much to have someone spin up a simple landing page. They are not always paying someone to configure a CMS. They are not always paying for the little dashboards, the internal tools, the basic websites, or the quick fixes that used to be great bread-and-butter work. That work was not always difficult, but it was income-generating work. But I think there is another possibility here. AI may not be the end of engineering. It may be the beginning of an entirely new category of engineering work. Because what I keep seeing is that people can now get much further than they used to. A non-technical person can build something that looks and feels real. They can get a dashboard working. They can prototype a workflow. They can duct tape together a tool that actually helps the business. The tool's usefulness can be verified before the business ever spends real money building it. But then they hit the wall. And the wall is not always "the model is not good enough." The wall is usually that they do not know what to ask for. They know how to describe features, but they don't know how to describe good software. I see this all the time. Inexperienced people are using the best model money can buy. They are saying, "I'm just going to use GPT-5.5 for everything," or Claude Opus, or whatever the current monster model is. Maybe they have an AI budget. Maybe they do not. But either way, they start burning through tokens. I have one client that burned through an entire paycheck's worth of tokens trying to build a thing. And the crazy part is the project probably did not require that much token burn. The issue was not that the work was impossible. The issue was that they did not know how to communicate what they were asking for in a specialized way. Every field has terminology. Design has terminology. Medicine has terminology. Engineering has terminology. Law has terminology. Sometimes one correct word can express what would otherwise take paragraphs to explain. A single term, a handful of tokens, can point the model toward the exact shape of the thing you want. But if you do not know that term exists, you end up writing paragraph after paragraph of prose trying to describe something that already has a name. That is where a lot of waste happens. The user is trying to explain a concept the field already solved. The model is trying to infer what they mean. They go back and forth. The conversation gets longer. The context gets messier. The cost goes up. The quality goes down. This is one reason I feel fortunate that I came into software before these tools existed. I had to learn the terminology. I had to learn the algorithms. I had to learn the pesky Gang of Four design patterns. I had to learn the annoying little Linux commands. I had to learn what things were called. That does not mean I can implement every possible algorithm in every possible programming language from memory. Nobody can do that. But I do know broadly what I am looking for. I know the language of the space. I know how to say the thing correctly in a small number of words. This translates to token savings. And weirdly enough, this brings me to one of my favorite sports: rock climbing. I was raised rock climbing. I learned to traditional lead climb from my uncle, who came up in an era where climbers used very basic, simple machines to protect climbs. They had nuts, chocks, hexes, and other pieces of what we called passive protection. These were basically pieces of metal attached to wire cable that you would wedge into the rock. Ideally you wanted a V-shaped notch in a crack, something that would allow the piece to seat itself securely. If it was a horizontal crack, you might place a hex, which like its namesake was hexagonal in shape and you could kind of cam it into position. There were also tri-cams, which did something similar in their own strange little way. But the basic idea was the same. You were wedging small pieces of metal into the rock and trusting them to hold you if you fell. Then along came a little technology called the spring-loaded camming device. Wild Country made one of the iconic early versions, called Friends, and they changed everything. A spring-loaded camming device has lobes that contract when you pull the trigger and expand when you release it. You place it into a crack, let it expand, and when it is weighted during a fall, the outward force is magnified by the geometry of the device. That meant you could protect cracks that were very hard, or sometimes nearly impossible, to protect with passive gear. They worked in flaring cracks, where the crack rounds outward toward the edges. They worked in horizontal cracks. They could handle multidirectional forces better than many passive placements. If you placed a hex in a horizontal crack and the rope jerked it upward, it could come loose. So you had to think carefully about extending the connection point between the rope and the gear to prevent that from happening. Cams changed the calculation. They were faster to place. They fit in more places. They made climbers feel more secure. They opened up new routes. But they came with a cost. They were bigger and took up more space on your harness. They were also heavier. Today, modern gear is much lighter, but back then a lot of these spring-loaded devices had metal stems and real heft to them. You had to make a trade-off. Do you carry more active protection because it is easier and fits in more places, or do you carry lighter passive protection because you know how to place it well? We have to make the same trade-off with AI in software. Do you throw masses of tokens at it until you get what you want, or do you have the precision to use a simple incantation for the same output? If you are good at placing passive protection, you do not need to haul an entire rack of heavy cams up the wall. You can move more efficiently. You can preserve energy. You can make better decisions because you have more tools available to you. The same thing is true with AI. If you know how to get great work out of lighter-weight models, you become more token efficient. You are preserving the amount of weight you are hauling up the wall. Your strength, your budget, your context window, your patience, all of it lasts longer. Not everything needs the biggest model. Not every task needs the heaviest tool. Sometimes you need the expensive spring-loaded camming device. Sometimes you just need a nut that fits perfectly. The engineer who knows the old ways has an advantage here. That does not mean we reject the new tools. Quite the opposite. The birth of the spring-loaded camming device opened up climbs that were previously considered unsafe to lead. There is a famous climb my uncle showed me called *Mr. Machine*. It was named so because it was one of the first climbs done with these spring-loaded camming devices. The climb had a series of horizontal, flaring cracks with rounded-out shapes that were basically impossible to lead safely with the passive protection climbers had before. Sure you could solo it and risk death and serious injury. But to lead it the way us mere mortals do, from the ground up with a rope, you needed cams. The new technology did not remove the need for climbing skill. It opened up a new world where skill could be applied. Nobody before that had fully conceived of a world where removable protection could be placed that quickly, hold that securely, and work in that many strange features of the rock. Once the gear existed, climbers started looking at walls differently. As climbing gear got better, we got lighter cams, smaller cams, offset cams, flexible-stem cams, micro protection, and all kinds of newer, lighter, stronger, more specialized tools. Each improvement opened up new possibilities. New generations of climbers looked up at walls and saw lines the previous generation did not see, not because the previous generation lacked courage or imagination, but because the gear changed what was possible. AI is doing something similar to computing. We are entering the world of non-deterministic computing, and everyone is trying to learn the latest thing. Every time a new model comes out, we all go, "Oh my God, everything has changed forever. Nothing will be the same. Learn this or be left behind." But that is a silly way to look at it. You are not "left behind" because spring-loaded camming devices exist. You are left behind if you refuse to understand what they now make possible. You have to look at technology through a new lens, the same way climbers had to with their newfound power. The new generation of engineers will still have to learn the old ways. They will have to understand the old tools, the old commands, the old systems, the old engineering process. Because guess what? That stuff still comes in handy. When I go up a wall, I still make the trade-off. If a piece of passive protection fits perfectly, I place it. I do not waste a cam just because cams are newer. The same is true at a computer. If I can type a bash command faster than I can ask Codex to do it, I should type the bash command. Moving a file from one directory to another is not some grand prompt engineering challenge. It is `mv`. Copying a file is `cp`. We should not be sitting here saying, "Well, I do not need to learn any Linux commands anymore because I have Codex." You can look at it that way, but it is definitely more characters to say, "Move this file from this path to this other path," than it is to type the command. Learning this stuff is still useful if you want to use a computer efficiently. At the same time, there are now parts of applications that are possible that were not possible before. There are interfaces that can exist now because we have this strange new ability to loosely ask a machine what we want and get a reasonable response back. The interfaces of the future are probably not all going to look like ChatGPT or Claude. They are going to be specialized machines. They are going to be workflows, tools, agents, dashboards, terminals, canvases, editors, and strange new compositions we have not fully imagined yet. A little while ago, everyone thought AI coding was going to live mostly inside IDEs. Then tools like Codex and Claude Code pulled people back into the terminal, this old thing we supposedly moved beyond. Cursor has a CLI and cloud-agent workflows with shared terminal sessions. Now people are asking whether the future is agents, loops, Kanban boards, plan mode, terminal sessions, or some combination we do not have a name for yet. We are in a state of extreme innovation. And all of that has to be built by engineers. Not because engineers have a monopoly on ideas. They do not. In fact, many of the best ideas will probably come from people outside engineering, because they are closer to the business pain. They are the ones inside the organization duct taping together these first strange little tools with AI. But engineers are going to be the ones who know how to turn those ideas into durable systems. They are going to know how to configure these models, connect them to real data, control their behavior, manage cost, build guardrails, design workflows, handle permissions, satisfy security requirements, and combine older engineering processes with this new AI-native layer. That is the work that has not fully arrived yet. Or maybe it has arrived, but we do not have clean names for it yet. This brings me back to why businesses are reaching out to me now. They usually wet their whistle by building something themselves. They get a little app working. They use AI to solve some annoying internal problem. They build a tool that is kind of working but kind of not. Then they start wondering if more is possible. Could it read documents? Could it follow a workflow? Could it make recommendations? Could it connect to their CRM? Could it follow their security rules? Could it be governed? Could it handle weird edge cases? Could it be cheaper to run? Could it become something the business actually depends on? That is where the old and new worlds meet. And that is where engineering is not ending. It is changing shape. Yes, some parts of the industry are in a state of atrophy. I think we have to be honest about that. A lot of the work people used to pay for is being eaten by tools. The landing pages, the basic websites, the simple dashboards, the CMS configuration, the little pieces of glue code. Some of that work is gone, and some of it is not coming back in the same form. But the new thing is coming. When we look up at the wall now, we have to ask: what is the new Mr. Machine? What is the climb that was not possible before this gear existed? Those ideas will lag behind the technology at first. It takes ingenuity and imagination to find these novel use cases. It takes weird people staring at the wall and seeing something others do not see yet. It takes business owners realizing they no longer need you to build the simple website, but they do need you to help make this half-working AI system real. And as more of these systems show up, more people will start to understand what is possible. They will not call and say, "Can you build me a landing page?" They will say, "I put this thing together. It works, kind of. It is costing me a lot of money. It breaks in weird ways. There is a bunch of stuff I want it to do. I need someone to make this reliable because we've created something valuable." That is not the end of engineering. That is a new wall. And we are only just starting to see the new lines that are possible. --- # The Problem With Abundance AI may make digital things cheaper and easier to produce, but the scarce things people actually want will still be controlled, priced, and protected. Published: June 26, 2026 Tags: AI, Opinion, Society Canonical URL: https://michaelrispoli.com/blog/the-problem-with-abundance/ I keep hearing a certain word from the techno-optimist world when it comes to what AI will bring to us all. That word is *abundance*. We are told that AI is going to make everything cheaper, so cheap that everyone can have anything. It is going to make everyone more productive. It is going to give people more time, more access, more opportunity, more creativity, more of everything. And maybe some of that is true. But I think a lot of very wealthy people are genuinely confused by the public skepticism around AI. They wonder why students are booing AI speeches at graduation and why communities are pushing back against new data centers. They seem to look at the reaction and say, "Why are people so afraid of this? Don't they understand that we are trying to build a better future for them?" The skepticism is not just about the technology. It is about who controls the technology. It is about who benefits first. It is about whether the same people promising abundance have any real interest in sharing the parts of life that are scarce. That is the part the abundance crowd does not seem to understand. A lot of Americans have spent enough time on the lower rungs of society to know exactly how the people at the top often look down at everyone else. They may not say it out loud in public. They may have better PR teams. They may wrap it in language about innovation, access, opportunity, and the future. But every once in a while, the mask slips. And when it does, people notice. So when the same class of people tells everyone, "Trust us, AI is going to create abundance for you," or "you'll just buy intelligence on tap, like water," a lot of people hear something else. They hear, "We are going to own the machines, own the platforms, own the models, own the data, own the distribution, own the capital, you'll just pay us forever for it, and this will be wonderful for you." You can see why someone might be skeptical of this kind of message. The reality is for most Americans, the price of everything has gone up. The cost of living has gone up. And they're not really seeing the fruit. The other problem with abundance is that it is not possible for everything. We can create abundance in some areas, but not in all areas. Technology can make *stuff* cheaper, faster, easier, and more accessible. But there will never be an abundance of floor seats at a Knicks Finals game. There will never be an abundance of first-class seats on a flight. There will never be an abundance of the best restaurants, beautiful views, country clubs, beachfront property, or the quietest places in the world. Some things are valuable because they are scarce. Some things are valuable because not everyone can have them at the same time. I think about this a lot through climbing. When I was growing up rock climbing, I remember when you could just pull up to the crag and get on any three-star classic climb you wanted. You could show up with a friend, rack up, tie in, and spend the day on the wall in the sunshine, testing your limits on something real. That experience is not just the grade of the route. It is not just the rock. It is the place, the weather, the person holding the rope, the feeling in your hands, the little bit of fear before you commit, and the quiet satisfaction of topping out because you actually did the thing. You cannot digitally recreate that in a way that is true to the reality of being there. The same is true of a perfect powder day at Highlands Bowl in Aspen, when the snow is right and the mountain feels open. Anyone who has had one of those days knows exactly what I mean. It is not just skiing. It is the air, the light, the effort to get there, the first turn, and the fact that you were lucky enough to be in the right place at the right time. Now you can scarcely go anywhere without being mobbed by crowds. The routes are crowded. The trailheads are crowded. The mountains are crowded. The beaches are crowded. The restaurants are booked. The secret spots are on Instagram. The world did not run out of entertainment. It ran out of quiet access to the things that make you feel alive. You can make a beautiful television and tell people they can watch the game at home. And to be fair, watching sports at home is better than it has ever been. The picture is incredible. The camera angles are incredible. You can get highlights, stats, replays, and analysis instantly. But that is not the same thing as sitting on the floor. You can build a ski simulator. You can build a VR mountain. You can put someone in goggles and give them a pretty convincing version of a run. Maybe someday it will be amazing. But anyone who has ever been on a real mountain, on a perfect day, when the snow is right and the crowds are thin, knows that the simulation is not the thing. The thing *is* the thing. And the thing is scarce. It is the same with the concert you will always remember. You had to be there. You can stream the album. You can watch the footage. You can generate a synthetic version of the artist, the crowd, the lights, the set list, the whole thing. But you cannot manufacture the real thing and make it abundant in the same way for everyone. The best things in life are free, as they say. The next best things are really expensive. That is where the abundance conversation starts to feel silly. Let's say AI does create some future where the basics are easier to provide. Let's say food, education, entertainment, and basic services become much cheaper. Let's say people work less. Let's say people have more free time. What do people do with that free time? They try to do the things that are *not* abundant. They travel. They go to games. They ski. They climb. They golf. They eat at the restaurant everyone wants to eat at. They go to the beach town that only has so many houses. They try to get into the room, the club, the event, the school, the neighborhood, the experience. And then the price of those things goes up because they cannot scale. You cannot solve that with another GPU cluster. You cannot prompt-engineer more oceanfront. You cannot vibe-code another Madison Square Garden floor. You cannot create infinite quiet mornings on a mountain with fresh snow and no lift line. So we end up in this very strange place where the world may become abundant in the things that are easiest to digitize, automate, and distribute, while becoming even more brutally competitive around the things that cannot be copied. That is not an abundant utopia. It's just a more comfortable waiting room. And this is also where the conversation about work gets more complicated. People love to say that if nobody had to work, everyone would be free to pursue meaning. Maybe. But work is often where people discover meaning. Structure, obligation, contribution, even in small ways, matter to people. Strip all of that away and hand people infinite entertainment, and I am not sure you have created the paradise you think you have. And once people get bored, they will want the real things. The scarce things. The human things. The things that require place, proximity, access, and status. Those things will still have a line outside. So when wealthy technologists talk about abundance, I think people hear the missing sentence. They hear, "There will be abundance for the stuff we can manufacture, but scarcity for the things we still want for ourselves." That may sound cynical, but it is not irrational. People are not stupid for distrusting the sales pitch. They are not backward for wondering whether AI will mostly enrich the people who already own everything. They are not anti-progress for noticing that the people promising a frictionless future often have no intention of giving up their own frictionless lives. It sounds like someone trying to sell you the Brooklyn Bridge. People are right to ask a few questions. And when the people at the very top promise abundance for everyone, the public is right to be skeptical. Because people do not only want more content. They do not only want faster apps. They do not only want cheaper summaries, automated workflows, AI tutors, synthetic media, and infinite generated slop. They want dignity. They want meaning. They want to contribute. They want to know that the people building the future do not secretly see them as a crowd to manage, a cost to reduce, a labor force to replace, or a mass of outsiders waiting beyond the velvet rope. That is the trust problem AI has. It is not just that people fear the machine. It is that they do not trust the people holding it. --- # Cracking the AI Code Interview The engineering interview has to change. In the AI era, the work is not just writing code faster. It is judgment, cost, quality, communication, and knowing what should be built at all. Published: June 17, 2026 Tags: AI, Engineering, Hiring Canonical URL: https://michaelrispoli.com/blog/cracking-the-ai-code-interview/ I have been thinking a lot about what the engineering interview is supposed to look like now. For a long time, I still believed some kind of coding portion belonged in the interview. Honestly, I *think* I still do. Engineers should not let their basic coding skills atrophy. Plenty of companies are going to keep asking people to write code on a whiteboard, in a shared editor, or in some stripped-down environment long after the job itself has changed. So yes, you should still be able to code. But I run a smaller agency. I get to decide what matters here. And the more I think about it, the more obvious it becomes that the old interview format is increasingly testing the wrong thing. We dropped LeetCode-style interviews years ago because they were not especially relevant to the actual work we do. If someone was great at LeetCode but failed every other part of the process, they were not someone we were going to hire anyway. The job was never really "solve an abstract algorithm problem under artificial pressure." The job was: can you understand a messy client problem, ask good questions, make sound technical decisions, communicate clearly, protect the quality of the product, and ship something useful? AI has only made that more true. ## I Expect Engineers to Use AI At this point, pretending engineers are not going to use AI is absurd. My customers expect us to use AI. My company expects us to use AI. We are an AI-forward agency. I cannot seriously tell clients that we use the best modern tools to move faster and then design an interview process around pretending those tools do not exist. The whole hourly billing model is already under pressure. The idea that someone is going to come in, hand-code all day, and compete with what customers now expect is not realistic. The interview should not be built around catching someone without their tools. It should be built around understanding how they use their tools, when they trust them, when they do not, and how they know the difference. ## How Do You Experiment? A friend of mine, Scott Werner, made a point recently that stuck with me: all of these tools are still new. We are all still learning them, even the senior people. The best engineers I know are still changing their process every few months. They are trying new workflows. They are testing new models. They are figuring out when agents help and when they create chaos. They are learning where AI accelerates the work and where it just gives you a higher-velocity path into a ditch. So one of the first things I would want to understand in an AI-era engineering interview is not just: "What is your current process?" It is: "How are you evolving your process?" What are you experimenting with right now? How do you decide whether a new technique is better than the old one? When a new tool or method comes out, how do you evaluate it? What did you try that failed? What did you stop using? What still works? If someone tried a big agent loop, I want to know how they decided when it was useful. When did it break down? What kinds of tasks was it good for? What kinds of tasks did it make worse? Not every technique works for every problem. The way I use AI for product development and design is different from how I use it for data migrations. That is different from how I use it to evaluate a codebase. That is different from how I use it for code review. I want to know how an engineer chooses their technique based on the shape of the problem. That, to me, is one of the hallmarks of a good AI-era engineer. ## Curiosity, Not Dogma This was true before AI, but it is even more true now: dogmatic engineers are dangerous. There is a type of engineer who gets very attached to a method, a stack, a workflow, or a philosophy. Sometimes that can look like discipline. Sometimes it can look like confidence. We have to be open-minded about new methods. We also have to be suspicious of them. Both things have to be true at the same time. I would be deeply suspicious of someone who told me the only effective way to build software now is to spin up a thousand-agent swarm and let it run wild in some recursive loop until a product appears. I would also be suspicious of someone who said, "I just use GitHub Copilot for tab complete and otherwise nothing has really changed." Those are opposite ends of the same problem. One person has confused novelty for wisdom. The other has confused caution for professionalism. What I want is the person in the middle. Curious, but not gullible. Experimental, but not reckless. Skeptical, but not frozen. Someone who can say, "I tried this. It worked here. It failed there. Here is how I know." That is the engineer I want to talk to. ## Speed Is Not the Product Yes, moving fast matters but not at the expense of quality and security. Clients want speed, of course. Everyone wants speed. But the kind of clients we want also care deeply about quality. In the age of vibe coding, plenty of people can build their own stuff fast. When they come to my team, it is usually because they do not know how to get the quality back. When someone *buys* premium software, they do not want random bugs, sloppy UX, weird friction, or a product that feels like it was assembled by five interns and a chatbot during a long weekend. They want sharp, pointy tools that work under pressure. That means another major part of the interview has to be about quality. How do you ensure code quality when the tools let you move faster than ever? How do you review AI-generated code? How do you decide when to slow down? How do you know when speed is becoming the problem? AI makes you feel productive. It makes the screen move. It makes the branch grow. It makes the diff look impressive. But a bigger diff is not the same as better software. If we want to charge premium rates, we need to produce a level of quality clients cannot get everywhere else. Quality has to be part of the process, not something we try to sprinkle on at the end. So how do you as an engineer ensure quality with these tools? ## The Coding Interview Becomes a Problem-Solving Interview I like real-world, problem-solving interviews. I am less interested in watching someone perform syntax under pressure and much more interested in watching how they think through an unfamiliar domain. I like to pick a problem from a real client situation. Something not quite clear and ideally with a subtle human behavior problem underneath the technical one. Something where there isn't just one right answer or even a clear answer at all. Then I want to see what happens. Do they ask questions? Do they try to understand the business context? Do they jump into solutions too quickly? Do they assume software is *always* the answer? Do they know how to separate symptoms from causes? This matters especially in consulting and forward-deployed engineering. We work with nontechnical founders all the time. We also work with technical people who may be skeptical of newer AI-driven workflows or simply behind on what is now possible. So I need engineers who can work with both groups. Can you explain your process to a nontechnical founder without making them feel stupid? Can you bring a skeptical technical stakeholder along for the ride? Can you show your work in a way that builds trust? This is not soft-skill fluff. This is difficult stuff to cultivate but this is now the job. ## Writing Is an Engineering Skill Now I would also pay a lot more attention to writing. Can you write clearly? Can you explain the problem? Can you document your assumptions? Can you produce a plan another human can understand? Prompting is fundamentally writing. Specifications are writing. Technical plans are writing. Client updates are writing. Code review is writing. Product thinking is writing. Exceptional technical communication skills have always been important for team communication, but now they are essential to the work itself. If your written communication is muddy, your AI workflow is probably muddy too. This does not mean everyone needs to write like a novelist. But clarity matters. Precision matters. The ability to describe what you want, what you tried, what changed, and what you learned matters more than ever. The engineer who can write clearly has leverage. The engineer who cannot is going to struggle in a world where the interface to increasingly powerful tools is language. ## The Token Bill Is the New Clock There is another piece of this that I do not think enough people are talking about: cost. AI has created a strange new version of an old consulting problem. In the hourly world, the bad behavior was milking the clock. Running up the hours. Making a project take longer than it needed to because the billing model rewarded waste. In the AI world, the new version is token maxing. There are people and organizations operating as though there are no budget constraints at all. Some venture-backed AI labs can burn enormous amounts of money on tokens because experimentation is the entire point and cash is plentiful. That is not my world. It is not the reality for the vast majority of businesses either. In a consulting business, especially one serving small and mid-market companies, the token cost matters. The cost of the solution matters. The AI bill matters. The cost of implementation and maintenance matters. If someone is using a $100 or $200 a month coding plan to get better output, great. That is an easy conversation. If someone is running up an $8,000-a-day token bill on top of their own salary, there had better be a very strong reason. Not vibes. Not "it feels faster." A real reason. A business reason. A reason that connects to money, quality, speed, or some measurable advantage. I love engineers who understand ROI. I want to know whether you monitor your usage. I want to know whether you think about cost. I want to know whether you can decide when the expensive tool is worth it and when the cheaper workflow is good enough. Because "no budget" is not a real strategy. It is a fantasy you only get to live inside very specific organizations for very specific windows of time. Everyone else has to do the math. ## Sometimes the Best Code Is No Code Another part of the interview I would love to include is a problem where writing software is not the right answer. That tells you a lot about a person. Some engineers see every problem as a reason to deploy code. But we are not in the business of selling people work they do not need. We are not here to create software for the sake of creating software. We are here to be a trusted source. Sometimes the answer is a process change. Sometimes it is a spreadsheet. Sometimes it is better training. Sometimes it is deleting a feature. Sometimes it is telling the client, "You do not need to build that yet." That kind of judgment matters more now because AI has challenged the old notion of there's always too much software to build and too little time and money to do it. Just because something is easier to build does not mean it is worth building. A good engineer needs to be comfortable saying, "I do not think code is the answer here." That is not a lack of ambition. That is professionalism. That's how you build trust, which is really what we sell our customers at every interaction. ## The AI-Era Interview Has Two Halves If I had to summarize the engineering interview I am interested in now, it has two major halves. The first half is about process. How are you working through this new experimental phase? What tools are you using? How are you evaluating them? How often are you changing your mind? Where are you skeptical? Where are you excited? How do you protect quality while moving faster? I expect the answer to be unfinished because this new world is unfinished. We're all still learning and we should have the humility to say that. Anyone who claims to have this all figured out is probably not paying close enough attention. The second half is about business sense. Do you understand the product? Do you understand the customer? Do you understand cost? Do you understand ROI? Can you explain your work? Can you work with nontechnical stakeholders? Can you tell when software is not the solution? Can you make the business better, not just the codebase bigger? These are not bonus traits anymore. They are becoming the job. The AI-era engineer is not just someone who can produce code faster. The AI-era engineer is someone who can decide what should be built, how it should be built, what tools should be used, how much it should cost, how quality will be protected, and how to explain the whole thing to the humans paying for it. That is the interview I want to run. Not because coding does not matter. Because coding alone is no longer enough. --- # I Don't Need More Horsepower. I Need More Road. AI has made software teams faster than the feedback loop. The harder business problem now is growth, trust, distribution, and having enough road for all that horsepower. Published: June 17, 2026 Tags: AI, Product Engineering, Growth Canonical URL: https://michaelrispoli.com/blog/i-dont-need-more-horsepower-i-need-more-road/ A lot of people have been asking me if I have tried Fable Five yet. And the honest answer is, no. It is not because I do not think it is impressive. I am sure it is impressive. Every new model at this point is some combination of faster, smarter, more capable, and always more expensive. But here's the thing, I already have about as smart and capable a model as I'm going to need right now. My team is building software faster than I have ever seen software built before. Faster than my clients have ever seen it built before. In some cases, faster than we can review it and at this point, faster than users can use it and react to it. Software is not valuable because it exists. Software is valuable because someone uses it, gets something out of it, and then gives you some signal about what should happen next. We can build a feature in a day now, which is great. But then a customer has to discover it. They have to understand it. They have to care enough to use it. We have to watch the usage patterns. We have to listen to what they say. We have to decide whether the thing we built is producing ROI, creating value, or just adding another button to a screen that already had too many buttons. That takes time. You cannot release a feature on Monday, pile three more things on top of it by Wednesday, and pretend you are building a better product because the machine allowed you to move that fast. At some point, you are no longer developing software. You are burying feedback under output. And that is why the current models already feel fast enough for a lot of real business work. The accuracy of GPT-5.5 is excellent. It is far ahead of what we were using even a year ago. Last year we were using Sonnet and thinking, "This is incredible. This changes everything." And it did. Even then, we were already moving faster than most organizations could keep up with. Not just faster than their code review process. Faster than their users. Faster than their internal decision-making. Faster than the customer feedback loop. So when a new model comes out and the pitch is, "This is even more powerful," my reaction is not disbelief. My reaction is, "Okay, but is that the thing slowing me down?" Right now, for me, it is not. I would rather have better harnesses, better orchestration patterns, better ways to route work across different models so cost stays reasonable, and better systems for managing agents, reviews, tests, deployment, customer feedback, and product direction. But paying more money for a slower, more expensive model because it has more raw intelligence does not make business sense by default. Not when the thing I am doing already has more than enough horsepower. I think about this like my car. I drive a Dodge Challenger. My wife bought it for me when she saw me eyeing some older classic cars and thought *he doesn't need another project*. When we were looking at the different models, of course there was the Hellcat. There was the Demon. There were versions of this thing pushing close to a thousand horsepower. And I bought the six-cylinder model. It has something like 300 horsepower, which is already more than enough for a normal human being driving to get coffee or take his kids somewhere. A thousand horsepower sounds amazing. It is an incredible vanity metric. It is the kind of number that makes people lean forward and go, "Wait, what?" But I am not a race car driver. I do not drag race on the weekends. I am not taking the thing to a track. I am driving around town. I have not been pulled over for speeding in the last 20 years. Where I live, I can drive 55 miles per hour tops on most roads. If you live out in the desert somewhere and the speed limit is 95, fine. Guess what? Any consumer car can still do that. You do not need a thousand horses to go the speed limit or even a little beyond it. So if you buy the thousand-horsepower version, you are not buying it for practical utility. You are buying it because you love it, because you collect it, because it makes you feel something, because it is ridiculous in the exact way you want it to be ridiculous. And that is fine. But it is not because you needed that much car to go to the grocery store. That is how I feel about a lot of this AI model discussion right now. The horsepower is incredible. The benchmarks are impressive. The demos are wild. But in my actual business, speed is not the main problem anymore. We keep finding ways to move faster with fewer people involved using the models we already have. The question is not, "Can we build more software faster?" The question is, "Do we have enough of the right work to point all this capacity at?" And that is where things get hard again, maybe the hardest it's ever been. Because once you get all this AI leverage, the real problem shows up: you need more customers. That is the part I think a lot of businesses are starting to feel, even if they have not said it out loud yet. AI has helped companies get leaner. It has helped teams move faster. It has helped businesses trim the bottom line. You can automate some tasks. You can reduce headcount in certain areas. You can get more output from fewer people. You can become a much slimmer company. But you cannot cut your way back to prosperity. It is the same idea as personal finance. You can save money. You can spend less. You can get disciplined. But you cannot save your way into true wealth if there is no growth on the other side. Business works the same way. You can use AI to get lean. You can reduce waste. You can make the machine more efficient. But the company still has to grow. Revenue still has to come in. Customers still have to buy. Someone still has to want the thing. And that is as hard as it has ever been. In fact, AI has made it harder. Because if there is one place where AI has not produced the same kind of magic for me, it is marketing. The strongest use case for AI, at least from what I can see, is software engineering. It helps generate code, debug, refactor, build features, explore architecture, write tests, and move from idea to implementation faster than we ever could before. There is no doubt in my mind that AI is useful there. Marketing has been a different story. AI helps with the surrounding tasks. It helps edit clips. It helps organize content. It helps generate variations. It helps resize banners. It helps create rough drafts. It helps with production workflows that used to be painful and expensive. That stuff matters. But the core creative work? The thing that gets attention? The thing that makes someone stop scrolling, care, laugh, trust you, or feel like you understand something true? AI is not solving that for me. In fact, a lot of AI marketing feels like it is making the internet noisier. Look at your inbox. If it is anything like mine, there are 200 messages from AI-powered cold outreach companies telling you that their system will get you warm leads from cold email. Every one of them sounds the same. Every one of them has the same false familiarity. Every one of them has the same fake personalization. Every one of them is "checking if this is a priority" or "circling back" or "noticed you help companies scale" or whatever sentence the machine decided was the average of every mediocre sales email ever written. And the result is not better marketing. It is more noise. We have tried AI-style outreach campaigns. We have tried the automations. We have tried to use these tools to come up with creative that can get attention online. And the truth is, the output is boring most of the time. It is clean. It is competent. It is polished. But it is boring. People scroll past it. That is a problem, because marketing and advertising are not supposed to find the average of a thing. They are supposed to get attention. They are supposed to break a pattern. They are supposed to make someone feel something specific enough that they remember you. When everyone has access to "good enough" design, "good enough" copy, "good enough" video editing, and "good enough" campaign ideas, the baseline rises. But the baseline rising does not make everyone stand out. It makes everyone easier to ignore. That is why the podcast matters. We are there. We film it. We sit down. We talk. We disagree. We laugh. We try to say something real. The most time-consuming part is still the human part: being on camera, doing the work, and having something to say. AI helps us produce it. Tools like Riverside help us make something with a level of quality we could not have afforded or maintained years ago. AI helps with clips, edits, summaries, titles, repurposing, and all the other production work around the act itself. But everybody has access to that now. So the production baseline goes up, and now your podcast looks pretty good. Mine looks pretty good. Everyone's looks pretty good. But then you compare it to something like Diary of a CEO or Joe Rogan or any major show with a full human team behind it, and you can see the difference. Maybe the gap is 10%, but that 10% is everything. That last 10% is often the difference between good and great. It is the difference between "this looks professional" and "this feels alive." It is the difference between clean output and something people want to watch. And that last 10% still requires humans who care. Humans who know when a cut feels wrong. Humans who understand rhythm, emotion, timing, story, tension, and the strange little details that make something worth paying attention to. So yes, AI has helped us with marketing operations. But AI has not replaced the hard part of growth. The hard part of growth is still trust. The hard part is still attention. The hard part is still being in the room. The funny thing is, the more AI content floods the market, the more old-school human behavior seems to matter: conferences, coffee, handshakes, conversations, referrals, and sitting across from another person to understand what they are trying to do. That stuff is working because it is real, and real has contrast again. So when people ask me why I am not more excited about the newest, biggest, most powerful model, that is my answer. I am not against it. I am not unimpressed by it. I am not pretending the technology is not incredible. I just already have enough speed, I have enough horsepower, and I cannot put the pedal to the floor anyway. What I need is more road. What I need is more customers. More trust. More distribution. More human moments that create actual demand. More people who understand what we do and why it matters. Because once every company has trimmed itself down, once every team has automated what it can automate, once every business is running leaner than it used to, they are all going to run into the same wall. You cannot cut your way into growth, and you still have to sell, matter, and be chosen. And I do not think more AI-generated marketing noise solves that. By its nature, once everyone is doing it, it fades into the background. It ceases to be marketing and becomes atmosphere. So maybe the next great business advantage is not more speed. Maybe it is being more human in a world where everyone else is trying to sound like a machine pretending to be one. --- # The Agent Told Me It Was HIPAA Compliant AI can generate convincing healthcare software. It cannot declare your product safe, legal, or compliant just because the checklist looks complete. Published: June 15, 2026 Tags: AI, Healthcare, Cybersecurity, Compliance Canonical URL: https://michaelrispoli.com/blog/the-agent-told-me-it-was-hipaa-compliant/ A friend recently told me they had vibe coded a patient management system. Not a scheduling app. Not a little intake form. A full patient management system. Most importantly, they told me it was fully HIPAA compliant. So I asked the obvious question. "How do you know?" "The agent told me," they replied. This is the trap we are walking into with AI-generated software. We are not just asking agents to write code anymore. We are asking them to tell us whether the thing they wrote is safe, legal, secure, compliant, scalable, production-ready, and appropriate for real humans to rely on. And the agent, being an agent, will often give us the most dangerous answer in software: "Looks good to me." This gets especially messy with HIPAA because HIPAA compliance does not work the way many founders think it works. I find that people lump HIPAA and SOC 2 into the same bucket. However, SOC 2 has a more familiar shape. You hire an auditor. You define controls. You go through an audit window. You receive a report. It may be Type I or Type II. There is paperwork, process, and a thing you can point to when a customer asks. HIPAA is different. There is no SOC 2-style attestation report for HIPAA, and no official government-issued certificate that blesses your app and sends you into the world with a gold sticker. And yet we see that language everywhere. This database is HIPAA certified. This hosting provider is HIPAA compliant. This AI tool is HIPAA ready. When a vendor says it is "HIPAA compliant," what it usually means is not "some official governing body has certified our entire company and every possible way you might use this product." It usually means something closer to this: we have relevant controls, we may sign a Business Associate Agreement, we support encryption, we have access controls, we log activity, and we have internal processes around protected health information. Maybe they have done serious third-party reviews. Maybe they have mapped controls to HIPAA. Maybe they have a real security team. Maybe they are doing the work. That still does not automatically make your application HIPAA compliant. So when someone says they have a "HIPAA certificate," my follow-up question is always: Issued by whom? Was it an internal self-assessment? A third-party consultant? A security firm mapping controls to HIPAA? A training certificate someone received after watching a course? Did anyone review the actual product behavior, vendor agreements, policies, access controls, audit logging, risk analysis, incident response, and engineering workflows? Those are not the same thing. A serious third-party HIPAA assessment can be valuable. I am not saying outside reviews are fake or useless. A good compliance partner can identify gaps, document your program, improve controls, and create evidence that you are taking the law seriously. But that is not the same as an official government certification. And it definitely does not mean every product workflow, vendor integration, admin panel, logging tool, AI prompt, staging database, and support process is automatically safe forever. That is why "we have a HIPAA certificate" should not end the conversation. It should start it. What was in scope? What was out of scope? Did the review cover the actual application or only the infrastructure? Did anyone inspect how PHI moves through the system? Did they evaluate internal access to patient data? Did they review BAAs with vendors? Did they test audit logging? Did they examine breach response procedures? Did they look at whether developers can casually view plain-text PHI inside an admin interface? Without those details, a HIPAA certificate can just be security theater. It may look reassuring in a sales deck, but it does not tell you whether the system is actually being operated in a compliant way. This is the part people miss. HIPAA compliance is not a property you inherit by choosing the right database. You cannot sprinkle MongoDB, Neon, Vercel, AWS, or some AI coding agent over your app and suddenly become compliant. A compliant vendor can still be used in a non-compliant way. A secure database can still store the wrong information. An encrypted server can still expose patient data through a broken authorization rule. A good cloud provider can still be misconfigured. A signed BAA does not save you from bad product decisions. One of the clearest examples is something I see all the time: "The database is encrypted at rest." Great. Wonderful. Love that for the database. But then a developer logs into an admin panel, database browser, error monitoring tool, customer support dashboard, or internal UI and can see every patient row in plain text. Encryption at rest matters. TLS matters. Vendor due diligence matters. But none of that means much if every engineer can browse patient records over lunch. The data may be encrypted on disk, but operationally it is sitting there exposed in the tools your team uses every day. In a properly thought-through healthcare system, PHI should not be visible to engineers just because they work on the product. Access should be limited to the minimum necessary. It should be role-based. It should be logged. It should be reviewed. In many cases, it should require a break-glass workflow where someone has to explicitly justify why they are accessing sensitive data. "Encrypted at rest" is not the same thing as "protected from unnecessary human access." A lot of teams confuse infrastructure security with compliance. They look at the cloud architecture and say, "We are good. The database is encrypted. TLS is on. The vendor signs a BAA." But HIPAA is not only about whether the hard drive is encrypted. It is about who can access protected health information, why they can access it, whether that access is necessary, whether it is monitored, and whether the organization has controls around how that information is used. The uncomfortable truth is that HIPAA compliance is not just infrastructure. It is architecture, operations, policies, people, process, training, access control, auditability, risk management, incident response, and a real understanding of where protected health information lives in your system. It is not one thing. It is not a checkbox. It is not something an agent can declare after generating a Rails app on a Tuesday afternoon. Broadly speaking, when people talk about HIPAA compliance, they are talking about whether the organization and system can protect PHI, which means protected health information. That means asking questions like: Who can access this data? Why can they access it? What do we collect? Do we actually need all of it? Where is it stored? Is it encrypted in transit and at rest? Which vendors touch it? Do those vendors sign BAAs? What happens when an employee leaves? What happens if a laptop is stolen? What happens if a patient asks for their data? What happens if there is a breach? What gets logged? Who reviews those logs? How do we know someone did not access something they should not have? And maybe the most important question: How do we prove any of this? Because "the agent told me so" is not proof. When it comes to HIPAA, compliance isn't just something you obtain. You can't just look at the code and determine it. It is embedded into the way your organization operates. You do not become HIPAA compliant once and then stop thinking about it. You maintain it. You review it. You update it. You train people. You evaluate vendors. You respond to changes in the product. You revisit permissions, risk, and assumptions. This is also why it is wrong to talk about HIPAA compliance as if it means "a breach can never happen." Major hospitals, insurers, clearinghouses, and healthcare vendors get breached. Some have sophisticated teams, expensive tools, compliance programs, lawyers, security policies, and signed agreements all over the place. Attackers still get in. Change Healthcare is the obvious modern example. This was not a weekend project with a login screen and a dream. It was a major healthcare technology company inside UnitedHealth Group, processing a massive share of healthcare claims infrastructure in the United States. In 2024, it suffered a ransomware attack involving protected health information. The lesson is not "therefore compliance is fake." The lesson is that compliance does not mean nothing bad ever happens. Compliance means you have the systems, records, policies, logs, contracts, and procedures to know what happened, what systems were affected, what data may have been exposed, who needs to be notified, who is responsible, and what happens next. A serious HIPAA program should help you answer ugly questions after an incident. When did the attacker get in? What did they access? Was PHI involved? Which individuals were affected? Which vendors were involved? Were the right agreements in place? Who needs to be notified? What controls failed? What are we changing so it does not happen the same way again? That is part of what compliance is. It is not a force field. It is a system of accountability. This is why the AI era makes the problem both better and worse. AI can help generate the first version of a policy. It can map data flows. It can summarize HIPAA requirements. It can write security checklists. It can identify obvious risks in code. It can produce documentation that would have taken a team days to assemble manually. But AI can also create an extremely convincing compliance-shaped object. It can write the code, write the policy, write the privacy page, generate the checklist, and tell you the checklist passed. If nobody in the room knows enough to challenge it, you now have the illusion of compliance at software speed. That is the danger. Not that AI writes bad code. Bad code is fixable. The danger is that AI writes plausible code, wraps it in plausible documentation, and gives a plausible explanation for why everything is fine. A shocking amount of compliance risk hides in boring places: error logs, analytics tools, customer support dashboards, session replay software, email notifications, PDF exports, CSV downloads, AI prompts, internal admin panels, backups, staging databases, and screenshots in Slack. The real world of HIPAA is not just "is my production database encrypted?" It is "did someone paste a patient note into a support ticket that is now sitting inside a tool with no BAA?" It is "does our bug tracker contain screenshots of medical records?" It is "can every developer open the database and read patient rows?" It is "are we sending PHI to an AI model without understanding what happens to that data?" That is where systems fail. So how do you handle this yourself? The easiest first step is to evaluate whether you actually need all the PHI you are collecting. Many founders bias toward collecting more information than they need in case they need it someday. Data can be a moat for a company. But that data can also increase your risk substantially. After you've determined you're collecting only the data you need, start treating HIPAA as an operational system, not a marketing claim. You map every place PHI enters, moves, rests, leaves, and gets destroyed. You make sure every vendor that touches PHI is willing to sign a Business Associate Agreement. You implement strong access controls, not just login screens. You encrypt data in transit and at rest. You separate roles and permissions. You prevent engineers from casually browsing PHI. You log access to sensitive data. You review those logs. You write actual policies and make sure the team follows them. You train the people who touch the system. You create a breach response plan before there is a breach. You perform a real risk analysis and update it as the product changes. You document your decisions. And when the stakes are high enough, you bring in a qualified compliance or legal expert who understands healthcare. One of the worst follies in software is believing that technical competence automatically creates legal or regulatory competence. A great engineer can build an insecure healthcare app. A great product team can design a workflow that collects far more sensitive data than necessary. A great AI agent can confidently misunderstand the entire compliance model. That is why the phrase "fully HIPAA compliant" should make us a little suspicious. Not because it is always false, but because it is usually incomplete. The better statement is more specific: We have performed a HIPAA risk analysis. We know where PHI exists in our system. We have signed BAAs with vendors that touch PHI. We have administrative, physical, and technical safeguards in place. We have documented policies and procedures. We have audit logs and access controls. We have limited internal access to PHI. We have a breach response process. We have reviewed this with someone qualified. That is a very different sentence than "the agent told me." The future of software is going to include a lot more people building things they never could have built before. That is mostly good. But in healthcare, finance, education, and other sensitive spaces, the ability to build faster does not remove the obligation to think harder. If anything, it raises the bar. Code is cheaper than ever but good judgment is more valuable than ever. And the real question is not whether an agent can generate a patient management system. Of course it can. The question is whether anyone involved knows enough to know when the agent is wrong. --- # The Software Factory Works Best After You Know What You're Making Agent loops are powerful for mature systems with known patterns. Product discovery still needs human judgment close to the work. Published: June 12, 2026 Tags: AI, Product Strategy, Software Delivery Canonical URL: https://michaelrispoli.com/blog/the-software-factory-works-best-after-you-know-what-youre-making/ There is a lot of talk right now about agent loops. And to be clear, I get it. The pitch is seductive because it is not entirely wrong. You write a great spec for the feature you want to build. You do this with the help of an agent. You ask it to interrogate the shit out of you, then you interrogate the shit out of it, and the two of you bang around ideas until you have a very well-formed markdown plan. At that point, the promise is that you can drop the plan into the machine. The agents enter the loop. Plan the feature. Code the feature. Test the feature. QA the feature. Fix the feature. Review the architecture. Review the security. Review the UI. Repeat until done. Sometimes there are multiple layers of agents involved. I have heard of people running workflows with dozens of subagents reviewing a feature from different angles. Product review. Architecture review. Test review. Security review. Design review. Code smell review. Documentation review. The whole thing becomes a little software factory humming along in the dark. And honestly, I believe it works. It may use a shitload of tokens, but after enough passes through enough thoughtful agents with enough well-written skills, the output can get damn near great. The mistake is assuming that this is now the correct way to build all software. It isn't. It is the correct way to build some software. And the difference matters. The loop works best when the shape of the thing is already known. If the architecture is mature, the design system is stable, the product patterns are established, and the work is mostly a matter of producing another well-understood part, the software factory can be incredible. Need another admin table that follows the existing patterns? Great. Need to add a new endpoint that behaves like the other endpoints? Perfect. Need to create another settings page using the same UI kit, same form structure, same validation patterns, same authorization model? Let the machine cook. This is where agent loops shine. The system has rails. The product has gravity. The design language already exists. The architecture already has opinions. The agents are not inventing the world; they are manufacturing parts that fit into a world that has already been invented. That is a very different task from figuring out what the product should be. A lot of my work does not start with a mature system. It starts with a problem, a half-formed product idea, a user who might not know what they need yet, and a bunch of assumptions that are probably wrong in at least three places. That kind of work is not factory work. That is product work. And product work is messy. It involves UX design, product judgment, technical tradeoffs, deep thinking, timing, sequencing, and a lot of staring at something you thought was going to be great and realizing, ten seconds after seeing it on the screen, that it is actually kind of bad. This is why I do not personally run long autonomous loops for hours and then come back expecting the thing to be right. My judgment is needed much earlier than that. Not because I am smarter than the agent. Not because the agent is useless. Quite the opposite. The agent is moving very fast, and because it is moving very fast, my judgment has to be in the loop more often, not less. When I am building a product, I am often discovering the UX as I go. I may have a pretty strong idea in my head. I may even be convinced the flow is obvious. Then I see it. I click it. And the whole thing feels off. The button is wrong. The page is wrong. The form asks too much too early. The workflow I thought was simple is only simple because I have been living inside it for three days. That moment matters. And I do not want that moment delayed by six hours of autonomous work. This is especially true if you are doing CPTO-type work. Product, UX, and engineering are not separate lanes yet. They are tangled together. You are not just implementing a known design. You are finding the product through the implementation. In the old world, you might have ended that exploration with a Figma file. In this new world, you can end it with a working, shippable product. That is an enormous advantage. But it does not mean the exploration disappeared. It just moved closer to the code. That is the part I think people miss. AI did not eliminate the need for deep thinking about the product. It compressed the distance between idea, design, and implementation. Which means you can make more decisions faster than ever before. That can be exhausting. Sometimes it feels like the guy in *Limitless*. Everything is brighter. The world is moving slower. You can see all the connections. You are building at a pace that used to be impossible. But you are also aging twice as fast. Because even though the typing is easier, the judgment is not. The judgment may actually be harder now. You are reviewing more possibilities, making more product calls, rejecting more ideas, shaping more flows, and correcting more nearly-right implementations than you ever could before. The work did not become effortless. The shape of the work changed. For some software, the hard part used to be raw production. Can we write enough code? Can we get enough tickets done? Can we generate enough test coverage? Can we ship the backlog? Agent loops are very good at attacking that problem. But for new products, early features, and UX-heavy work, the hard part is often not production. The hard part is knowing what should exist. And honestly, I hate when people call that a bottleneck. "Bottleneck" is a manager's word. It implies the ideal state is some frictionless conveyor belt where an idea enters one side, implementation comes out the other, and nothing slows down the glorious march toward done. But real makers know the friction is not the problem. The friction is the job. Figuring out the right thing is not some annoying blockage in the system. It is the work. Exploring the space is the work. Spelunking into the dark weird depths of the problem and coming back with something elegant is the work. That is what you need makers for. Not just people who can move tickets across a board. Not just people who can turn a spec into code. You need people who can live inside the ambiguity long enough to find the shape of the thing. This is the part that does not show up cleanly on a Gantt chart. It does not look efficient from a distance. It can look like circling, wandering, revisiting, deleting, renaming, rebuilding, and changing your mind. But that is not waste. That is what separates good work from great work. That is the difference between producing software and making a product. This is where I think a lot of people get into trouble. They try to use the software factory before they know what the factory is supposed to make. Factories are incredible when they are producing known parts. They are much less useful when you are still standing in the woods trying to decide whether you are building a chair, a cabin, or a boat. That does not mean the agents are not useful in the early phase. They absolutely are. I use them constantly. But I use them more like a collaborator than a factory. I want the agent to challenge the plan. I want it to generate options. I want it to help me see the edge cases. I want it to code fast, revise fast, and explain tradeoffs. I want it to help me move from idea to working product without the old ceremony. But I do not want it disappearing into a tunnel for half a day while I go off and do something else. Not only am I out of the loop at that point, I am out of the product. I have exited the flow state. And when the thing comes back, I am no longer shaping it from the inside. I am reacting to it from the outside. For that kind of work, the loop has to be tighter. Build a slice. Look at it. Feel it. Change your mind. Rewrite the flow. Move the button. Delete half the fields. Rename the concept. Realize the whole page should not exist. Ask the agent to refactor. Run it again. That is still a loop. It is just a human-centered loop. The human is not a final approver standing at the end of the assembly line. The human is part of the creative process itself. The judgment is not a checkpoint. The judgment is the work. Once the product matures, the balance changes. When the patterns settle, the design system hardens, the architecture has proven itself, and the core workflows are known, the software factory becomes much more powerful. At that point, you can hand off bigger chunks. You can trust the agents to follow existing conventions. You can create skills that encode your preferences. You can build review layers that catch mistakes. You can let the system produce more while you supervise less. That is a great place to get to. But it is not always where you start. The mistake is treating every software project like it has already reached that stage. Some projects need a factory. Some projects need a studio. And some projects need the founder, designer, product thinker, and engineer sitting in the same chair, arguing with the machine every twenty minutes until the thing finally feels right. That is the distinction. Agent loops and software factories are real. They work. They are going to change how mature software gets built. For stable systems with clear specs, established patterns, and known outcomes, they may become the default way a lot of work gets done. But when you are still crafting the product, discovering the UX, and deciding what the thing is supposed to be, you cannot fully remove yourself from the loop. You are the loop. --- # The Rise of Mediocrity and the Death of the Real Turd AI did not make everything worse. It made bad harder to see. Published: June 10, 2026 Tags: AI, Opinion, Creative Work Canonical URL: https://michaelrispoli.com/blog/the-rise-of-mediocrity-and-the-death-of-the-real-turd/ There is a common criticism right now that AI is causing the enshittification of everything. The argument is that by giving everyone access to these tools, we are flooding the world with bad writing, bad design, bad art, bad code, bad everything. And I understand the criticism. There is a lot of AI slop out there. There is a lot of work that has the unmistakable smell of the machine on it. But I think there is another possibility worth considering. What if AI is not making everything worse? What if AI is making it harder to remember what truly bad work looks like? For a long time, mediocrity was easy to spot because there was a visible gap between professional-level work and everything else. You could usually tell when something had been made by a person who really knew the tools. The design had better spacing. The code had better structure. The copy had more polish. The presentation simply felt more finished. That did not always mean the professional had better ideas or better taste. Sometimes they did, of course, but often the difference was much simpler: they knew how to get the thing out of their head and onto the screen. That was the great bottleneck before AI. A lot of people had interesting ideas, and a lot of people had good taste, but there was a real distance between what they could imagine and what they could actually produce. If you wanted to become a great designer, you had to learn Illustrator, Photoshop, Figma, typography, layout, color, export settings, and all the strange little quirks of the tools. If you wanted to become a great programmer, you had to learn languages, architecture, databases, frameworks, deployment, debugging, and all the hidden details that separate something that technically works from something that works well. The tools were not just tools. They were gates. I do not think those tools are irrelevant now. In many ways, they matter more than ever at the highest level. But for a lot of people, the act of learning the tool well enough to express the idea was the thing that stopped them. It took years. Sometimes it took decades. Sometimes they simply never got there. I have felt this myself most clearly with graphic design. I can see something in my head. I can know the feeling I want. I can recognize when something is wrong. But then I open Illustrator and the idea gets trapped somewhere between my taste and the interface. I do not know where the little feature is nested. I do not know the right workflow. I do not know why the thing is snapping strangely or why the export looks wrong or why what I made is close, but not quite alive. That used to be the wall. Now the wall is lower. With AI, I can ask where the tool is. I can ask how to use it. I do not have to sift through a seventeen-minute YouTube video to find the thirty seconds I needed. And in many cases, I can skip parts of the tool entirely. I can describe what I want in plain English and have the machine attempt to make it. That is not a small change. Plain English has become a creative interface. Of course, describing what you want is its own skill. Knowing what to ask for is not easy. Knowing the correct terminology for what you want still requires learning. Describing what is wrong with the output is not easy. Having enough taste to reject the first decent answer is not easy. But the old technical barrier between taste and execution has started to collapse, and that is changing the nature of mediocrity itself. The strange thing happening now is that almost everyone can produce work that looks sort of professional. The floor has been raised. What used to look impressive a few years ago now looks ordinary. What used to be good enough to get someone paid now feels like something a reasonably capable person could generate in an afternoon. The work is clean. The lighting is nice. The typography is decent. The code runs. The copy is polished. The deck looks like a deck. The product mockup looks like a product mockup. And yet somehow, it all feels mediocre. That is the important distinction. AI has not filled the world only with garbage. Garbage is obvious. Garbage announces itself. What AI has done is more subtle. It has filled the world with things that are pretty good. Pretty good writing. Pretty good design. Pretty good code. Pretty good strategy. Pretty good branding. Pretty good images. Pretty good interfaces. Pretty good everything. Pretty good is becoming invisible. Think about the old local furniture store commercial that somehow became a meme. The yellow hue to the lighting. The lo-fi audio. The owner is yelling at you from a warehouse with their arms outstretched. The transitions are insane. The jingle sounds like it was recorded in a basement by someone’s cousin. It is so bad that it becomes funny because we couldn't imagine someone paying for something that bad, much less proudly broadcasting it on television. Or think about the flyer that comes home from your kid’s school. Not the clean Canva flyer. I mean the old kind. The Microsoft Word flyer. Three different fonts. Arial, Comic Sans, and then some strange display font with wavy letters. Clip art in the corner. A sparkly dot-matrix border. A random assortment of various colors. Text centered for no reason. A random stretched image where all the children's faces look like they were pressed in a flat iron. That stuff was everywhere. The wedding video with the square fade in and out. The church bulletin with twelve fonts. The public access commercial. The restaurant menu with every item given the same visual importance. The small business website with a background texture, a drop shadow, a spinning logo, and a contact form that may or may not work. Or what about the old 90s drug-free commercials. That was not the edge case. That was a huge amount of everyday design. And a whole class of professional design existed, in part, to make things not look like that. A lot of baseline professional work was simply the ability to play the greatest hits. Use fewer fonts. Give things space. Align the elements. Pick colors that do not fight each other. Make the headline readable. Do not stretch the image. Do not use every transition. Do not make the logo spin. Do not center everything. Do not turn the flyer into a ransom note. That was valuable work. It still is. But AI has learned to default to pretty good. It has learned the design equivalent of pop music. It knows how to give you a pretty good rhythm, a pretty good hook, a pretty good chorus, a pretty good bridge. It knows how to make something clean, balanced, and familiar. It knows how to play the greatest hits of acceptable taste. In fact, you'd have to put in work to get it to produce something as horrendous as that clip-art school flyer. So maybe the problem is not that everything is turning into shit. Maybe the problem is that we do not see real turds in the wild anymore. The bottom has been lifted. The truly chaotic, spectacularly bad work is disappearing from many parts of life because the person who would have made the Microsoft Word flyer can now ask Claude or ChatGPT or Canva or any number of tools to make something that looks pretty good. The person who would have made the unwatchable commercial can now use templates, AI voiceover, automated editing, image generation, and script assistance to produce something that at least clears the floor. That is a strange kind of progress. It means the world may actually get less ugly in certain obvious ways. Fewer ransom-note flyers. Fewer broken layouts. Fewer unreadable menus. Fewer small businesses with websites that look like they were designed inside a printer settings dialog. But it also means we lose a certain clarity. When bad was bad, good was easier to identify. You could point to the bad thing and say, “Not that.” You could point to the professional thing and say, “That.” Now the bad thing often looks decent. The amateur work looks professional enough. The average has been dressed up. Mediocrity has learned spacing. This is why the conversation around AI and taste is more complicated than simply saying AI makes everything worse. In many cases, AI makes the worst work better. It raises the floor. But by raising the floor, it also raises the standard. The old version of “good” starts to feel like the new version of “fine.” And fine is where things go to disappear. We are already developing a sensitivity to this. We say, “That looks like AI,” or “That sounds like AI,” or “That feels like AI.” But the strange part is that a lot of this work would have looked professional not very long ago. It would have been considered decent work, maybe even strong work. It would have passed. It would have impressed a client. It would have helped someone get hired. Now it has the smell of the average. That is what AI produces by default: the average. A large language model is not dreaming in the way a person dreams. It is not remembering the first movie that changed you, the song your father played in the car, the strange shape of a restaurant sign from your childhood, or the way a certain book rearranged your sense of the world. It is moving from token to token by probability. It is excellent at producing the next likely thing. That is useful, but the next likely thing is rarely the unforgettable thing. This is where taste becomes even more important, not less. There is a story a professor once told me about Hampshire College. As I remember it, the point was that they did not organize education around traditional grades in the same way most schools do. The work was more project-based, more qualitative, more centered around the thing itself. His belief was that when you eliminate grades, you can actually raise the standard because now there is not an A, B, C, D, and F. There is great work, and then there is everything else. That idea always stuck with me because grades create a strange comfort. You get a B and move on. You tell yourself it was good enough. In school, maybe it was. But the world does not really work that way. The world does not care that you got a B. The world cares whether anyone stops, whether anyone notices, whether anyone feels something, whether anyone remembers. We are entering a similar moment with creative work. When everyone can produce something that looks pretty good, pretty good stops mattering. The new division is not between amateur and professional. The new division is between average and alive. That is a much harder division because professional polish is no longer enough. Looking clean is no longer enough. Sounding articulate is no longer enough. Having a nice logo, a nice deck, a nice landing page, a nice app, a nice image, or a nice paragraph is no longer enough. The question is not simply, “Does this look professional?” The question is, “Does this feel like it came from somewhere?” Does it carry a point of view? Does it make a connection I would not have made on my own? Does it draw from a life, not just a dataset? Does it have taste? This is why I think the people who stand out in the AI era will not simply be the people who use AI the most, nor the people with generally accepted good taste. Because AI does generally accepted taste by default. What it can't do is bring together your unique perspective on the world and produce something novel. The most successful people will need to develop a unique taste. They will be the people who read strange books, watch old films, listen to music outside the algorithm, study architecture, notice menus, remember packaging, care about chairs, pay attention to language, and collect references from the real world. Their advantage will not just be that they know how to prompt. Their advantage will be that they have something worth prompting from. Novelty does not come from asking the machine to be novel. Novelty comes from forcing unlikely worlds to collide. It comes from bringing together ideas that would not naturally sit next to each other: a product inspired by an old camera and a Japanese lunchbox, a landing page with the pacing of a sermon and the design of a punk record, a software interface that feels less like SaaS and more like a well-made tool from a hardware store. That is where the human being matters. The machine can help produce. It can help execute. It can help explore variations. It can help you get past the blank page, the empty canvas, or the intimidating tool. But it cannot care for you. It cannot decide what is worth preserving. It cannot know which references belong together unless you bring them to the table. This is the opportunity hiding underneath all the anxiety. AI lowers the execution barrier, but it raises the taste barrier. It makes mediocre work easier to produce, but it also makes truly excellent work more obvious. When everything looks acceptable, the exceptional becomes louder. When everything is polished, soul becomes the differentiator. When everyone can make something that looks professional, the only thing left is to make something that feels alive. Producing something different yet delightful is still as difficult as it has ever been. Maybe more difficult. Because now you are not competing against people who cannot use the tools. You are competing against a world where everyone has access to competence. That means competence is no longer the moat. Taste is. Point of view is. Life is. The barrier is no longer learning where the tool is hidden in the software. The barrier is knowing what is worth making in the first place. And for the people who can answer that question, AI is not the end of creativity. It is the removal of an old excuse. Now the idea can get out. Which means the idea has to be better. --- # The magic in the meeting AI can make execution cheap, but the real product judgment still happens when the right people stay with the problem together. Published: June 9, 2026 Tags: AI, Product, Leadership Canonical URL: https://michaelrispoli.com/blog/the-magic-in-the-meeting/ I once had a mentor who used to say, “The magic is in the meeting.” I was working at an advertising agency at the time, and he had been around long enough to have lived through a very different version of the industry. Maybe not exactly the golden age of advertising, but certainly an age when the creative process still had a kind of mythology around it. The creatives sat around together. They argued over ideas. They sketched campaigns. They pushed each other. They found the thing hiding underneath the obvious thing. He was not anti-technology, he was passionate about it. He understood that digital tools were changing the work, and in many ways making the work better. But he believed very deeply that the computer was not where the idea happened. The meeting was where the idea happened. The computer was where you made the thing, refined the thing, distributed the thing, and measured the thing. But the strange human process of figuring out what the thing should be still happened when the right people got in a room and did that thing called brainstorming. I have been thinking about that line a lot more in the age of AI, because I think it is more true now than it was when he first said it to me. We have more powerful execution tools than ever. We can generate copy, code, designs, workflows, research summaries, prototypes, and product ideas at a speed that would have seemed absurd even a few years ago. But the danger of cheap execution is that it can trick us into skipping the part where we decide whether the thing is actually worth executing. That is the trap. AI will happily help you build the wrong thing. It may even make the wrong thing look polished enough that everyone feels like progress has been made. But a well-executed bad idea is still a bad idea. In fact, it might be more dangerous now because the cost of building it has dropped so much that teams feel less pressure to stop and ask whether they are solving the right problem in the first place. But do you know what's worse than bad ideas. Almost good ideas. The ideas that seem good enough to ship. The ideas that are nearly there but nobody is there to say we're close, but we're not there yet. This came up for me recently in a sprint planning meeting. A client had asked us to build something. They wrote a ticket and on the surface, it was clear enough. There was a requested behavior, a proposed flow, and a desired outcome. But as I read it, something felt off. It was not that the request was impossible. It was not even technically difficult. With today’s tools, we could have built it pretty quickly. That was actually part of the problem. I said something like, “I can give this to my coding tools and build whatever you want. It will do what you are asking. But something about this does not feel right. The product experience feels off. The user experience feels, unexpected. I think we need to push on this before we build it.” And then the truth came out. The client had already met about it. A group of them had debated it for a while. They were not thrilled with the solution either. It was simply the best they had been able to come up with from their vantage point, given the constraints, the time frame, and the context they had. They ended the meeting on time, but without feeling good about where they were at. That detail matters, because this was not a case of a client being careless. They had done the work. They had sat with the problem. They had debated the options. They had come to the best conclusion they could reach with the people who were in the room with the time they gave themselves to think about it. But the person missing from that room was the product and UX person. That was the gap. Not intelligence. Not effort. Not concern for the user. The gap was vantage point. They understood the business situation and the operational need, but they could not quite conceive of the right product flow from where they were standing. They could describe the pain. They could describe the edge case. They could describe what they thought the platform needed to do. But they needed someone in the room who could translate that pain into a cleaner product experience. That is where the meeting became valuable. We did not say, “Okay, this is good enough, let’s just build it.” We decided to stay inside the idea until it felt right. If that meant extending the meeting, we would extend the meeting. If that meant calling another meeting, we would call another meeting. The important thing was that we were not going to take an awkward solution, wrap it in a ticket, and throw it over the fence just because the execution was easy. This is one of the biggest traps in the AI world. There is not always enough pain in the build process anymore to force the hard conversation. In the past, if something was going to take three weeks, cost real money, and require a whole team to implement, people had more incentive to stop and ask, “Are we sure this is right?” Now the answer can be, “Well, let’s just have the AI build it and see.” That sounds harmless, but it can quietly train teams to accept half-baked thinking because the cost of implementation feels low. But the cost is still there. It just moved. The cost shows up in the product. It shows up in the user experience. It shows up in the maintenance burden. It shows up when the next edge case arrives and the team has to stack another awkward flow on top of the first one. It shows up when the product starts to feel less like something designed and more like something accumulated. So we stayed with it. We started with the situation, not the proposed solution. What was actually happening? Who was being invited? Why did this case exist? How often would it happen? What would break if we did nothing? Was this even a problem we needed to solve inside the product, or was it a rare enough case that the cleanest answer was to leave it alone? That is always the first place I want to start: is this really a problem? But the meeting is not only valuable because it helps you identify the real problem. That is part of it, but it is not the whole thing. The real magic is that, once the right people are in the room, the group can start creating answers that no single person could have created from their own vantage point. That is what happened here. The client understood the business situation. They knew why the edge case mattered. They understood the operational pressure that had created the request in the first place. I understood the product patterns, the platform, and the UX tradeoffs. Someone else understood how the users were likely to encounter the flow in the real world. Each person had a piece of the truth, but no one had the whole thing. That is why good meetings are not just status updates. They are creative instruments. One person says, “Here is the problem.” Another person says, “That solution feels too heavy.” Someone else says, “But we still need to account for this edge case.” Then someone throws out a rough idea, someone else sharpens it, someone else breaks it, and someone else finds the simpler version hiding underneath it. The solution emerges through the bounce. It is not brainstorm theater. It is not everyone putting sticky notes on a wall so we can pretend collaboration happened. It is the real collision of perspectives. This is where creative solutions come from. Not always from one genius having one perfect thought, but from many capable people bringing their partial views into the same room and letting those views interact. Sometimes the result is simply a cleaner solution to the problem in front of you. Other times, if the group is good and the room has enough trust, you find something genuinely novel. You find a flow, a campaign, a product move, or a strategic angle that nobody could quite see until everyone started working it together. Once we talked through the invite flow from that angle, the right answer became almost obvious. It was not obvious before because the conversation had been happening from the wrong altitude. They were trying to invent the interface from the business problem. My job was to help them stay with the business problem long enough to discover the interface that actually belonged to it. That is the kind of thing that does not happen when everyone is working in silos. It does not happen when a product discussion gets flattened into a ticket. It does not happen when the team treats the AI tool as the missing collaborator. AI can help produce versions, mockups, flows, and code, but it cannot replace the moment where the right people get in the room, bounce their perspectives off one another, and collectively discover an answer none of them had when the meeting started. That is the magic in the meeting. ## Remote Work Has Made This Harder One of the hidden costs of remote work is that we do not gather the way we used to. I am not saying every company needs to be in person all the time. Remote work has real benefits. Deep work matters. Flexibility matters. Not every conversation deserves a meeting. But some problems absolutely do. Some problems need a room. Sometimes that room is physical. Sometimes it is a video call that everyone agrees to let run long. But the principle is the same: we need focused, shared attention. The trouble with remote work is not simply that people are in different places. The trouble is that everyone is fragmented. Someone has another call at the top of the hour. Someone is half-listening while answering Slack. Someone is waiting for the document. Someone else is interpreting the ticket differently. Someone is asking AI to generate options without ever forcing the real conversation to happen. And slowly, the work becomes siloed. People stop solving problems together and start throwing artifacts over the fence. A ticket becomes a substitute for a conversation. A mockup becomes a substitute for strategy. A generated implementation becomes a substitute for judgment. That is how teams lose the magic. ## The War Room Is Coming Back This is why I have been thinking more seriously about the idea of the war room. Not as some performative business cliché. I mean an actual focused working session where the right people gather, clear the distractions, and stay with the problem until something breaks open. For my own company, this has become an important concept. Sometimes we need to be in person. Sometimes we need to immerse ourselves in a product for a day, or several days. Sometimes we need to say, “This is what we are solving this week. We are not scattering our attention across ten calls, twenty Slack threads, and a graveyard of half-written tickets. We are going to sit with this until we understand it.” That kind of focus is increasingly rare. Which makes it increasingly valuable. The war room is not about rejecting modern tools. It is the opposite. The tools make the war room more powerful. In the past, a meeting might end with a whiteboard, a few sketches, and a list of next steps. Today, with AI and modern prototyping tools, a meeting can end with real artifacts. Mock ups. Flows. Copy. Code. Data models. Working prototypes. Multiple directions explored in real time. That is incredible. But the tool is not the magic. The meeting is still the magic. The tool just lets the magic become tangible faster. ## AI Is the New Execution Machine For years, a lot of companies treated outsourced teams as execution machines. The thinking was simple: we will decide what needs to be built, write it down, send it across time zones, and get back the implementation. Sometimes that works for well-defined tasks. But it rarely works for ambiguous product problems. The reason is simple: outsourced execution teams are often structurally removed from the magic. They are not in the room. They do not have the full context. They are not part of the debate. They are handed decisions after the most important thinking has supposedly already happened. Now AI gives everyone an execution machine. A much faster one. Which means the question becomes even sharper: if execution is no longer the bottleneck, what is? The answer is people. Not in a negative sense. People are not the problem because they are slow or inefficient. People are the bottleneck because judgment, taste, context, prioritization, and product intuition still live with people. So the way to remove the bottleneck is not to remove the people. It is to focus them. We have to stop thinking in terms of bottlenecks and remember that the people are the point! We build for the benefit of people. Get them in the room. Give them the context. Let them challenge the premise. Let them use the tools in real time. Let them make decisions while the problem is still alive, instead of waiting three weeks for someone to interpret a stale ticket. ## The Future Belongs to Better Meetings I know meetings have a bad reputation. Most of that reputation is earned. Bad meetings are expensive. Status meetings are often wasteful. Recurring meetings with no decisions, no tension, and no real purpose can drain the life out of a team. But that is not an argument against meetings. It is an argument against bad meetings. A great meeting is not a calendar event. It is a compression chamber for understanding and creativity. It brings the right people into contact with the real problem. It creates enough friction for weak ideas to fall apart. It creates enough trust for people to say, “This does not feel right.” It creates enough focus for the obvious solution to finally become obvious. And sometimes, when the group is really working, it creates the conditions for a solution nobody walked in with. In the age of AI, this matters more, not less. Because we are going to be able to make more things faster than ever before. The winners will not be the teams that can generate the most output. The winners will be the teams that can decide what is worth making, and then bring the right minds together long enough to make it better than any one person could have made it alone. Those decisions will not come from isolated prompts, scattered tickets, or one person quietly asking a machine to validate their first idea. They will come from people gathering around a problem with enough focus, humility, and taste to get to the truth. The magic is still in the meeting. Only now, when the meeting is good enough, you can leave the room with the idea, the plan, and the first version already in your hands. --- # Cast the Ring Into the Fire: Why Founders Must Resist the Temptation to Add One More Feature Early products need one powerful story. Every extra persona, workflow, and feature can weaken the focus that makes the first users care. Published: June 8, 2026 Tags: Product Strategy, Founders, Fractional CTO Canonical URL: https://michaelrispoli.com/blog/cast-the-ring-into-the-fire/ I have seen the same thing happen to founders enough times now that I have decided I need to start saying something earlier. It usually starts with a good product. Not a vague idea. Not another generic app. A real product. A product with a sharp niche, a founder with vision, real research behind it, and actual conversations with actual users. Those are the products I like to work on. David Ogilvy wrote in *Confessions of an Advertising Man* about the importance of believing in the product you represent. I have always felt the same way about software. I do not want to build things I do not believe in. I do not want to help create second-best products. If I am coming in as a fractional CTO or CPO, I want to believe the thing we are building has a real shot at being best in class for the people it is meant to serve. And these days, that focus matters more than ever. Artificial intelligence has made it easier than ever to build general software. Generic apps are cheap now. If your product does not require domain expertise, a sharp point of view, or a difficult problem worth solving, it is going to be very hard to defend. So the best early-stage products usually begin with a beachhead: a specific user, a specific pain, a specific story, and a specific reason to exist. And then, somewhere during the build, something happens. The product starts to feel real. The founder starts to ruminate. They begin seeing all the other ways the product could be used. It could serve this group. It could serve that group. A VC says, "I would be more interested if it also did this." A potential customer says, "This is great, but we would need it to also support that." A friend makes an offhand comment. A new module appears in someone's imagination. Another persona gets added to the landing page. Another workflow enters the backlog. And suddenly the product is no longer telling one powerful story. It is trying to tell three. That is where the trouble starts. ## You Cannot Tell Every Story at Once The first version of a product has to tell an incredibly powerful story to the first group of users it is trying to capture. That story shows up everywhere: on the landing page, in the onboarding, in the product architecture, in the navigation, and in what you choose not to build. Every time you introduce another audience into that story, you dilute it. Now the landing page has to ask, "Are you this person or that person?" Then maybe, "Are you this person, that person, or this third person?" And while that might seem like a small UX problem, it is actually a positioning problem. There is rarely an elegant way to do it. The copy gets softer. The onboarding gets heavier. The product gets broader. The emotional connection gets weaker. Instead of making one group of people feel like, "This was built exactly for me," you make three groups of people feel like, "I think this might be for someone like me." That difference is fatal at the earliest stage. Great products, like great stories, need coherence. Think about *Game of Thrones*. Part of what made it so captivating was the sheer number of stories happening at once. There were love stories, revenge stories, quests for power, family tragedies, political betrayals, and hero's journeys all unfolding together. For a long time, that complexity was thrilling. But complexity creates debt. The more threads a story carries, the harder it becomes to resolve them in a way that feels satisfying. Eventually, all those arcs have to come together. If they do not, the audience feels it. Products work the same way. Now contrast that with *The Lord of the Rings*. It is also a massive world with many characters, kingdoms, histories, battles, and side quests. But the core story is simple: Frodo must carry the ring to Mordor and destroy it. That clarity gives the whole story its shape. Early products need that same center of gravity. They need to feel like the obvious answer for a specific person with a specific problem. The more user types you introduce, the more workflows you add, and the more promises you make, the harder it becomes to make the whole thing feel inevitable. And early products need to feel inevitable. ## The Ring of a Thousand Features This is where the metaphor becomes useful. For founders, the temptation to add "just one more thing" is the ring. It is precious. It whispers. It says, "This will make the product bigger." It says, "This will unlock another market." It says, "This will help us raise money." It says, "This will make that one buyer say yes." It says, "This is easy to add." And the most dangerous part is that the ring is not always wrong. The feature might be useful one day. The other market might be real one day. The workflow might matter one day. The VC might even have a point. But "one day" is not the same as "right now." At the zero-to-one stage, the question is not, "Could this be useful?" Almost anything could be useful. The question is, "Does this make the core story stronger for the first group of users we need to win?" If the answer is no, cast it into the fire. Do not put it in the backlog. Do not hide it in the nav. Do not add it as a secondary onboarding path. Do not build it because someone important said they might care. Write it in a notebook if you must. Put it in a parking lot document. Let it sit. Let time test it. But do not let it corrupt the product. ## Beware the Counterfeit Yes One of the most dangerous things a founder can receive is a counterfeit yes. A counterfeit yes sounds like this: "We would invest if it also did this." "We would buy it if it had this feature." "This would be interesting for our team if you supported this other use case." Founders hear those sentences and understandably want to act. They are trying to survive. They are trying to raise. They are trying to sell. They are trying to make the product more attractive and building has never been cheaper. So they build the thing. And then what happens? The VC does not invest. The buyer does not buy. The customer has another objection. The person who suggested the feature disappears. Now the founder is left holding the bag. The product is more complex. The story less powerful. And worst of all, the app is less delightful. This is how good products die. Not always from one catastrophic decision. Often from a series of small, reasonable-sounding additions that slowly dilute the original promise. ## Easy to Build Does Not Mean Worth Building This temptation has never been stronger than it is right now. AI has made software faster to produce. Modern frameworks, component libraries, boilerplates, and LLM-assisted coding make it feel like adding another module is not a big deal. And technically, maybe it is not. Maybe it is easy to add. But that is not the right standard. A product is not finished when there is nothing more to add. It is finished when there is nothing more to take away. That idea, often attributed to Antoine de Saint-Exupery, is one of the most important principles in early product development. The cost of a feature is not just the time it takes to build it. The cost is the explanation, the onboarding, the support, the navigation, the edge cases, the mental model, and the dilution of the story. Every feature asks the user to understand one more thing. Every persona asks the product to serve one more master. Every additional market weakens the force of the original wedge unless it is introduced at the right time, in the right way, after the core has already been proven. ## We Will Just Put It in the Nav Is Not a Strategy Another version of this mistake is when the founder says, "We will build it, but we will not make a big deal out of it. We will just put it in the nav." That sounds harmless. It is not. If the feature is buried, then it is good as not built. It will not attract the new audience, because the product is not telling that audience a story. There is no dedicated positioning, no focused on-boarding, no emotional hook, no reason for that user to believe this product was made for them. So now you have built something that does not help you acquire the new audience. But it can still create complexity for the existing one. And what if people do find it? What if they use it? What if the secondary feature starts creating demands that conflict with the primary use case? Now your core users want one thing, your accidental users want another, and your product starts bending in multiple directions at once. That is not flexibility. That is fragmentation. With great flexibility comes great complexity. The more paths you allow into the product, the more responsibility you take on to make each path excellent. And at the early stage, you do not have the money, time, team, or market clarity to make five things excellent. So make one thing excellent. ## Build the Better Feature for the Core User Here is the question I wish more founders would ask: Would you rather build one excellent feature your core user will love, or five half-formed features for five audiences you have not yet earned? Because that is usually the real trade-off. It rarely feels that way in the moment. In the moment, it feels like expansion. It feels like opportunity. It feels like being strategic. But in reality, you are often choosing between depth and sprawl. And depth is what creates love. The goal of an early product is not to be broadly acceptable. The goal is to be intensely valuable to a specific group of people. You do not need everyone to like it. You need a small group of people to love it. You need the hundred true fans. The true believers. The people who feel the pain so clearly that when they see your product, they immediately understand why it exists. Once you have that, expansion becomes easier. You can add new markets later. You can introduce new workflows later. You can build the adjacent modules later. You can tell the second story after the first story is working. But if you never get the first group to love the product, the second group will not save you. ## The Focused Competitor Is Coming There is another danger here founders do not think about enough. While you are broadening your product, someone else can come along and build the focused version. They do not need to beat you to market anymore. Software is moving too quickly for that phrase to mean what it used to mean. They can beat you in market. They can show up at the same time with a sharper product, a clearer landing page, a simpler on-boarding flow, and a stronger emotional promise. While your app says, "We help these five types of users do these twelve things," theirs says, "We help this exact person solve this exact painful problem." That is the product people remember. That is the product people share. That is the product that feels like it was built by someone who understands them. The bar for building apps has gone down. The bar for building beloved apps has gone up. Focus is how you compete. ## My Duty as a Fractional CTO/CPO As a fractional CTO/CPO, part of my job is to help founders build. But another part of my job is to help founders not build. That is sometimes the harder responsibility. Because the founder is paying me. If they insist, of course I can put the feature in the app. I can add the module. I can add the on-boarding branch. I can add the extra persona to the landing page. But I also have a duty to say the thing plainly: I have almost never seen this strategy work at the earliest stage. I have seen it kill products. I have seen good ideas get overtaken by secondary ideas. I have seen original theses diluted beyond recognition. I have seen teams run out of money not because they could not build, but because they built too much of the wrong thing too early. So the next time the ring appears, I am going to say something. That feature may be real one day. That market may matter one day. That module may deserve its own roadmap one day. But right now, we have a ring to destroy. Stay with the original thesis. Serve the first user deeply. Tell one powerful story. Make the product more lovable, not more expansive. Build until there is nothing left to take away. And when the temptation comes to add one more feature because it feels easy, strategic, or impressive, do the thing that great product work often requires: Cast it into the fire. --- # A Runtime for Non-Deterministic UI JSON Lisp started with a question: what if AI could stream the right interface for one user instead of forcing everyone through the winning side of an A/B test? Published: June 5, 2026 Tags: Case Study, AI, Interface Design Canonical URL: https://michaelrispoli.com/blog/json-lisp-ai-written-interfaces/ Most product teams still design for the average. Run an A/B test. Pick the version that wins with 51% of users. Ship it to everyone. The losers do not get a vote after that. They just live inside the winning average. That made sense when interfaces had to be mostly fixed. A product team could not design a different workflow, explanation, layout, or decision path for every person. The cost was too high. So we optimized the shared screen and accepted the tradeoff. AI changes that assumption. Imagine a product that does not ask, "Which interface won for most users?" Imagine it asks, "What does this user need right now, and how do they prefer to process information?" One person may need a checklist. Another may need a comparison table. Another may need a guided sequence. Another may need dense controls because they already understand the domain. That is not personalization as decoration. It is a different idea of interface design. Instead of being the short end of an A/B test, the user ends up in a different place because the software can produce the right UI for the moment. The application becomes less like a fixed set of screens and more like a runtime that can receive a task-specific program. That is where JSON Lisp comes from. The project is public here: [Cause-of-a-Kind/json-lisp](https://github.com/Cause-of-a-Kind/json-lisp). The original seed was work I did at The Knot Worldwide. We were exploring how to sync UI across web, iOS, and Android from a shared JSON data structure. Because the product had a shared UI kit, we could express new views as JSON and let each platform interpret that structure in its native environment: JavaScript on web, Swift on iOS, Kotlin on Android. That work was not about AI. It was about portability, consistency, and reducing duplicated product logic across platforms. But the idea stuck with me: if a UI can be expressed as structured data and interpreted by a known runtime, the screen does not have to begin life as hand-written application code. JSON Lisp takes that idea and points it at AI. If an LLM is going to create UI or small programs on the fly, maybe it should not generate normal frontend code at all. Maybe it should generate a compact program representation that the browser already knows how to execute. That is the backbone idea: a browser-native runtime where structured JSON can describe dynamic interfaces and program behavior in a token-efficient format. The LLM does not have to write a full React app. It can stream a smaller, constrained program into a running application that targets a known runtime. The Lisp part of the name is intentional. Clojure and other Lisp traditions treat code as data in a way that has always felt unusually well matched to this problem. If the program can be expressed directly as a data structure, you are not asking the model to produce a pile of syntax and hoping a compiler makes sense of it. You are asking it to write into the shape of the abstract syntax tree. That gives the runtime more leverage. The program is easier to inspect, transform, validate, constrain, transmit, and potentially generate in pieces. For AI-generated software, that flexibility matters. The output is not just text that happens to look like code. It is structured material the system can reason about before it becomes behavior. At the smallest level, the program is just JSON. A model can emit something like this instead of a component file: ```json { "v": "0.1", "state": { "mode": "checklist" }, "view": [ "html.section", { "class": "stack" }, [ ["html.h2", {}, ["Your next three steps"]], ["html.ol", {}, [ ["html.li", {}, ["Confirm the business goal"]], ["html.li", {}, ["Pick the safest next action"]], ["html.li", {}, ["Ask for help if the answer is unclear"]] ]] ] ] } ``` The host app gives that document to the runtime: ```js import { renderJsonLisp } from "@json-lisp/dom" const app = renderJsonLisp(program, { target: document.getElementById("app") }) ``` Then the UI can still behave like software, not just static content. State, events, and updates are part of the document: ```json { "v": "0.1", "state": { "count": 0 }, "view": [ "html.button", { "@click": ["!set", "count", ["+", ["$get", ["$state"], "count"], 1]] }, [ "Count: ", ["text", ["$get", ["$state"], "count"]] ] ] } ``` That is intentionally not a lot of syntax. The point is to give the model a small target: describe the document, read state, handle an event, update the model, render the result. That matters because tokens are not just a billing concern. They are a design constraint. The longer and looser the generated output, the more chances the model has to drift, contradict itself, invent missing pieces, or produce code that looks plausible but is not safe to run. A compact runtime changes the bargain. The model operates inside a smaller language. The browser receives structured data instead of arbitrary source code. The system can reason about what is allowed. Interfaces can become non-deterministic in a controlled way: generated for the moment, shaped by context, but still rendered through a known execution model. This is not only a technical experiment. It points at a different product pattern: non-deterministic UI. Most software assumes the interface is designed ahead of time. Non-deterministic UI assumes the application can generate an interface at runtime based on the user's goal, context, available data, and safe actions. The interface may not need to be fixed. It can be produced for the task at hand. That does not mean chaos. It means the runtime becomes the contract. The product question becomes: what small set of primitives can express enough useful interface and program behavior for an LLM to assemble something meaningful, without making the output huge, fragile, or unsafe? That is where JSON Lisp is interesting. It treats AI-written UI as a runtime-design problem instead of a prompt-writing trick. The goal is not to make the model produce prettier code. The goal is to give the model a better target. For founders building AI products, this distinction matters. If your product depends on generated software behavior, you should care about the shape of the thing being generated. Free-form code is powerful, but it is expensive to trust. A compact program format can make the system easier to stream, inspect, transmit, constrain, and evolve. The future of AI interfaces may not be one perfect app screen that wins the test and gets forced on everyone. It may be a runtime that lets the right screen exist for one person, just long enough to do the job. --- # Building AI-Assisted Workflows Inside a Regulated Environment Karvenience shows why sensitive data changes the AI conversation: credit applications, documents, integrations, and operational trust all need boundaries. Published: June 5, 2026 Tags: Case Study, AI, Regulated Software Canonical URL: https://michaelrispoli.com/blog/karvenience-regulated-ai-workflows/ AI feels different when the data is sensitive. It is one thing to summarize marketing copy or generate a draft email. It is another thing to work around credit applications, personal information, documents, inventory feeds, approvals, and operational decisions that affect real people. In that setting, the question is not whether AI can help. It is where AI is allowed to help. Karvenience sits in that more serious category. The product work involves a regulated environment, sensitive user data, credit-application workflows, document handling, file storage, inventory ingestion, PDF generation, email, monitoring, and integrations such as SFTP inventory drops. That is a lot of business reality for one app to absorb. The ambition was not just to make a nicer form for a dealership website. It was to let a buyer move through the car-buying process in one coherent flow: find a vehicle, understand the price, submit the right information, handle documents, coordinate financing steps, and move toward a dealer handoff without the usual maze of phone calls, redirects, and half-finished web forms. That sounds obvious until you touch the industry. Car buying is not a clean greenfield workflow waiting for a startup to "disrupt" it. It is a crowded system of dealers, lenders, credit bureaus, inventory feeds, document requirements, compliance obligations, and legacy APIs owned by a small number of powerful companies. Every modern interaction has older technology sitting behind it. If the product pretends that legacy does not exist, it fails as soon as it leaves the demo. The real job was to build on top of that world and around it at the same time. That matters because the customer problem is real. Local dealers are not only competing with the dealership across town. They are competing with Carvana, CarMax, and every buyer expectation those companies have reset. The modern buyer wants transparent pricing, fewer surprises, less haggling, and a way to avoid the classic car-buying marathon. A website that looks like old WordPress, points to a finance form, and ends with "call us" is not enough anymore. But the answer is not to erase the dealer. Dealers still own local relationships, inventory, service, trade-ins, and a lot of operational knowledge. The opportunity is to give them software good enough to compete with the newer online-first players. Most individual dealerships cannot do that alone. They know the car business, but building a secure, integrated, buyer-facing product is a different discipline. The tempting mistake would be to treat AI as a blanket feature. Add document parsing. Add summaries. Add automation. Move faster. That is not enough. When sensitive data enters the product, architecture becomes policy in code. What data is stored? What gets passed to an AI tool? What is avoided? What gets logged? Who can see the result? What requires human review? What happens when extraction is incomplete or wrong? Which parts of the workflow must remain deterministic? Those are product questions and engineering questions at the same time. The technical work has to respect the business environment. Rails is useful here not because it is trendy, but because it gives the product a stable, understandable application structure for models, background work, file handling, access control, views, and operational flows. The AI parts can then be constrained inside the workflow instead of sprayed across the product as magic. That distinction matters. In a regulated workflow, AI should usually be an assistant to a bounded task: parse this document, suggest extracted fields, help classify material, reduce manual entry. It should not silently become the source of truth. The user needs to know what happened, what the system inferred, and where review is still required. That is where AI made sense for Karvenience. Not as a chatbot pasted onto the side of the product, but as practical assistance inside the work: making document entry easier, helping extract structured information, reducing repetitive typing, and supporting the people responsible for moving a buyer through the process. The product still needed classic software judgment underneath it: permissions, auditability, data boundaries, deterministic workflows, secure storage, and integrations that could fail loudly enough for an operator to recover. The same discipline applies to integrations. SFTP drops, documents, generated PDFs, and email all sound ordinary until one of them fails. Production software needs to make failure visible. Operators need enough information to recover without turning every exception into a developer emergency. The founder lesson is that AI does not remove compliance, privacy, or operational responsibility. It makes those responsibilities more important because the system can move sensitive information faster. Good AI product work is not just capability. It is containment. Karvenience is also a reminder that some industries do not get modernized by uprooting everyone already inside them. They get modernized by giving the people inside better tools. The best technical decision is sometimes a boundary: this data stays here, this workflow requires review, this automation stops before it makes a promise the business cannot defend. The best product decision is sometimes just as grounded: meet the industry where it actually is, then build the bridge to where buyers already expect it to be. --- # Production CTO for the AI-Prototype Era Founders can get farther than ever with AI tools. The hard part is crossing the final mile into software customers can trust. Published: June 4, 2026 Tags: Fractional CTO, AI, Product Engineering Canonical URL: https://michaelrispoli.com/blog/fractional-cto-in-the-ai-era/ The old fractional CTO pitch was easy to understand. A few calls, some architecture advice, a second opinion on the roadmap, and maybe a senior person to make the engineering team sit up straighter. That version can still be useful, but it is not enough anymore. AI changed the front half of product work. A founder can generate screens, wire together APIs, build a demo, and get something in front of customers before a traditional team would have finished the kickoff deck. That is a good thing. It also creates a new failure mode. The demo looks real. The investor likes it. The customer nods. The founder starts thinking the product is 70% done. Then production shows up and everything gets more honest. Authentication is half-bolted on. The data model is a guess. The happy path works because the demo was trained to walk in a straight line. Nobody knows what should be rebuilt, hardened, deleted, or treated as a useful sketch. This is where the CTO job changes shape. The useful version is not a meeting machine. It is a leader who can sit with the founder before a decision gets expensive and ask better questions. What are we trying to learn? What should be built, bought, automated, or ignored? Where is the system lying? Which technical risk is real, and which one is a fancy way to avoid the market? AI makes bad product judgment faster. It can generate more tickets, more prototypes, more demos, and more software-shaped material than the team knows how to digest. Velocity without taste is just maintenance debt with better branding. Used well, though, AI is leverage. It shortens the distance between a question and a working artifact. It helps with exploration, testing, internal tools, research, customer workflow design, and implementation. It makes the CTO role more important because someone still has to decide what deserves to become durable. A good production CTO in this era works at three levels: executive, product, and engineering. At the executive level, the work is cost, risk, timing, team shape, vendor reality, and the path from prototype to production. At the product level, the work is finding the actual workflow, not the one in the sales deck. At the engineering level, the work is architecture, code review, technical due diligence, agent-assisted delivery, and sometimes writing the first real version by hand. That last part matters. The AI era rewards leaders who can still touch the work, not because every CTO should be the main developer, but because strategy gets sharper when it has to survive contact with the code. The winners will not be the companies with the most tools. They will be the companies with faster execution, better taste, and a lower tolerance for theater. That is the production CTO job now: help founders cross the final mile from plausible demo to software customers can trust. --- # What to Do When Your AI Prototype Gets Stuck The demo proved something. Now you need to figure out whether it is a product, a workflow, a throwaway prototype, or a technical trap. Published: June 2, 2026 Tags: AI Prototypes, Product Rescue, Founders Canonical URL: https://michaelrispoli.com/blog/what-to-do-when-your-ai-prototype-gets-stuck/ The first demo is intoxicating. You type an idea into an AI tool, wire up a few screens, connect an API, and suddenly there is something to show. Customers stop nodding at abstractions. Investors can click around. The founder can point and say, "That. That is what I mean." That matters, but the next step is where a lot of projects get stuck. The prototype looks real enough that everyone starts treating it like a product. Authentication gets bolted on. The data model bends until it cracks. The AI behavior is impressive in the demo and slippery in real use. The code is hard to change. Nobody knows which parts are throwaway and which parts are supposed to become the foundation. This is not embarrassing. It is the normal move from exploration to production. The first thing to do is stop adding features for a minute. A stuck prototype needs diagnosis before acceleration. What did it prove? What did it avoid? Which assumptions are still untested? Which shortcuts are harmless? Which shortcuts are about to make the next month expensive? Then separate product risk from engineering risk. Product risk asks whether the thing is worth building. Do customers care? Is the workflow real? Does this create value, or did you just build a nice demo? Engineering risk asks whether the thing can become durable software. Can it be maintained? Is the architecture coherent? Can the AI behavior be evaluated? Can the data model handle reality? Those are different questions. Mix them up and you get bad decisions. You rebuild before you understand the product, or you validate a product on top of a foundation that cannot survive. Once the risks are separated, make the repair-or-rebuild call. Sometimes the prototype should be hardened. Sometimes it should become a specification and get thrown away. Sometimes the answer is a hybrid: keep the workflow, keep the lessons, replace the foundation. The point is not to shame the prototype. The point is to respect what it taught you and stop pretending it answered questions it never tried to answer. AI makes it easier to start. Production judgment is what helps you finish. --- # Turning a Homegrown Lead Tool Into a SaaS Opportunity Gault Family Companies had an aging lead system, deep home-services expertise, and a chance to modernize internal software into a product for businesses like theirs. Published: June 1, 2026 Tags: Case Study, Internal Tools, Product Engineering Canonical URL: https://michaelrispoli.com/blog/gault-family-lead-management-system/ Gault Family Companies is a local oil, gas, and home-services delivery company with a very real software story. Like a lot of long-running businesses, they had built and collected a large amount of software over time. Some of it was homegrown. Some of it came from third-party tools. Some of it worked because a few people knew where the bodies were buried. The company had a small software team supporting a large operational footprint, and the stack was starting to show its age. One of those homegrown tools was lead management. Replacing it with a generic tool was on the table. So was integrating more deeply into systems like HubSpot and other internal platforms. But that would not have solved the deeper problem. Gault was not just trying to track leads. They were trying to modernize how software was built, deployed, integrated, and maintained inside the business. They were also sitting on a product idea. For years, they had talked about building a SaaS product for home-services companies like theirs. A product that could manage leads with the domain awareness generic CRMs rarely have. The lead-management rebuild became a good place to test that thesis. Gault knew the business. My role as fractional CPTO, alongside my team, was to help turn that expertise into product strategy, architecture, and working software. The first hard problem was the customer record. In a lot of software, a customer is a person or an account. In home services, that is not enough. The real center of gravity is often the home address. Even that is too simple, because an address may contain multiple dwellings in the case of apartment buildings or multifamily properties. Then the contact model gets complicated. Sometimes the contact is the owner. Sometimes it is a tenant. Sometimes it is a loved one or caregiver. Sometimes the person calling is not the person receiving service. If the software treats all of those as the same thing, the business pays for that abstraction later. Lead sources were just as important. Leads did not only come from sales people or web forms. They came from boots-on-the-ground service people who saw real opportunities in the field. Those leads had to be delegated differently depending on the team, the brand inside the company, and the kind of work involved. That is the kind of detail generic CRM thinking usually flattens. We worked through it in a forward-deployed way: in the office, with engineers, stakeholders, and sales people. The job was not to disappear into a requirements document and return with software. The job was to sit close enough to the business to see how the work actually moved. The product had to do two things at once. It had to serve Gault's immediate operational needs, and it had to avoid becoming so Gault-specific that it could never be deployed into another home-services company. That balance is hard. Too generic and the product loses the domain value. Too specific and the SaaS opportunity disappears. The technical choices followed that same principle. We chose Ruby on Rails for the core solution because Gault needed durability more than novelty. They had experimented with newer JavaScript frameworks, but the turnover rate of frontend tooling was moving faster than the company's internal software maintenance rhythm. Rails gave the team a stable, traditional mental model: the server owns the application, renders HTML, models the domain, and exposes clear endpoints. That did not mean the interface had to feel old. Hotwire and Turbo gave the product modern interactivity without forcing the team into a complex frontend stack that would be harder to maintain over time. The result could feel fast and current while still being built on a framework with a long shelf life. The modernization mattered beyond the screens. Gault was used to older integration patterns, like reading from a read-only Microsoft SQL database on an on-prem machine to generate reports. That kind of architecture can work for a long time, but it also hardens into a fragile way of thinking about data access. The new system moved toward modern integration primitives. Data would be exposed through proper REST API endpoints. Systems could sync through webhooks. The code would live under version control. The test suite would protect behavior. CI/CD would make deployment a normal part of the development process instead of a special event. That is a bigger shift than swapping one lead tool for another. It is the difference between a tool that only solves today's workflow and a product foundation that can support a new business line. For founders, this is the lesson: the best SaaS ideas often come from companies that have lived the workflow long enough to know where generic tools fail. But domain expertise is not enough by itself. You still need product discipline. You need to decide which details are essential, which are accidental, and which technical choices will still make sense when the first version has to be maintained by a real team. A good lead-management system is not a table of prospects. For a home-services business, it is a model of places, dwellings, people, field activity, brands, teams, delegation, and follow-through. Once the software understands that, it stops being an internal replacement project and starts looking like a product. --- # Rebuild or Repair Your MVP? A messy MVP does not automatically need a rewrite. The right call depends on what the current system is costing the business. Published: May 30, 2026 Tags: MVP, Technical Debt, Product Rescue Canonical URL: https://michaelrispoli.com/blog/rebuild-or-repair-your-mvp/ The rewrite conversation usually starts with a sigh. The code is messy. The team is tired. Every new feature feels like opening a wall in an old house. The founder has stopped trusting estimates. Someone finally says the thing everyone has been thinking: maybe we should rebuild this from scratch. Maybe they are right. Maybe they are just exhausted. A messy MVP does not automatically need a rewrite. Early software is supposed to have shortcuts, guesses, and weird corners. That is part of the deal. The question is not whether the product has debt. The question is what the debt is costing. Start with business pain. Is the system blocking sales? Making customers churn? Creating support work nobody can keep up with? Slowing a funding milestone? Turning every feature into a surprise? Creating a security, compliance, or reliability risk the company cannot absorb? If not, a rebuild may be vanity with a Jira board. If yes, find out whether the pain is local or structural. Local problems can be repaired: a bad integration, a confusing admin flow, a slow report, a brittle deployment, or a feature that should have been isolated and was not. You do not burn down the house because one room smells funny. Structural problems are different. If the data model fights the business, the architecture cannot support the workflow, the system has no real boundaries, or the product was built around a false assumption, repair becomes a slow rewrite with worse morale. The answer should not be a slogan. It should be a map: stabilize this, replace that, leave this ugly thing alone because it is ugly and harmless, decide this product question before touching the code, and find the smallest path to a system the company can trust. A good product rescue audit makes that call clearer. It does not insult the old work. It does not bless every shortcut. It shows what the current system is doing to the business. Rebuild when the foundation is blocking the company. Repair when the product has earned a more careful next step. --- # How to Rescue a Failed Agency Build A bad agency handoff can leave founders with code, invoices, and no confidence. The rescue starts by separating blame from diagnosis. Published: May 27, 2026 Tags: Agency Handoff, Product Rescue, Founders Canonical URL: https://michaelrispoli.com/blog/how-to-rescue-a-failed-agency-build/ A failed agency build has gravity. The founder paid real money. There are Figma files, tickets, invoices, a repository, maybe a staging URL that still works if nobody breathes on it. In screenshots, the thing looks close. In real life, nobody trusts it. The agency may be gone. The relationship may be sour. The code may only run on one laptop owned by someone who has moved on with his life. The product may have the shape of the idea and none of the load-bearing parts. The first move is not blame. It is inventory. What was actually delivered? Can the app run locally? Can it deploy? Are the core workflows present? Is the data model usable? Are integrations real or mocked? Is there test coverage? Does anyone understand the architecture well enough to change it without praying? You need facts before you need a villain. Then you recover the product truth. Agency failures are rarely only technical. Sometimes the scope was vague. Sometimes the founder discovered the product mid-build. Sometimes the agency optimized for visible screens because visible screens get approvals. Sometimes nobody owned the painful tradeoffs. Sometimes the agency was careless. Usually it is a mix. The rescue has to separate the artifact from the intent. What was this product supposed to help customers do? What is still true about that? What did the build teach you? Which features exist because they mattered, and which exist because they were easy to draw? Only then can you choose the path. Stabilize if the foundation is workable and needs discipline, missing pieces, and a better delivery process. Salvage if the value is in the designs, workflow lessons, data, integrations, or isolated pieces of code. Restart if the current build is more useful as evidence than infrastructure. Founders resist restart because it feels like admitting failure. I get it. But dragging a fragile build forward can cost more than telling the truth while the blast radius is still small. The goal is not to punish the past. The goal is to get control of the product again. Once the founder knows what exists, what is missing, and what the next honest milestone should be, the work becomes possible. --- # What a Product Rescue Audit Should Tell You A useful audit should not just list problems. It should tell a founder what to do next, what to avoid, and what risk the business is carrying. Published: May 24, 2026 Tags: Product Rescue, Fractional CTO, Due Diligence Canonical URL: https://michaelrispoli.com/blog/what-a-product-rescue-audit-should-tell-you/ Most audits are written like the reviewer got paid by the page. Here is the messy code. Here are the missing tests. Here are fifteen architecture complaints. Here is a diagram. Here is a risk matrix. Here is a document that proves the reviewer knows things. The founder still has the same problem on Monday morning: what now? A product rescue audit should answer that in plain language. What do we actually have? What works? What is fragile? What risk is product risk? What risk is engineering risk? What should be repaired, rebuilt, paused, or ignored? What is the next milestone that would create real confidence? The founder does not need a museum tour of every flaw. They need a decision tool. That means every technical observation has to earn its place. A weak deployment process matters if it slows onboarding or makes releases dangerous. A poor data model matters if it blocks the workflow the product needs to support. Missing tests matter most when change has become expensive or risky. A messy file is not automatically a business emergency. The best audits also say what not to fix. That part matters because anxious teams overcorrect. They turn every rough edge into a priority. They polish software that has not earned polish. They hide from the market inside cleanup work because cleanup feels controllable. A useful audit keeps urgency without manufacturing panic. It should leave the founder with a few honest paths: repair the product and keep moving, rebuild the foundation before scaling, cut scope and prove the workflow, pause engineering until the product bet is clearer, or replace the vendor, change the team shape, and put technical leadership in the seat. The output should be calm, specific, and immediately usable. Not a performance of expertise. Not a vague warning. A map from the messy version to the next honest version. --- # The Worst Kind of Failure Looks Like Success A team can hit the deadline, ship the feature, and still avoid the thing the business needed to learn. Published: May 22, 2026 Tags: Delivery, Product, Leadership Canonical URL: https://michaelrispoli.com/blog/the-worst-kind-of-failure-looks-like-success/ Some software failures come with smoke. The launch slips. The app breaks. Customers complain. The postmortem writes itself. The harder failure is clean. The team ships on time. The demo works. The board update sounds responsible. The roadmap moves one square to the right. Nobody panics. Nobody has the hard meeting. The business just learns nothing. That is the worst kind of failure because it looks like success. This happens when a company optimizes for completed work instead of learned truth. A feature moves from idea to ticket to pull request to release. Everyone can point at the output. Nobody comes back to the original bet. Did this reduce customer pain? Did behavior change? Did the business get simpler, more valuable, or more defensible? Did we learn anything that should change what we do next? Delivery matters. I have no patience for strategy that never becomes software. But delivery without a learning loop becomes ceremony. It gives everyone the emotional reward of motion while preserving the uncertainty that mattered in the first place. AI can sharpen this problem. It makes prototypes cheaper, research faster, and implementation less precious. Good. Use that. It can also bury a team in artifacts that feel like evidence. A generated prototype is not customer validation. A faster sprint is not a better product strategy. A polished internal tool is not proof that the workflow matters. Output can become camouflage. The fix is not to slow down. The fix is to attach meaningful work to decisions. What will this help us decide? What would make us stop? What would make us double down? What would force us to change the design, market, business model, or technical approach? Good product engineering is not a factory for completed tickets. It is a system for reducing uncertainty through shipped work. Speed is leverage when it teaches you something. When it does not, it just helps you get lost faster. --- # Do Hard Things Before You Automate Them AI and automation are most useful after you understand the work well enough to know what should disappear. Published: May 8, 2026 Tags: AI, Operations, Product Strategy Canonical URL: https://michaelrispoli.com/blog/do-hard-things-before-you-automate/ The spreadsheet is ugly, which is often why it is honest. Somebody has a column called "check this manually." Somebody highlights rows in yellow because the system cannot explain the difference between urgent and merely loud. Somebody keeps a second tab because the official report lies just enough to be dangerous. The first instinct is to automate it. Clean it up, build the workflow, add AI, and make the humans stop touching the messy thing. Sometimes that is right. Often it is how a team turns confusion into infrastructure. The hard part of a workflow is rarely the clicking. It is the judgment hiding inside the clicking. Why does support check that field before replying? Why does ops distrust the report? Why does the founder still keep a spreadsheet next to the product they paid to build? If you automate before you understand those decisions, you preserve the mess and make it harder to see. AI raises the stakes because automation now feels available everywhere. Summarize this. Classify that. Draft the response. Generate the report. Route the ticket. Those can be useful tools, but they can also become bad excuses. The better order is less glamorous. Do the work by hand. Watch someone else do it. Write down the exceptions. Notice where people pause. Find the moment where the rule stops working and taste begins. Then automate. That is where AI gets powerful. It can remove repetitive surface area while keeping the human judgment that creates value. It can make an expert faster without pretending expertise is just a better prompt. For founders, this is a discipline problem. Nobody wants to tell investors the next smart move is a better spreadsheet, a concierge flow, or a boring review queue. But manual work is often the shortest path to a real system. It teaches the product what the business actually does. It exposes the hidden requirements. It stops the team from spending months polishing an abstraction over a process they never understood. The goal is not to avoid automation. The goal is to deserve it. --- # When the Rewrite Is the Responsible Move BEST App Suite started as a mobile migration. Years of real user behavior taught us why a Rails PWA was the better product for people with traumatic brain injury. Published: May 1, 2026 Tags: Case Study, Accessibility, Healthcare Canonical URL: https://michaelrispoli.com/blog/best-app-traumatic-brain-injury-accessibility/ When we started Cause of a Kind, one of the promises was that we would chase meaningful work, not just clean scopes. There is nothing wrong with ordinary business software. Plenty of it matters. But the agency was built around the idea that we could bring strong product and engineering judgment to mission-driven organizations, especially the ones doing work that deserved better tools than they usually had access to. That is why the opportunity to work with [Best Education Strategies Technology](https://bestconnections.org/) was too good to pass up. BEST supports people suffering from traumatic brain injury. That changes the stakes of the software. Accessibility is not a polish pass at the end. It is not just contrast, labels, keyboard support, and ADA compliance. Those things matter, but they are the floor. For this population, accessibility also means cognitive clarity. The product has to work for people dealing with memory issues, attention challenges, fatigue, confusion, sensory sensitivity, and difficulty processing dense information. A screen that looks clean to a typical product team can still be too demanding. A workflow that feels efficient to a developer can still ask too much of the person using it. The original project began as a mobile migration. BEST had one iOS app that effectively contained four apps inside it, each serving a different use case. The plan was straightforward: separate those experiences into four React Native applications, bring them to Android, and make them offline-ready. At the time, that thesis made sense. Native apps felt like the right container. Offline support felt important. Separate applications seemed like a cleaner way to serve distinct workflows. We rebuilt two of the four that way. Strategize My Life went fine. Pace My Day was harder. Pace My Day relied heavily on timers. Timers sound simple until they live inside a mobile operating system that can push an app into the background, pause work, manage battery aggressively, and behave differently across devices. The more we saw real usage, the more the original assumptions started to fray. Users switched devices. A strategy might begin on a tablet, while a timer started on a phone. People wanted their data to follow them. They wanted the system to feel continuous. That challenged the idea that local-only offline behavior was the most important requirement. The separated-app model created its own friction too. Separate apps on the same device could not simply share one SQLite database. What looked clean in the app store created awkward boundaries in real life. So we tried to make the architecture more serious. We designed a backend that could receive and reconcile events from different devices. Event sourcing made sense for the problem. If users were generating activity across phones and tablets, we needed a way to capture what happened and rebuild the truth from those events. Technically, that was the right kind of thinking. Operationally, the mobile surface kept fighting us. Some users did not update app versions. TestFlight added confusion. React Native gave us push support, but support across many devices, operating system behaviors, and app versions became difficult to reason about. The hardest part was not writing code. It was debugging what was happening in the hands of a nontechnical population that was already dealing with enough. Then AI-assisted development changed the economics of the decision. After years of learning, we asked the question that teams are usually afraid to ask: what if the original thesis is wrong now? Maybe the product should be one suite again. Maybe it should not be native. Maybe offline was less important than sync, supportability, visibility, and the ability to ship fixes immediately. Maybe the humane product was not the one that lived deepest in the phone. Maybe it was the one we could understand, improve, and keep current for everyone. We rebuilt BEST App Suite as a Ruby on Rails PWA. That choice changed the shape of the product. Users could still install it as a tile on their phone like an app. But we no longer had to wait for app store updates, version adoption, or TestFlight confusion. When something needed to change, we could ship it. When something went wrong, we had more visibility. When users moved across devices, the product could rely on a shared server and database instead of pretending every device was an island. Most importantly, the rewrite let us carry years of user learning into the new architecture. Timers and data could sync across the suite. The apps could share a foundation. The product could support a physician portal where people suffering from traumatic brain injury could share their data and progress with the doctors caring for them. That is not a small detail. It changes the product from a set of tools into a bridge between a person and their care team. The old conventional wisdom says you should never rewrite. I understand why. Rewrites often become expensive ways to forget everything the first version taught you. But AI-assisted development changes the math when the team is disciplined. It does not make rewrites automatically wise. It does make it possible to move faster through the parts you now understand, while spending more attention on the parts that actually matter. In this case, the rewrite was not an ego decision. It was a product decision. We had years of evidence. We knew the pain points. We knew where native mobile was hurting support. We knew where the separated apps were fighting the user experience. We knew that a shared backend could make the suite more coherent. So the second version came out better. It is easy to talk about AI in abstract productivity terms. Faster tickets. Faster code. Faster prototypes. This project is a better example of what that speed is for. It let us revisit a hard product with more knowledge, rebuild it in months, and give users something clearer, more maintainable, and more connected to real care. That is the part that still feels incredible. Software is often sold as efficiency. Here, the work is more human than that. Good software meets users where they are. For BEST App Suite, that meant admitting what the first architecture taught us, letting go of the original thesis, and rebuilding the product around the lives of the people it was supposed to help. --- # Misunderstanding Technical Debt Technical debt is not automatically bad. The real problem is when nobody remembers what the debt bought or when it has come due. Published: April 18, 2026 Tags: Technical Debt, Engineering Leadership, Startups Canonical URL: https://michaelrispoli.com/blog/misunderstanding-technical-debt/ Technical debt is a useful phrase that got worn out by lazy conversations. Bad code gets called debt. Old code gets called debt. Work nobody wants to do gets called debt. Sometimes that is accurate. Sometimes it is just a polite way to say, "I hate this part of the system." Debt is not automatically bad. A startup should take debt when speed, learning, or survival matters more than elegance. That can be the right trade. The problem starts when nobody remembers making it. Good technical debt has a receipt. We cut this corner to validate demand. We kept the manual process because the customer workflow was still foggy. We chose the vendor because it bought us six months. We duplicated the code because the abstraction would have been fake. Bad technical debt has amnesia. Nobody knows why the decision exists, what it bought, or when it should be revisited. The system becomes a museum of old urgency. This is where founders and engineers talk past each other. Engineers feel the drag every day, so they ask for time to clean things up. Founders hear an expensive pause with fuzzy business value. Both sides are usually holding part of the truth. The better question is not, "Should we fix the debt?" The better question is, "Which debt is charging interest now?" Is it slowing delivery? Is it creating support burden? Is it blocking revenue? Is it making good engineers leave? Is it increasing the risk of a failure the company cannot absorb? When the answer is yes, it is not cleanup. It is business work. Technical leadership has to make that visible without turning every messy file into a crisis. Speed is not free. Cleanup is not always noble. The adult move is to show the trade clearly enough that the business can choose with its eyes open. --- # Client Anxiety Is Product Signal An anxious customer is not always a delivery problem. Sometimes they are showing you where the product, process, or promise is unclear. Published: March 29, 2026 Tags: Clients, Product, Delivery Canonical URL: https://michaelrispoli.com/blog/client-anxiety-is-product-signal/ An anxious client will often ask the same question in three places. They ask in Slack, ask again in the project plan, and then bring it up on the next call because the first answer did not make them feel any better. From the delivery side, this can feel like noise. The team is working. The tickets are moving. The answer was already given. Why are we still talking about it? Usually because anxiety is what risk feels like when nobody can see its edges. The client may not understand what is happening. They may not trust the plan yet. They may have promised a launch date to their boss, their board, or a customer who is already irritated. They may also be reacting to a previous bad experience that looked fine until it suddenly was not. More explanation can help, but explanation is not the same thing as confidence. Confidence comes from visible work, small proofs, clear tradeoffs, named risks, and a next step that does not sound like a shrug. When a client keeps asking where things stand, the problem may not be that they are needy. The system may be making reality too hard to read. The same thing happens inside startups. Founders get tense when engineering feels like a sealed room. Engineers get annoyed because they are working hard and feel mistrusted. Product starts translating emotion into tickets. Everyone uses more words, and trust keeps leaking out of the process. The repair is usually operational before it is emotional. Show work sooner. Ship smaller cuts. Tie progress to decisions. Say what is known, unknown, blocked, and next. Kill vague percentages. "We are 80% done" sounds confident but does not mean much. "The workflow is built, payments are blocked on account approval, and the next risk is refund handling" is useful. Anxiety drops when people can see the shape of the problem. That does not mean every concern is valid, or that every stakeholder gets the wheel. It means technical leadership owns trust as part of the product surface. Clients and founders do not need theater. They need enough truth to make a good call. --- # Marketplaces Do Not Start as Marketplaces The cold start problem is not a technical problem first. It is the part of the business most founders have to solve by hand. Published: February 17, 2026 Tags: Marketplaces, Product Strategy, Startups Canonical URL: https://michaelrispoli.com/blog/marketplaces-do-not-start-as-marketplaces/ The clean marketplace pitch is almost always the same. There are sellers on one side. Buyers on the other. The platform sits in the middle, takes a fee, and gets stronger as both sides grow. The slide looks obvious because it skips the only part that matters. Why would either side show up first? Andrew Chen popularized this as the cold start problem, and it is not academic. Sellers do not want to list products into an empty room. Buyers do not want to browse a marketplace with weak supply. Brands do not want to pay for access to creators until the creators can move real demand. Creators will sign up for free all day, but that does not mean the other side has a reason to spend money. That tension kills more marketplace products than bad code does. I have seen this shape a few times. One founder already had a real business. It was not a pure software platform. It involved physical products, relationships, curation, and a lot of operational work that did not look clean in a venture pitch. But it gave the company something most marketplaces would kill for: access to both sides of the market. There were buyers. There were suppliers. There was actual demand. The work was messy, but the mess was evidence. Investors wanted something cleaner. Less physical business. More platform. More like Etsy or Faire. More software margin, more marketplace language, more scalable narrative. The direction sounded bigger, but it pulled the product away from the people who were already buying. That is the dangerous part of taking marketplace advice from people evaluating a pitch instead of operating the business. They may push you toward the version of the company they would like to fund, then never fund the painful transition they helped create. The product work becomes confused because the business gets confused. Instead of turning the existing operation into software one proven workflow at a time, the team starts building a marketplace for customers who have not asked for it yet. Merchant onboarding. Buyer discovery. Admin tooling. Payments. Search. Profiles. Inventory. Messaging. Every piece may be reasonable in isolation. Together, they can become a very expensive theory. The theory usually sounds like this: if we build the platform, the market will organize itself. Usually it will not. The famous marketplace stories make this easy to forget because we remember the scaled version, not the awkward first version. Airbnb did not begin as a global lodging marketplace with infinite inventory and polished trust systems. It began with air mattresses, conferences, city-by-city urgency, and founders doing work that had no business existing in a scalable platform. When listings in New York looked bad, the founders went to hosts, rented a camera, and took better photos themselves. That was not a feature. It was a manual intervention into the supply side of the market. But it solved a real marketplace problem. Travelers did not trust weak listings. Hosts did not know how to merchandise their own homes. Better photos made the supply more legible, which made buyers more willing to book, which made hosting more worthwhile. The unscalable work created the conditions for the scalable marketplace. Uber had a different version of the same problem. A ride-hailing marketplace is worthless if riders open the app and see no cars. It is also worthless if drivers wait around with no rides. Early Uber did not solve that by launching a universal transportation platform on day one. It started with a narrow, premium black-car use case, in one city, where the supply could be recruited and the experience could be controlled. That focus mattered. The company did not need every rider, every driver, and every trip type at the start. It needed enough reliable supply in a dense market to make the app feel real. The early marketplace was not broad. It was constrained, operational, and local. Only later did the product expand into cheaper rides, more drivers, more cities, and a more general transportation network. The lesson is not that every founder should copy Airbnb or Uber. Most should not. The lesson is that even the iconic marketplaces did not cold start by acting like fully liquid platforms. They found a narrow pocket of demand, made the supply side better by hand, and used manual work to create trust before software could carry the load. Another founder I worked with had the same problem in influencer marketing. Signing up influencers was easy because it cost them nothing and offered upside. The supply side looked healthy in the dashboard. The demand side was a different story. Brands did not want to pay just because the marketplace existed. They needed trust, proof, campaign support, quality control, and confidence that the work would produce a business result. The software could register interest. It could not manufacture demand. I saw a similar pattern in advertising. The pure marketplace model struggled. The service business worked better because the founders could make the match, manage the work, learn the buyer's objections, and turn vague interest into actual revenue. It was less elegant, but it was closer to money. This is why the "unscalable" work matters. Manual matching is not a failure of product strategy. Concierge onboarding is not automatically a lack of ambition. A founder making calls, curating supply, walking buyers through options, and handling the awkward middle is often doing the most important product research in the company. That work tells you what the platform should become. It shows which buyers are real, which sellers are worth recruiting, where trust breaks, what needs to be guaranteed, what can be automated, and where the business actually earns its take rate. It also shows whether the marketplace should exist at all. Sometimes the better company is a service business with software leverage. Sometimes the marketplace is a later stage of the operation, not the starting point. Founders get into trouble when they treat manual work as something to hide from investors. The better move is to understand it deeply enough to explain why it is an advantage. The service layer can be the wedge. The buyer relationships can be the demand engine. The curated supply can be the moat before the marketplace has enough liquidity to stand on its own. Code still matters. The architecture has to support different users, permissions, payments, workflows, and operational control. But the architecture should follow the cold start strategy, not replace it. Building seller portals and buyer discovery before you know how the first valuable transactions happen is just a polished way to avoid the hard part. Marketplaces are not hard because there are two sides. They are hard because both sides are waiting for proof, and early proof usually comes from a founder doing the work the platform is supposed to make disappear. --- # When an AI Project Needs a Rules Engine Incentiviiz started with an LLM thesis. The real product needed a hands-on fractional CTO, deterministic software, and AI used in the right place. Published: December 12, 2025 Tags: Case Study, AI, Product Engineering Canonical URL: https://michaelrispoli.com/blog/conduiit-incentiviiz-ai-tax-incentives/ Some AI projects become more interesting when AI turns out not to be the answer. That is what happened with Conduiit and Incentiviiz. It is also a good example of what a fractional CTO role can look like when it is actually useful. This was not a few advisory calls and a diagram. It was hands on keyboard, working beside a domain expert in film production accounting, trying to turn a hard professional workflow into software that could survive real data. I had to learn enough of the domain to understand what the expert was seeing, then translate that judgment into product structure, technical architecture, and working code. The original thesis was reasonable. Film and television tax incentive work involves dense laws, changing jurisdictions, complicated ledgers, and accountants trying to understand which expenses may qualify across countries, states, counties, provinces, and regions. It is the kind of domain where an LLM sounds like a natural fit. Let the model read the law. Let it inspect rows in an accounting ledger. Let it decide what qualifies. Turn weeks of manual review into an intelligent workflow. At small scale, it looked impressive. Give the system a few rows of ledger data and a narrow incentive rule, and the model could produce a useful explanation. It could reason through a transaction. It could point at possible eligibility. It could make the demo feel like the future. Then production reality showed up. The model did not guarantee that it would find the same rows every time. It did not always apply the same reasoning every time. Sometimes the law itself was not perfectly clear about whether a particular expense qualified. That ambiguity is already hard for humans. Feeding it into a nondeterministic system made the problem worse, not better. We did not arrive at that conclusion from theory. We arrived there in the lab, testing the product against real ledger data and watching where the AI approach bent, slowed down, or changed its mind. That is the kind of evidence a founder needs from a technical leader: not generic AI optimism, and not reflexive skepticism, but a working diagnosis from contact with the actual workflow. That problem compounds fast. A multimillion-dollar production does not have five ledger rows. It can have thousands upon thousands of transactions spread across pages of accounting data. If every row requires an LLM call, the system becomes slow and expensive. Worse, the result is not guaranteed to be repeatable. That is unacceptable for accountants. It is unacceptable for state tax offices. It is unacceptable for anyone making financial decisions where the system needs to explain what it did and produce the same answer under the same conditions. The demo said AI could do the work. The product said something more honest: AI could help us understand the work, but the final computation needed good old-fashioned programming. The real solution was a deterministic rules engine. Instead of asking an LLM to evaluate every ledger row at runtime, the product needed rules that could run quickly, consistently, and explainably against structured ledger data. The system had to parse ledgers, classify transactions, apply incentive rules, compute totals, and produce repeatable results at computer speed. That is a different kind of engineering problem. Less magical in the demo. Much more useful in production. The rules engine became the spine of the product. AI still had a role, but the role changed. It was useful for reading law, exploring edge cases, summarizing dense material, comparing provisions, and helping author or refine the deterministic rules that would later run the same way every time. That required a tight loop between domain expertise and engineering. The expert could explain why a category of spend mattered, where the law was ambiguous, how accountants would review the output, and what kind of answer would be defensible. My job was to turn that into software primitives: rules, calculations, review states, data structures, and interfaces that made the expert workflow repeatable. That distinction matters. AI is excellent at helping humans move through ambiguity. It is not always the right tool for final authority. In Incentiviiz, the LLM could assist the process of turning messy legal and accounting context into structured rules. Once those rules existed, the runtime system could apply them consistently across large ledgers without the latency, cost, and inconsistency of model calls for every transaction. This is the kind of lesson AI prototypes hide. The impressive prototype is the model reasoning over a few examples. The serious product is the system that can run over an entire production ledger, finish quickly, produce the same result twice, preserve assumptions, expose review points, and give accountants something they can defend. That does not make the product less AI-native. It makes it more mature. The strongest AI products will not blindly throw models at every workflow. They will use all the power of computers: deterministic code where repeatability matters, databases where truth has to persist, rules engines where logic has to run quickly, and LLMs where language, ambiguity, and authoring support create real leverage. That is the lesson from Incentiviiz. The job was never to make the machine sound smart. The job was to build a system that works. --- # Modernizing a Service Admin UI Without a Rewrite A service admin panel had become hard to change. The fix was not a full rewrite, but an AI-assisted strangler migration from strange React patterns to predictable code. Published: September 18, 2025 Tags: Case Study, Product Rescue, React Canonical URL: https://michaelrispoli.com/blog/service-admin-ui-modernization/ A software rescue does not always mean rewriting the product. Sometimes the users are fine. The UI works. The business depends on it every day. The problem is that the code underneath has become so strange that every change takes too long, every estimate feels padded, and the development team is afraid of touching the wrong thing. That was the situation with a service admin management UI we helped modernize. The app was an old Create React App build. It used React, but not in the way most React engineers expect to read it. Instead of traditional JSX and recognizable components with hooks, the code leaned on factory-style patterns that made it difficult to look at a file and understand the HTML being produced. That matters. JSX is one of the reasons React works so well. It gives engineers a visual, readable bridge between component logic and interface structure. When that disappears behind custom factories, the app may still run, but the code stops explaining itself. The state layer added another problem. The app also used Redux, which meant a non-React specialist had to understand both the unusual rendering pattern and a separate state-management model before safely changing the UI. Two complex concepts were working against the team at the same time. The first step was not coding. It was archaeology. We used LLMs and AI-assisted analysis to audit what was happening across the application. Where did these patterns come from? How did data move? Which factories produced which parts of the interface? Where was Redux essential, and where was it just making simple UI work harder? You know you are on shaky ground when the LLM has not really seen the pattern before. But it could still help pick the system apart. That is one of the better uses of AI in software rescue: not blindly changing code, but helping a senior engineer map a strange codebase faster. Once we understood the shape of the app, the decision was clear. A full rewrite did not make sense. The customer service team was already using the panel. They were happy with the general UI. They just had changes they wanted, and those changes were taking weeks or months instead of hours. Breaking the whole product apart to prove an architectural point would have punished the people depending on it. So we used a strangler pattern. Section by section, we rewrote the interface into standard React with JSX. We replaced the confusing factories with readable components. We introduced hooks and query patterns where they made the data flow easier to reason about. As we touched each section, we incorporated the actual requests from the customer service team and shipped those improvements along the way. The goal was boring on purpose: no visual or operational disruption for users, but a much better codebase underneath. That is a good rescue principle. If the users are already relying on the product, success is not always a big reveal. Sometimes success is that nothing feels broken while the engineering team slowly regains control. We also modernized the API assumptions. The backend needed to behave more like a traditional REST API, with predictable resource boundaries and request behavior. That gave both humans and LLM-assisted development a clearer contract to work against. We added JSDoc types instead of forcing a full TypeScript migration all at once. TypeScript may have been the cleaner long-term destination, but it also would have expanded the surface area of the change. JSDoc gave us more type safety and editor support while keeping the migration focused. The final infrastructure step was getting off Create React App and onto Vite. Create React App is no longer the right foundation for modern React work, and staying on it would only make future maintenance harder. The result was not a rewrite. It was modernization without operational drama. That distinction matters. Full rewrites have their place, but this was not one of them. The app had users. The workflows were known. The UI did not need to be reinvented. The real problem was that the code had become hostile to change. AI helped, but not by magically rebuilding the product. It helped with audit, comprehension, pattern extraction, and mechanical migration. The engineering judgment was deciding how to use that leverage without creating unnecessary risk. The measure of success was simple: how fast can the team ship the next requested change? Before, changes could take weeks or months because nobody wanted to touch the code. After the modernization, the same kind of work could move in hours. That is what a good rescue should do. It should not only make the code prettier. It should give the business its change velocity back.