Please… Enough with the Sloppy, One-Shot SaaS Replacements — Mahmoud Abdelwahab, Railway

Sending an email or publishing a post is only part of replacing a marketing tool. The replacement also has to feel good when someone opens it every day. Mahmoud Abdelwahab opens with that gap: agents can produce working software in one shot, while the software people want to use depends on care that a feature request may never specify.

At Railway, his replacement is an all-in-one internal marketing app. It manages website content, the changelog and blog; sends email; posts across social platforms; and manages website media. A small CRM tracks external creators. Task tracking, launch planning and a calendar coordinate what goes out and when. Comments and real-time editing support the people doing that work together. Agents built the app, and Railway runs it with automatic deployments.

Recorded from an outdoor bench in Edinburgh in October 2026—a “ten out of ten bench”—this is a set of opinions earned while building that tool. Abdelwahab explicitly leaves room for those opinions to change as agents improve. The useful question is immediate: what must you ask for to turn a functioning internal app into a consistent, polished place to work?

“Tech stacks don’t matter” needs a qualification. An agent may be able to work in many languages and frameworks, but the structure of the codebase still affects what it produces. Solid abstractions give a new feature an existing way to fetch data, organize code and present behavior. Without those patterns, each feature gives the agent another opportunity to invent a different solution to the same problem.

Abdelwahab’s preferences are TanStack libraries for web development and Payload for content-related work. The reason for choosing a CMS is practical: being able to build one from scratch does not make that the best use of effort. Established abstractions provide a starting point the agent can reuse. His broader recommendation is a properly structured codebase, rather than a claim that these particular libraries are mandatory.

The same distinction appears in the product. A server-rendered page with a submitted form can send an email or publish content. It satisfies the basic operation. Recreating a favorite SaaS product exposes the smaller decisions that make repeated use pleasant, and Abdelwahab finds that agents often leave those decisions out unless they are requested explicitly.

A document editor makes the first missing behavior obvious. Requiring a Save click puts responsibility for preserving progress on the writer. Autosave moves that work into the background, but it also needs an interaction requirement: saving must be non-blocking. The writer should keep typing while the app saves, rather than waiting for each operation to finish.

A second layer guards against closing the browser tab while changes remain unsaved. These mechanisms address different moments: background saving preserves progress during work, while the close guard intervenes when the user tries to leave before saving finishes. They reduce opportunities to lose edits; the talk does not establish a guarantee against every browser, network or storage failure.

Real-time collaboration extends the editor to concurrent edits. In Abdelwahab’s experience, the agent could add it after a discussion and review of how it would work. His joke about “seven hundred million tokens later” preserves some of the effort behind that success. The recording does not explain a conflict-resolution algorithm or synchronization protocol, so the transferable lesson here is to specify collaborative behavior explicitly, rather than to copy an implementation.

Optimistic updates change when the interface acknowledges an action. Instead of showing a loading spinner until the operation completes, the app immediately displays the expected success state and synchronizes the change in the background. If synchronization fails, it rolls the interface back and tells the user the operation did not work. The fast path and the recovery path belong to the same feature.

That makes an action feel faster without claiming that the underlying operation finishes faster. It also requires judgment. Some actions should retain a loading state until success is confirmed. Abdelwahab recommends asking the agent to plan where optimistic updates make sense, rather than applying them indiscriminately. Knowing to request the behavior is part of building the product.

A request to delete records often produces a Delete button, perhaps a confirmation dialog, and then deletion. Undo changes the experience. Clicking Delete immediately removes the record from the interface, while a short window lets the user change their mind. If they choose Undo, the record returns. If they do nothing, the app performs the deletion after the window expires.

When does deletion actually happen? The branch below separates the immediate visual response from the delayed operation. Both outcomes begin with the item disappearing, but only the expired undo window leads to deletion. This is a specific timing decision: the implementation described delays the operation, so Undo can restore the item before that operation occurs.

Archiving handles a different intent: someone wants an item out of the interface or search results without losing the ability to bring it back later. Archive and Unarchive give that intent its own operations. A short undo window helps with an immediate change of mind; archiving provides a reversible way to keep a record out of everyday view.

Lists acquire useful context through filters, sort order and other conditions. Keeping that state in the URL lets someone share the configured view with a teammate. The recipient can open the intended selection directly, rather than reconstructing the sender’s filtering and sorting choices. The URL carries the view’s settings.

Infinite scroll removes another repeated interaction. As the user scrolls, the app loads more records instead of requiring another Load More or Next Page click. At the end, it indicates that there is no more data. This is Abdelwahab’s preference for a tool used every day: remove the small navigation task that otherwise repeats throughout the work.

Once a page works well, it can become a concrete reference for the next feature. Ask the agent to follow its UI, data fetching and overall structure. Two areas that both list, create, update and delete records should offer a consistent experience. A reference page gives the agent a local example of what that means, extending the earlier idea of reusable code patterns into reusable product decisions.

References improve consistency in Abdelwahab’s experience, but they do not ensure compliance: sometimes the agent ignores the named page. Recurring opinions can also be packaged as agent skills, so the agent has guidance to apply across features. Reference pages supply examples; skills carry reusable instructions.

His internal tooling draws on three kinds of guidance:

• UI and written feedback. One skill covers interface quality, typography, layouts and better error messages.
• Motion. Another set of design engineering skills guides animations and related interaction details.
• Deployment. Railway agent skills help the agent work with and deploy the infrastructure running the tool: buckets, databases, the application and the real-time server.

A passing build and passing tests can still accompany a broken experience. That is why verification is the final—and, for Abdelwahab, most important—step. The agent needs to try the feature, observe what fails and fix it. Computer use made that form of verification substantially more useful in his workflow because the agent could exercise the application rather than stop at an implementation report.

The instruction includes the environment: run the infrastructure and verify the feature end to end. This asks the agent to test the feature in operation, where its pieces must work together. It is the practical check on all the earlier requests: the desired interaction has to survive actual use, not merely exist somewhere in the code.

The destination is an internal tool that works consistently and feels good enough to reach for. Abdelwahab closes by inviting builders to become their company’s “SaaS layer.” In this account, that role includes choosing the small behaviors, carrying them across the app and checking the running result—the work that turns generated features into something colleagues want to use.