[{"data":1,"prerenderedAt":21},["ShallowReactive",2],{"post-day-1":3},{"postId":4,"tags":5,"content":12,"createdAt":13,"coverImage":14,"publishedAt":15,"updatedAt":16,"status":17,"slug":18,"excerpt":19,"title":20},"9b2f4350-341f-4710-b2c7-c338ea2d3d99",[6,7,8,9,10,11],"AI-Native Software","Buy vs Build","Software Economics","Operational Systems","Product Strategy","Platform Architecture","## My Wife Asked a Simple Question\n\nThis is the first article in a three-part series about AI-native software development, operational systems, and a question I think a lot of companies may need to revisit: when does it make more sense to build software instead of buy it?\n\nFor most of the last two decades, the answer was usually pretty clear. Buy the software. Even if it did not fit perfectly. Even if the workflow had to bend a little. Even if a few requirements were missing. Building custom software usually required too much time, too many people, and too much ongoing maintenance to justify the effort.\n\nThat tradeoff shaped a lot of the SaaS era. Companies learned to accept gaps because the alternative was worse. A tool that solved 70 or 80 percent of the need was usually better than funding a custom build from scratch.\n\nBut AI is starting to make that math look different.\n\nNot because AI can write code quickly. That is part of it, but it is not the whole story. The bigger shift is that AI can help move many parts of software development faster at the same time: requirements, architecture, interface design, data models, infrastructure, testing, deployment, and refinement.\n\nThat raises a more interesting question.\n\nWhat happens when it becomes practical to build software around a very specific operational need?\n\nThat question became real for me a couple weeks ago after a conversation with my wife. She is a senior project manager who has spent years running complex work across marketing, software, and client delivery teams. Her projects are the kind where sequencing matters. Approvals matter. Dependencies matter. One delayed deliverable can quietly create problems for several other people.\n\nShe asked me a simple question.\n\n“Are there any good Gantt chart builders anymore?”\n\nAt first, I assumed there had to be plenty. Project management software is everywhere. But once we started looking, the issue became clearer. There are a lot of strong tools for collaboration, task tracking, agile boards, team communication, and general project visibility. Many of them are very good products.\n\nBut that was not exactly what she needed.\n\nShe had a specific set of requirements that existing tools were not solving well. She wanted something dependency-first, but still lightweight. Something visual and easy to adjust. Something focused on sequencing and project flow, without turning the plan itself into a second job.\n\nThis was not a deep critique of agile versus waterfall. It was not a complaint about modern project management software. It was much simpler than that.\n\nShe had a workflow need that available SaaS tools did not match very well.\n\nThe conversation itself was practical. She was describing what she needed to manage real work. But afterward, I kept thinking about why that gap existed in the first place.\n\nFor years, when software did not fit a workflow, the answer was usually to adapt the workflow. Not because that was ideal, but because building something custom was too expensive. By the time you gathered requirements, designed the system, built the app, managed the infrastructure, handled authentication, supported users, and maintained it over time, the cost usually outweighed the benefit.\n\nThat is where the conversation turned into a thought exercise for me.\n\nWhat if AI changes that equation?\n\nWhat if software can be built around the exact workflow instead of forcing the workflow to fit the software?\n\nAnd more specifically, could someone with product, systems, and infrastructure experience now build something that previously would have required a much larger team?\n\nI had a useful advantage in testing that idea.\n\nOver the last several years, I have spent a lot of time building serverless systems with SST on AWS. That stack removes a lot of the overhead that used to come with launching software. APIs, authentication, deployment environments, queues, databases, and infrastructure can be defined and managed much more cleanly than they could in older development models.\n\nWhen you combine that kind of infrastructure with AI-assisted development, the path from idea to working product starts to look very different.\n\nI was not interested in seeing whether AI could randomly generate an app. That feels like the least interesting version of this moment. I wanted to test something more practical: could I take a clear operational need, pair it with modern infrastructure and AI-assisted development, and build software that matched the requirement closely enough to be useful?\n\nSo I decided to test it.\n\nI committed to building exactly what she described. Not as a mockup. Not as a throwaway prototype. As real software designed around her requirements from the start.\n\nAnd I gave myself three days to see how far it could go.\n\nIn Day 2, I’ll walk through what that build process actually looked like, and why I think the role of the modern product builder is starting to change along with the economics of software itself.","2026-05-12T17:22:29.707Z","https://ericnparadis-com-prod-mediabucketbucket-baexchhz.s3.amazonaws.com/media/accbfed7-5c2b-450d-95d2-ee6a1268030a.png","2026-05-12T17:22:29.704Z","2026-05-12T18:38:25.809Z","published","day-1","For years, companies adapted their workflows to fit software. AI may make it practical to build software around the workflow instead.","Day 1  ",1778611230316]