Mahmoud Abdelwahab (Railway) describes replacing several internal marketing tools with a single app built using coding agents. He explains that beyond generating working features, the difference between a quick SaaS replacement and a tool the team actually uses lies in product polish: background autosave that doesn't block typing, optimistic updates that recover from failure, undo and archiving, URL state for shareable filtered views, and infinite scrolling. He covers structuring the codebase with reusable abstractions so new features follow existing patterns, referencing existing pages to help agents reuse interface and data-fetching conventions, packaging recurring design and deployment preferences into agent skills, and finishing with a verification loop that exercises the running feature end to end. Lessons are drawn from an internal tool, with no claim of measured financial savings. # Video Identity Observations ## Video Overview - **Title:** *"Please… Enough with the Sloppy, One-Shot SaaS Replacements — Mahmoud Abdelwahab, Railway"* - **Format evidence:** A recorded conference-style talk delivered outdoors: *"instead of doing my talk from my boring office, I decided to switch things up and do it outside… I'm in Edinburgh, Scotland"* — with the speaker noting it is a departure from his usual format: *"this type of talk for me feels a little bit different than what I'm used to."* ## Intended Audience - **Developers building with AI agents**, particularly those building internal tools. Evidence: the entire talk is structured as principles for agent-driven development (*"the principles that you can pull from and apply when building tools of your own"*). - **Teams considering replacing SaaS products with in-house tools.** Evidence: opens on the "SaaS is dead" discourse (*"Why pay someone to build and maintain the tools you use when you could just do it yourself?"*) and closes with *"I hope that you too can become your company's SaaS layer."* - The speaker also addresses a **beginner-adjacent audience**: *"it's not difficult for the agent to build it. You just need to ask and know exactly what to ask for."* ## Claimed Scope - A **principles-based guide to polishing agent-built software**, not a "vibe coding" celebration. Evidence: *"there's a gap, a big gap between working software that got one-shotted and software I would actually use."* - Grounded in **real internal work at Railway**: *"a journey to replace a bunch of SaaS providers we're using internally at Railway for marketing purposes"* — a tool covering CMS, email, social posting, media, mini-CRM, task tracking, and calendars. - Explicitly **time-boxed and provisional**: *"the landscape changes very very quickly… Consider this my disclaimer. The time of recording is fall 2026. It's October."* ## Self-Description Evidence - Positions himself as a **practitioner with strong opinions**, not a general commentator: *"I essentially will walk you through the journey of me building our own internal tools and the opinions I've developed."* - Self-identifies tooling preferences: *"my go-to choice today is TanStack libraries… if you're building anything content related, I would say definitely go with payload."* - Claims deep familiarity with polished SaaS from the **user side**: *"when you use a lot of SaaS products out there that you actually love… you quickly find out how much care and thought goes into different flows."* - Positions himself at the frontier of agent capability: *"I felt the breakthrough when GPT-6 came out"* and *"I felt this breakthrough with computer use once it got really, really good."* ## Observable Presentation Patterns (Demonstrated, Not Claimed) - **Practical, pattern-level specificity:** a concrete checklist of product polish patterns — autosave, optimistic updates, undo, archiving, URL state, infinite scroll, reference pages — each with rationale. - **Candid about agent limitations:** *"sometimes it just doesn't follow it. I don't know if models get dumber sometimes."* - **Platform-affiliated:** everything *"runs on railway… buckets, databases, the app itself, the real-time server"* — with matching "Railway agent skills" promoted as a deliverable. - **Honest about cost/limits:** *"just 700 million tokens later, I had real-time."* - **Closing tone is motivational and community-oriented:** *"hope you're inspired to build your own internal tools that feel good, that are polished, and spark joy."* # Delivery Observations — Mahmoud Abdelwahab, Railway ## Tone - **Conversational and casual** throughout, with heavy use of hedging fillers: *"you know," "like," "I don't know," "sort of."* Examples: *"you should tell your agent you want the ability to archive records"* is delivered as friendly advice, not formal instruction. - **Self-deprecating humor** appears at key moments: *"just 700 million tokens later, I had real time"* and *"I don't know if models like get dumber sometimes."* - **Enthusiastic framing of personal experience**: *"it's just unreal. Like I'm on a bench outside and this is my view. Definitely a 10 out of 10 bench."* ## Recurring Vocabulary and Phrases - **"Spark joy"** — used twice, bookending the talk: *"Software that sparks joy"* early on and *"internal tools that feel good, that are polished, and spark joy"* at the close. - **"Ask your agent"** — the central repeated imperative: *"Just ask your agent to do it," "you should ask your agent to persist in the URL," "you can just ask your agent like, 'Hey, I would like to implement optimistic updates.'"* - **"Pattern(s)"** — used frequently to frame teaching points: *"a bunch of patterns that I found that agents don't typically do," "Another pattern I found," "the first one is like autosave."* - **"Table stakes"** — quality-benchmark language: *"autosave is kind of like a table stakes feature."* - **"Polished"** — repeated success criterion: *"actually polished and matches the rest of the app," "tools that feel good, that are polished."* ## Teaching Habits - **Numbered/list-structured delivery** with explicit signposting: *"let's talk about the first point which is texts don't matter," "which ties into the next point," "This list kind of brings me to my next point," "So we'll go through them one by one."* - **Concrete before/after contrast** as the core explanation technique: delete-with-confirmation vs. delete-with-undo (*"a much nicer experience is actually allowing the user to undo that action"*), loading spinners vs. optimistic updates, "load more" buttons vs. infinite scroll (*"I don't want to be clicking on load more over and over and over"*). - **Practical recommendations with named tools**: *"my go-to choice today is one tan stack libraries," "definitely go with payload. Solid experience, great abstraction."* - **Anticipates objections and adds caveats**: *"of course you shouldn't blindly have optimistic updates for everything," "persist in the URL whenever it makes sense of course."* - **Explicit timestamped disclaimer** about fast-moving landscape: *"Consider this my disclaimer... the time of recording is fall 2026. It's October."* ## Communication Patterns - **Direct second-person address**: *"you will end up with solid internal tools," "Hope you found them useful," "I'll see you in the next"* — consistent viewer-facing framing. - **Persona-building opening** before content: the Edinburgh bench setup establishes the informal, on-location format before any teaching begins. - **Contrast-driven rhetoric**: *"night and day difference," "a gap, a big gap between working software that got oneshotted and software I would actually use."* - **Memorable closing aspiration**: *"you too can become your company's SAS layer."* ## Uncertainty Notes - Repetition of "spark joy," "ask your agent," and list signposting is well-evidenced (multiple occurrences each). - The humor and bench persona appear only once or twice each; whether these are stable habits of the speaker or choices specific to this talk cannot be confirmed from a single transcript. # Observation Record: "Please… Enough with the Sloppy, One-Shot SaaS Replacements" **Speaker:** Mahmoud Abdelwahab (Railway) — identified via curated metadata; transcript is first-person throughout. **Stated recording context (speaker's own disclaimer):** Recorded **fall 2026, October**, in **Edinburgh, Scotland**. He explicitly warns his views may "change completely in like the span of months." --- ## Core Thesis > "There's a gap, a big gap between working software that got one-shotted and software I would actually use." - The "SaaS is dead, just ask your agent to build it" take is common, but the **polish gap** is rarely addressed. - Evidence offered: he replaced multiple internal SaaS providers at Railway with a single all-in-one marketing tool (website/changelog/blog content management, email sending, multi-platform social posting, media management, mini CRM for external creators, task tracking, launch planning, calendar, comments, real-time editing) — all agent-built, running on Railway with auto-deploys. - He credits a "breakthrough" to **GPT6**. ## Positions & Stated Reasoning ### 1. "Texts don't matter" — with qualification - **Claim:** Language/framework choice "doesn't really matter" *as long as* the codebase is properly structured with solid abstractions. - **Reasoning:** A structured codebase means the agent follows existing patterns rather than reinventing wheels, producing more consistent features. - **Personal preferences stated:** TanStack libraries for web; **Payload** for content-related builds (after a CMS comparison rabbit hole — he believes CMS shouldn't be built from scratch "even though I can"). ### 2. UX patterns agents don't implement unless explicitly asked - **Autosave:** "table stakes" for editors; should be non-blocking, plus prevent tab close with unsaved changes. - **Real-time collaboration:** agent handled it easily — self-deprecating quote: *"just 700 million tokens later, I had real time."* - **Optimistic updates:** show success state, sync in background, roll back on failure — with explicit qualification: *"you shouldn't blindly have optimistic updates for everything"*; some scenarios warrant spinners. - **Undo instead of confirm-dialogs:** delayed deletion pattern. - **Archiving:** hide records without forcing deletion. - **URL state:** persist filters/sorts for shareability. - **Infinite scroll** over "load more"/pagination buttons. - **Use existing pages as references** — with honesty about failure modes: *"sometimes it just doesn't follow it. I don't know if models like get dumber sometimes."* Success rate is nonetheless higher. ### 3. Opinions should be packaged as agent skills Three skills he used: two design-engineering skills (UI/typography/layouts/error messages; animations), plus **Railway agent skills** (everything — buckets, databases, app, real-time server — runs on Railway). ### 4. Verification is "the most important step" - Agents claim success ("build passed, test pass") while the actual experience can be "very broken." - A **verification loop** using computer use is a "night and day difference": build → try → fail → fix → repeat. - Instruction he now always gives: verify the feature end-to-end by actually running infrastructure. ## Unresolved Tensions (preserved as stated) - He "agrees to some extent" with the language-doesn't-matter claim, then qualifies it heavily. - Reference-following and even CMS-from-scratch positions carry "who knows, maybe the future will change" hedging. - Success rates are described as improved, not guaranteed. ## Closing Framing Hopes viewers build tools that "spark joy" and "become your company's SaaS layer." # Speaker Attribution & Provenance Record **Video ID:** `01a15ca6-73fe-7d86-aaaf-8b5eb41df09c` **Title:** Please… Enough with the Sloppy, One-Shot SaaS Replacements — Mahmoud Abdelwahab, Railway --- ## Speakers & Roles | Speaker | Role | Basis | |---|---|---| | **Mahmoud Abdelwahab** | Creator / presenter, identified in title as affiliated with **Railway** | Title metadata; first-person narration throughout ("our internal tooling… at Railway") | - Single-speaker talk; no guests, interviewers, or third-party voices appear. - No narrator distinct from the creator; the creator narrates directly. - Speaker self-identifies context: recorded **fall 2026 (October)**, presented outdoors in **Edinburgh, Scotland** — stated explicitly as a disclaimer given the fast-changing landscape. --- ## Referenced Sources & Tools (as claimed by speaker) - **Internal Railway tool** the speaker built: content management (website, changelog, blog), email sending, social posting, media management, mini CRM, task tracking, launch planning, calendar, comments, real-time editing. - **Technologies named:** TanStack libraries, Payload (CMS), Railway (hosting — buckets, databases, app, real-time server). - **AI models/tools referenced generically:** "GPT6" (breakthrough claim), agents, computer use (for verification loops). - No cited papers, external studies, or attributed third-party claims beyond these product mentions. --- ## Promotional Content > ⚠️ **Promotion flag:** The talk repeatedly promotes **Railway** — the speaker's employer — as the hosting platform for all internal tooling, and promotes **Railway agent skills**. This constitutes embedded employer promotion within the talk. - Recommendation of **Payload** and **TanStack** reads as personal endorsement, not explicit sponsorship; sponsorship status **unverified/unstated** in transcript. --- ## Availability & Community Features - **Comments:** No information in transcript or metadata. - **Transcript completeness:** Appears complete (ends with sign-off: *"thank you so much for watching and I'll see you in the next"* — truncated mid-phrase at source). - No links, resources, or downloadable materials referenced as accompanying the video. --- ## Provenance Notes - All claims (e.g., "700 million tokens later, I had real time," GPT6 breakthrough, verification-loop efficacy) are **first-person speaker assertions**, not independently sourced. - Speaker explicitly disclaims durability of statements given landscape volatility. - No audience questions, co-speakers, or quoted third parties appear in the transcript. People have been saying that SAS is dead for a while now. It's not even a hot take at this point. Why pay someone to build and maintain the tools you use when you could just do it yourself? Just ask your agent to do it. And for me, there's one missing piece that rarely gets mentioned. And it's the fact that there's a gap, a big gap between working software that got oneshotted and software I would actually use. Software that sparks joy, that is polished, that feels good. and actually went on a journey to replace a bunch of SAS providers we're using internally at Railway for marketing purposes. And I just built an all-in-one tool that we use. The tool allows us to manage content for the Railway website, change log, blog. We can use it to send emails, post on all of our social platforms at the same time, manage the website's media. There's even a mini CRM so that when we're working with like external creators, we can keep track of that. There is task tracking, launch planning because you know you want to coordinate multiple things and when they'll go out. There's a calendar and at the same time there's like comments, realtime editing and it's all built using agents. I would say I felt the breakthrough when GPT6 came out and all of this is running on railway. Everything just auto deploys. And let me essentially now walk you through the principles I use to actually make sure that when I want to add a feature, it's, you know, actually polished and matches the rest of the app and at the same time the principles that you can pull from and apply when building tools of your own. So instead of doing my talk from my boring office, I decided to switch things up and do it outside. It is absolutely beautiful. Right now I'm in Edinburgh, Scotland, and it's just unreal. Like I'm on a bench outside and this is my view. Definitely a 10 out of 10 bench. Now this type of talk for me feels a little bit different than what I'm used to because I essentially will walk you through the journey of me building our own internal tools and the opinions I've developed. But I also understand that the landscape changes very very quickly. So like anything I say might change completely in like the span of months. Who knows? So I don't know. Consider this my disclaimer. Like but the time of recording is fall 2026. It's October. And yeah. So anyway, with that out of the way, uh let's talk about the first point which is texts don't matter. Now, a lot of people say that it doesn't matter what programming language you use, what framework you use. You can just ask your agent to build you anything and build it is able to do it. And while I agree to some extent, what I found is when you're building a tool that you will actually use, when you give the agent a proper codebase with solid abstractions, what ends up happening is whenever you're working, let's say, on a new feature, you end up with a much more consistent result that is similar to what you've already built before. And the reason is like it's very simple. the agent doesn't need to reinvent the same like wheel every time it tries to add a new feature or it doesn't need to introduce new patterns. It will just essentially follow existing patterns. And when it comes to like what you choose, I feel like it kind of doesn't really matter as long as you have a code base that is properly structured. But like my go-to choice today is one tan stack libraries for anything when building on the web. And if you're building anything content related, I would say definitely go with payload. Solid experience, great abstraction. I went down like a big rabbit hole of like comparing CMSS at some point because I don't believe that I should uh build it from scratch even though I can. But again, who knows? Maybe the future will change. But yeah, and that's kind of like the main first item that I kind of ran into. When you use like a lot of SAS products out there that you actually love that you use every day, when you're a user, there's like a lot of things you don't notice, but when you actually try to like replicate an experience, you quickly find out how much care and thought goes into different flows. So like something as simple as oh I want to be able to send an email or to publish something. You can easily do it by having like a good old you know just like server side rendered app with like forms that you submit. But if you try to build something that is going to be used every day that you will reach for a lot you're like oh it shouldn't feel that way. And there are kind of like a bunch of patterns that I found that agents don't typically do unless you explicitly ask them to. And this is my list. So we'll go through them one by one. And the first one is like autosave. I found that if like let's say I'm building some form of document editor, autosave is kind of like a table stakes feature. So rather than manually clicking save to save things, you just ask it to automatically save progress in the background and to make sure that it's like a non-blocking action so that you can let's say if as you're typing you're able to type and then it just automatically saves. And one other kind of like step further that you could do is to also prevent the browser tab from closing if there are unsafe changes. So it's kind of like this these two layers that kind of guarantee that whatever it is that you're working on is just not going to be lost. Now you can also go a step further and to add like real-time collaboration so that you can have like concurrent edits. And again, my agent didn't struggle at all with adding the feature. It was like, I don't know, asking about it, reviewing how it would work, and then once that's done, \>\> just 700 million tokens later, I had real time. So, I would say in general, this is the first thing that I find agents just don't do well from a product experience perspective. Another pattern I found that agents completely forget to implement is optimistic updates. So rather than showing your users a bunch of loading spinner whenever they're taking any action, you essentially show them the success state you know optimistically and in the background you're going to sync whatever change they made. Now if the sync or the operation fails for whatever reason you just roll it back and then tell them like oh the operation work. Now of course you shouldn't blindly have optimistic updates for everything. There are some scenarios where you want to show the user a loading spinner and you're going to wait to check that everything worked properly. But in general, having optimistic updates makes the overall experience feel significantly faster, much snappier, and it will just feel much more instant. So pretty sure you can just ask your agent like, "Hey, I would like to implement optimistic updates where it makes sense. Let's come up with a plan." And it will tell you all the areas where it makes sense to do. Again, it's like it's not difficult for the agent to build it. You just need to ask and know exactly what to ask for. Now, an extension of optimistic updates, in my opinion, is giving users the ability to undo certain actions. Now, for example, if you ask your agent to implement the ability to delete records, what it will typically do is it will give you a delete button. You click it, might show a confirmation dialogue, you hit confirm, and then it will actually do the deletion. But a much nicer experience is actually allowing the user to undo that action. So they hit delete, you immediately remove the item they want to delete from the UI, but you tell them like, hey, you have like a couple of seconds where you could change your mind. And if they don't do anything, that means you actually want to delete a thing. Then you actually implement the operation. Otherwise, if they hit undo, you just bring back the change. So it's kind of like you do the operation in the background as well. It's just kind of a delayed action which kind of ties into the next point which is archiving. You should tell your agent you want the ability to archive records and be able to unarchive them because sometimes you want to hide something from the UI completely or let's say from search results and archiving will be the way to do it and you shouldn't force your user to be like well if you don't want to see this you have to delete it. and a much better experience is just the ability to walk out records. So I think it is a pattern that should definitely exist. Another big one for me is URL state. you should ask your agent to persist in the URL whenever it makes sense of course and it's so useful because whenever you have let's say a list of records and you want the ability to filter or sort them and you just have a bunch of like conditions maintaining these things in the URL makes it trivial for you to give them to someone else and then let's say another team member is just going to be able to see exactly what you want them to see now another small detail that agents don't implement out of the box is infinite scroll I don't want to be clicking on load more over and over and over or like a next page button as I scroll I should just get the data I shouldn't need to click next page and then in the end I'll just see that oh I've reached the end it's a very minor thing but also when you use something every day I think it makes a huge difference now another pattern I found that made the output significantly better is telling the agent explicitly to use existing pages as references when it comes to the UI the data fetching and how it works works and how the thing is overall structured and that made it possible for me to essentially define what good looks like once and then just reuse it for more features. Now to be completely honest sometimes even when you tell the agent like hey use page X as a reference sometimes it just doesn't follow it. I don't know if models like get dumber sometimes but sometimes it does happen. But overall, I would say that my success rate is higher whenever I tell the agent to like, well, use an existing page as a reference because you also just end up with a more consistent experience. So like as you're using your app, you're like, oh, this just matches the other part of the app if they both share like the same concept. So like if two parts of the app are essentially lists of records that you can create update and delete and like list well both of these parts should be pretty much identical. This list kind of brings me to my next point which is whenever you have opinions about something they should be packaged as agent skills and then this way your agent whenever it's building something it will actually follow those skills pretty closely. And as I was building all of our internal tooling, I found myself reaching for three Asian skills. Uh two of them are related to design engineering. So one made it easier to have better UI, better typography, better layouts as well as like better error messages in general. And the second one was a set of design engineering skills that made it easier to just have better animations and other things like that. And then last but not least is the railway Asian skills, of course. So like everything that I built for us internally at railway runs on railway of course like everything. So like buckets, databases, the app itself, the real-time server, everything. And for the agent to effectively work with railway and be able to deploy everything, you just give it the Asian skills and it was just able to do it. And yeah, so like once you have all of your Asian skills and everything, in my opinion, the final step and I think this the most important step is verification. So the agents typically whenever you ask it to build something, it's going to be like, okay, I implemented the feature, build passed, test pass, all good, right? But what I found is when you actually try out what happens, you sometimes end up with just like a very broken experience. So once you have like a verification loop in place, it's like a night and day difference because the agent you can literally see it be like, "Okay, I built this thing. I tried it. It failed. I'm going to fix it." And it just keeps going. And then in the end, it's like, "Okay, I fully tested it." And I felt this breakthrough with computer use once it got really, really good. And now everything every time I want to add a new feature I literally just in the end say well you should verify that the feature works end to end and use it by actually running infrastructure and to test things end to end and the agents are very capable of doing this. You just have to tell them and once you have all those pieces I would say you will end up with solid internal tools that you can build quickly that work properly and work in a consistent way. And that's it. This was my list of principles that I use whenever I'm building any internal tools. Hope you found them useful, but more importantly, that you're inspired to build your own internal tools that feel good, that are polished, and spark joy. And I hope that you too can become your company's SAS layer. And with that, thank you so much for watching and I'll see you in the next