Please… Enough with the Sloppy, One-Shot SaaS Replacements

People have been saying that SaaS 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 one-shotted

and software I would actually use.

Software that sparks joy, that is polished, that feels good.

And I actually went on a journey to replace a bunch of SaaS providers we were 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 external creators, we can keep track of that.

There is task tracking, launch planning,

because you wanna coordinate multiple things

and when they'll go out, there's a calendar.

and at the same time there's like comments real-time 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 text acts 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 go do anything and those are 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 code base 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 my go-to choice today is, one, TanStack 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 a big rabbit hole of comparing CMSs at some point because I don't believe that I should 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 they 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 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 a good old server-side rendered app with 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 states 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, 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 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 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 didn't 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 they'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 dialog 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 could 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.

Any much better experience is just the ability to archive 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 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 lobe 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 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 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 agent skills.

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 agent 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 Railway agent skills and it was just able to do it.

And yeah, so like once you have all of your agent skills and everything,

in my opinion, the final step, and I think 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 pass, 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 nine 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 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 SaaS layer.

And with that, thank you so much for watching, and I'll see you in the next one.