Vijay Raina is a distinguished authority in the realm of enterprise SaaS and software architecture, bringing years of seasoned perspective to the rapidly evolving intersection of artificial intelligence and product design. As a specialist who has navigated the complexities of internal tooling and large-scale software deployments, he offers a unique vantage point on how AI agents are fundamentally reshaping the “buy versus build” debate within organizations. His expertise lies not just in the code itself, but in the sophisticated abstractions and user experience nuances that differentiate a mere prototype from professional-grade software.
This conversation explores the transition from traditional SaaS subscriptions to bespoke, agent-built internal ecosystems, examining the critical “polish gap” that often plagues automated development. We delve into the specific UI patterns—such as optimistic updates, URL state persistence, and non-blocking autosave—that agents typically overlook unless explicitly directed. Vijay explains the strategic importance of packaging architectural opinions into reusable agent skills and the transformative power of end-to-end verification loops, where agents must prove their work through real-world execution. The discussion also touches on the “SaaS is dead” philosophy and how a well-structured codebase serves as the essential foundation for these autonomous builders to succeed.
You have replaced a broad range of subscriptions—from CRMs to social posting platforms—with a single internal tool built by agents. How did you manage to consolidate so many disparate workflows into one cohesive environment?
The journey began with the realization that the traditional SaaS model, while convenient, often creates fragmented silos that don’t perfectly align with a company’s unique marketing or operational heartbeat. By leveraging AI agents, I was able to construct a unified platform for Railway that handles everything from managing website content, changelogs, and blogs to executing complex email campaigns and simultaneous cross-platform social media posting. We didn’t stop there; the tool also integrates a mini CRM for creator relations, task tracking, and a comprehensive launch planning system with a built-in calendar and real-time editing capabilities. It’s an expansive scope, but the beauty of using agents is that they can stitch these functions together far faster than a human team could manually code each integration. The key was not just asking for “a CRM” or “a blog,” but defining the specific data relationships and workflow hooks that allow a task in the planner to automatically trigger a social post or a changelog entry, all living within the same infrastructure we use to host our primary services.
What is the defining difference between “working software” generated in a single shot and the “polished software” that users actually find joy in using?
There is a massive, often underestimated gap between code that simply executes a function and software that feels truly responsive and professional. When an agent “one-shots” a replacement for a SaaS tool, it usually produces a basic server-rendered application with standard form submissions and loading spinners—the kind of experience that feels clunky and reminds you why you paid for a premium subscription in the first place. Polished software, on the other hand, is defined by subtle, high-leverage behaviors like background autosaving that guards against accidental tab closures, or optimistic updates where the UI reflects success immediately while the server syncs in the background. It’s about the invisible care in the flows, like having an “undo” button that gives you a five-second window to reverse a mistake rather than forcing a jarring confirmation dialog every time you hit delete. To cross this gap, you have to explicitly demand these “polish patterns” because agents, by default, will almost always take the path of least resistance, leaving out the very details that make a tool feel like something you actually want to reach for every day.
You’ve mentioned that tech stacks don’t matter as much as they used to, yet you have clear preferences for things like the OneTen stack and Payload. How do these choices influence the quality of what an agent builds?
While it’s true that you can point a modern agent at almost any framework and get a result, the internal structure and abstractions of your chosen stack act as a powerful guide rails for the AI. I personally lean toward the OneTen stack for web development and Payload for content-related tasks because they provide a solid foundation with excellent abstractions that prevent the agent from having to reinvent the wheel. If the codebase is properly structured, the agent doesn’t just write new code; it follows existing patterns for data fetching, UI consistency, and state management, which leads to a much more stable and predictable outcome. I spent a significant amount of time exploring various CMS options—falling down a bit of a rabbit hole, honestly—and concluded that even though I could ask an agent to build a CMS from scratch, using a robust tool like Payload is smarter because it allows the agent to focus on the custom workflow layer where our specific opinions provide the most value. Essentially, the stack provides the “grammar,” and the agent provides the “story,” so you want a grammar that is clear and well-defined to avoid a chaotic narrative.
When instructing agents to build UI, you’ve identified six specific patterns they tend to skip, such as URL state and infinite scroll. Why are these particular elements so difficult for AI to implement without explicit prompts?
These patterns are often overlooked because they aren’t strictly necessary for a feature to “work” in a technical sense, but they are vital for the user experience. For instance, an agent will default to a manual “Save” button because it’s the simplest logical path, whereas a human user expects a non-blocking, real-time autosave. Similarly, agents often store filters and sorts in a component’s temporary state, which means if you refresh the page or send the link to a teammate, the view is lost; I have to explicitly tell the agent to persist that state in the URL. Another example is the “infinite scroll” versus the standard “Load more” button; the latter is easier to code, but the former provides that seamless, high-end feel we expect from modern applications. Even things like archiving instead of just deleting are critical for keeping a workspace decluttered without losing data, yet an agent will usually just provide a delete button and a confirmation box. None of these are inherently difficult for the agent to build—it’s just that they don’t “see” the friction of a poorly designed UI, so you have to be the one to advocate for the user’s sensory experience.
You have described a method of packaging your architectural opinions as “agent skills.” How does this approach change the way you interact with the AI during the development process?
Packaging opinions as skills is about creating a reusable set of “best practices” that the agent can tap into whenever it starts a new task, ensuring that it doesn’t deviate from the established design language or deployment strategy. I’ve developed three core skills that I use repeatedly: a design-engineering skill that covers typography, layouts, and error messaging; an animation skill for that final layer of polish; and a set of Railway-specific skills that allow the agent to provision and deploy infrastructure like databases and real-time servers automatically. By doing this, I don’t have to remind the agent to use a specific font size or a certain type of transition every single time; it’s baked into its “persona.” It transforms the interaction from micro-managing every line of code to giving high-level creative direction, knowing the agent will adhere to the rigorous standards I’ve already defined. It’s the difference between teaching someone how to cook a single meal and giving them a master class in your specific culinary philosophy so they can eventually run the kitchen themselves.
One of your more striking insights is the “700 million tokens” cost signal for real-time collaboration. Can you walk us through the struggle of getting an agent to master complex features like concurrent editing?
Real-time collaboration is perhaps the ultimate test for an agent because it involves complex state synchronization and conflict resolution that can’t be easily “one-shotted.” When I set out to implement concurrent edits in our internal tool, it wasn’t a matter of hours or days, but a massive iterative process—represented by that “700 million tokens” figure—where the agent and I went back and forth to refine the logic. The breakthrough usually happens when you stop treating the agent like a simple code generator and start treating it like a partner in a deep debugging session. You have to watch it fail, see where the synchronization breaks, and then provide the right abstractions or reference points to help it bridge the gap. It was an arduous process, but once the agent “got” it, the result was a seamless experience that allows multiple team members to edit content simultaneously without stepping on each other’s toes, proving that even the most complex SaaS features are within reach if you’re willing to invest the tokens and the oversight.
The “verification loop” seems to be your final safeguard against “hallucinated” success. How does this process work in practice, and why is it superior to traditional testing?
The verification loop is the most critical part of the entire workflow because agents are notorious for claiming a task is done when the actual experience is still broken. They will report that the build is passing and the tests are green, but when you actually open the app, the button doesn’t click or the data doesn’t save. By implementing a loop where the agent has to verify the feature works end-to-end on real infrastructure—literally “seeing” the result through advanced computer use capabilities—the dynamic shifts from “I think I finished” to “I have confirmed this works.” I can literally watch the agent build a feature, try it out, encounter a failure, fix the code, and try again until it achieves total success. This is a night-and-day difference from traditional development because it closes the feedback loop instantly and ensures that the final product isn’t just a collection of passing unit tests, but a functional, reliable tool that solves the problem it was intended to solve.
You’ve made the bold claim that “SaaS is dead” for internal workflows. What does it mean for an engineer to become a “SaaS layer player” in their own company?
To be a “SaaS layer player” means to take ownership of the tools your company uses, rather than just being a passive consumer of third-party subscriptions. In the current landscape, the excuse for paying high per-seat costs for generic tools is rapidly vanishing because agents have made it possible to build bespoke, high-quality alternatives in a fraction of the time. This isn’t just about saving money; it’s about creating software that perfectly matches your team’s specific opinions and workflows, sparking joy and increasing productivity in ways a generic CRM never could. It requires a shift in mindset where you stop looking for the “best” app on the market and start asking how you can encode your company’s unique logic into an agent-built solution. Standing there on that bench in Edinburgh with a 10 out of 10 view, it became clear to me that the future of software isn’t in more subscriptions, but in the ability of engineers to manifest their own polished, professional-grade tools on demand.
What is your forecast for the future of custom internal tools?
I believe we are entering an era where the distinction between “off-the-shelf” and “homegrown” software will become completely blurred, with internal tools eventually surpassing commercial SaaS in both utility and user experience for most organizations. Over the next year, the “verification loop” and “agent skills” approach will become the industry standard, allowing even small teams to maintain massive, sophisticated platforms with minimal manual overhead. We will see a massive exodus from mid-tier SaaS providers as companies realize they can build their own “SaaS layer” that is more secure, more integrated, and far more cost-effective. Ultimately, the “SaaS is dead” argument will move from a provocative theory to an undeniable reality, as the tools we build for ourselves become the most powerful assets we own, precisely because they are infused with our own architectural opinions and a level of polish that automated systems can now finally deliver.
