What is Old is New Again!

As I’ve said before, some things are just evergreen. While it’s tempting to say that major paradigm shifts like AI make everything we already know obsolete, that’s just not true.

In my own personal development process, I’ve come to realize that the things I really depend on haven’t changed that much. The details of how Fictivize is built are fundamentally the same as the way my teams built other SaaS sites that I’ve been involved with. Interestingly, there are four key pillars of Fictivize: Open Source, Scripts, CLI and Cloud. Without those four things Fictivize would not have been possible.

Open Source

Like pretty much every other modern software project, Fictivize is based on tons of open source software. It’s truly insane how much great software is just sitting there waiting to be used. From Terraform to Node.js, the entire product sits on an Open Source foundation. Could I have asked Claude to build me a new tool to deploy infrastructure like Terraform? Probably. But why bother? Terraform is already a thing and it’s free. Why wouldn’t I use a tool that is a known quantity? Why solve problems that aren’t directly related to my business? AI doesn’t change any of that math for me. I still consume existing OSS frameworks if they exist. It just makes sense and reduces risk for me.

Scripts

Unexpectedly, scripts are still a really big part of my life. No, I don’t use them to deploy infra, but I do use them for things like running end to end tests or pushing a build to production. Any task that you’re going to perform more than once or twice is a good candidate for scripting. It used to be that building the script was a whole thing and you had to spend time figuring out how Python or your choice of language worked. Now, you can just tell your AI to build the script for you.

I can hear you asking me, so I’ll just call this out. Why wouldn’t I just tell Claude to do the thing that I need to do instead of asking Claude to write a script?

Great question, fictitious audience member.

Because LLMs, which is the technology that Claude is based on, aren't deterministic. They are probabilistic. That is to say, they calculate statistically what the best answer is. If you ask the same question again, you may not get the same answer. If you vary the instruction slightly, you can get wildly different results (yes, Claude proves that the Butterfly Effect is real). Scripts, on the other hand are deterministic. That means that if your script does X then Y then Z, you can be certain that X Y and Z will happen each time you run it. Of course, your script could have bugs, but assuming you’ve got the script nailed down, it will work every time. If you have a very repetitive task like deploying code to production, you don’t want variability. You want certainty.
Thus, scripts.

CLI

As I’ve documented before, I’ve had an on-again off-again relationships with MCP. In theory, Claude is supposed to use MCP servers when it wants to talk to other systems like AWS or Jira. In practice, the MCP infrastructure can be clunky and hard to debug. At first, I refused to use them at all and just told Claude to talk to the API directly. That works, but you burn an insane number of tokens figuring out the API every time you want to do something. See scripting above. So, some things just got scripted, which is fine.

But what if I want to do something like, “Claude, figure out why my GitHub Actions job failed.” You can’t script that. It’s different every time. You could use a MCP server, but then you have to find the silly thing, install it, etc.. But, if you are writing code, you probably have the GH CLI already on your machine. Heck, if you don’t, you should, so go install it. That means you can just say, “Claude use GH CLI to figure out why the Actions job failed.” And, it turns out, Claude is perfectly capable of doing that. Worst case you say, “Claude use the GH CLI help function to figure out how to do this.” Because the help text was written for humans, Claude can read it and take action. Now you and Claude are using the same tool to talk to GitHub. Very nice.

Cloud

Of course, all my SaaS projects are hosted on the cloud. They have been for some time. I happen to use AWS because I know it the best. But, regardless of which cloud you use, cloud is the cheat code that allows you to deploy production grade applications with a very small team. Even if you are super sharp and have been doing this for years, running your site completely on your own is a big task. Simple things like managing user login or supporting the latest Google API change are just a pain in the butt. You also have to worry about scaling and security. For a small project like Fictivize, it’s actually pretty cheap to just consume these services directly from AWS. I use Amplify, Cognito, CloudFront, Lambda and other AWS PaaS features because that way I can just worry about my app and not spend any time managing a K8s cluster or building my own Google login integration. It’s low value work for me, so why not let AWS do it?

Of course, as the site scales, some of these things can get very expensive. But that’s a normal part of growing a site. Every SaaS project I’ve ever been involved with had elements that didn’t really scale. We took shortcuts to get to market and then as the site grew, we had to go back and re-do those things that weren’t really ready for the scale we were running. AI doesn’t change that. It actually makes “do things that don’t scale” more realistic because AI can re-factor the service way faster than a human can. Want to get rid of Cognito? That’s a day’s work for Claude.