This whole conversation is also not new. The “build versus buy” topic is one every tech company asks itself at least once. AI just makes the build side feel a lot more tempting. This brings me to my far-from-comprehensive, highly debatable Build vs. Buy table:

Even those in the “Build” camp will be bought

I also don’t believe everything here in my “Build” camp will definitely be built. These companies are going to try hard to find ways to keep their customers. And even if something would be possible to build, it might still make sense not to. For instance, penetration testing would be straightforward enough to do on your own. But for SOC2 and other compliance processes, you may need to show certification of completion. A homegrown test might not “pass.” With a website builder, if the website is relatively small, sure. But if it’s large, you probably don’t want to worry about bugs, SEO, templates, analytics, and all the other things that come with maintaining it. For a sales enablement tool, if you’re using it externally with customers, then you’re probably going to want to stick with it. But if you’re truly only using it as the source of truth for your collateral, AI could probably sub in.

Systems of record feel different

In terms of “Buy,” there’s definitely a theme around systems of record. I’m closest to Salesforce, and I have to say: I don’t think it’s going anywhere. I am very familiar with how to build things in Salesforce and all the dials and knobs on the backend. I think there is so much more there than people realize. To rebuild Salesforce would require thinking through and accounting for so many requirements: object and field customizations, permissions, workflows, integrations, admin controls, change history, and all the random edge cases every company accumulates over time. Obviously it’s possible. I worked at Google, and they did roll their own. While I was there they called it GRM, short for Google Relationship Manager. There was a whole team dedicated to developing and supporting the tool, and even then, it still wasn’t perfect. That’s what people underestimate: the initial build is only one part of the work.

I do think an upstart may steal share from Salesforce, but even that won’t happen overnight. It has to have the table-stakes functionality and flexibility that Salesforce has while getting everyone excited about its AI-forwardness. For instance, Gong recorded meeting transcripts before, but Granola came out and made a lot of people realize there could be a lighter, more AI-native version.

My build-vs-buy consideration set

Obviously, the classic build-vs-buy question is partly about whether something is strategic enough to own. I still think that matters. But with AI making the initial build feel easier, I think the more interesting question is whether you actually should own all the software you’ve been buying.

So I’ve distilled what I think the principles are for deciding whether something should be bought or built. I’ve come up with five dimensions. If it passes all five, then sure: build it.

Complexity: If it would take a lot of time and technical know-how to get all the requirements and details right, then buy. Otherwise, if it’s relatively simple to build and maintain, build.

Criticality: If it creates real risk when it breaks, then buy. If downtime or bugs would be annoying but manageable, building may be fine.

Permissions: If you don’t need to manage user access levels, great. Build. If you need one or two role types, maybe you can still handle it. But if you need multiple permission levels, then buy.

Integrations: If there are no integrations needed, great. Build. If the desired integration has an open MCP or an API, okay, maybe build. If the tool requires an integration that involves business development or is deeply tied into other business-critical systems, just buy.

Credibility: If you need an external certification, audit trail, or third-party stamp of approval, then buy. A homegrown version may work internally, but it may not be enough externally.

So, will today’s software companies become dinosaurs?

I wouldn’t start planning a dinosaur museum.

I think companies will build more of the lightweight, internal, low-risk workflows they used to buy. And they will still buy the systems where reliability, permissions, integrations, compliance, and maintenance matter.

The build-vs-buy question is still going strong. AI just made the answer more interesting.

But for me, it might as well have been.

I vaguely remember stumbling upon it when trying to solve a problem and seeing someone on a forum suggest it as the solution. But I didn’t know how to write the actual scripts, and it felt like it was simply not built for people like me.

Until now.

I learned last week that with AI, I can describe what I want automated, and ChatGPT can build the code for me. It writes the script, explains how to implement it, and helps me troubleshoot it.

And to be clear: it did need a few iterations.

At least for me, the code was never perfect on the first try. I would run it, get an error or check the output against what I expected, and then bring the issue back to ChatGPT. It became a back-and-forth process: describe the goal, test the script, find the problem, refine the script, and test again.

I just had to know how to recognize when something wasn’t working. Being a good QA tester and being detail-oriented is key.

To hopefully inspire you, I wanted to share two Google Apps Script automations I recently built, what I learned from each one, and why I think this kind of lightweight automation is suddenly much more accessible.

First, a quick overview

The general process looks like this:

1. Go to Google Apps Script at script.google.com and create a new project.

2. Paste in the code that AI gives you. Clear out the default function myfunction() {} code first.

3. Save the script with Command + S.

4. Toggle to the main function and click “Run”. If you don’t know which one is the main one, AI can tell you. While there may be several functions in the code, you generally only need to manually run the setup or “run” function once.

5. Approve the permissions. You may have to click through some discouraging pop-ups.

6. If you also want your script to run on a schedule, you’ll also need to set up a trigger either by running an install function or clicking on the Triggers icon in the left-hand menu bar and setting it up manually.

Once you finish all these steps, you should be all set. Don’t be surprised when you see your Apps Script show up in your Google Drive.

Automation #1: Auto-deleting files from Google Drive

Sometimes I create a document, sheet, or file by accident and immediately know I do not need it.

When you are inside a Google Doc or Sheet, there is not a simple one-click “delete this file” button. So for years, my workaround has been to rename the file something like “Delete” or “Delete me” and delete it later when I see it sitting in my Drive.

I also use IMPORTRANGE in Google Sheets a lot. When you use this function, it automatically saves the raw file to your Google Drive. It’s unavoidable. So over time, my Drive accumulates a bunch of clutter.

Thus, I wanted a script that would automatically look for files with names like “Delete,” “Delete me,” or common names of files that I typically import, and move them to trash.

The first version seemed like it was working. Then, all of a sudden, it failed.

I pasted the error back into ChatGPT, and it suggested that the script might be trying to search through too many files and timing out.

That made sense. Most of the files I wanted to delete were not buried in a folder; they were sitting in the root of my Google Drive. So I told ChatGPT to update the script to only look there. That solved the problem, and I’m happy to retire my periodic Google Drive “spring cleaning” routine.

Automation #2: Scheduling a time to walk my dog each day

The second automation had to do with my calendar.

I wanted a script that would schedule time to walk my dog, Fred, on days when I would otherwise forget to protect the time.

Here were my initial requirements:

• Run automatically every Thursday around 9 a.m. using a time-based trigger.

• Schedule a 30-minute “🐾 Walk Fred” event on my Temp calendar for the upcoming Tuesday, Wednesday, and Friday.

• Randomly pick event times between 10 a.m. and 5 p.m. ET.

• Avoid conflicts with events on both my work calendar and personal calendar.

• Skip the day entirely if I appear to be out of office or on a company holiday, based on keywords like “OOO,” “vacation,” “PTO,” or “holiday” in event titles or descriptions.

ChatGPT also suggested one additional requirement:

• If no free slot exists between 10 a.m. and 5 p.m., fall back to 8 a.m. ET.

That was a good suggestion, so I added it.

Then, after testing the script a few times, I’d find another preference I had not thought to mention.

For example, I did not want the event to start at some random time like 10:07. I also did not really want the walk dropped randomly into the middle of an open slot. I wanted it to abut existing meetings, so it would create a cleaner block on my calendar instead of fragmenting my day. And I realized my calendar had declined events that were still showing up and blocking the script from scheduling time.

So I added:

• Start times should always snap to :00, :15, :30, or :45.

• Prefer slots adjacent to existing events, with no gap between meetings.

• If no adjacent slot is available, fall back to a random available slot.

• Declined events should be ignored.

• Tentative or unresponded events should still be treated as conflicts.

Without all the extra logic, I’m not sure this automation would have been any better than what I had already been doing manually each week. But now I feel confident that I can take this off my plate.

Final thought

This was seriously so easy. I can’t believe I went 10+ years without using it before. At this point, the real limitation is not the tooling. It’s my ability to think of more good use cases.

Hi, I’m [your full name]. I used to be a [first job], but I somehow landed a job at Pinterest as a [dream job]. I manage the sales team that works on the [a brand you love] business. Did you know they sell [noun]? Their results are [adjective]. At this rate, I think we should open an office near their headquarters in [where you grew up]. The office would be [adjective]. We’d stock the kitchen with [your favorite food], let employees bring their [noun] to work, ban all [pet peeves], and go [verb-ing] every Thursday. The team will definitely blow their goals out of the [noun]. And when they do, I’m taking everyone on a trip to [the last place you went on vacation].

It worked well because people could be funny without having to think too hard, and the final read-alouds gave everyone an easy way to share a little about themselves.

I’ve now turned it into a GPT, so people can just plug in their answers and get the full paragraph back, ready to read. It’s free in the GPT Store in case you want to use it for your own team.

In particular, there are two functions I still think are underused, especially for anyone who wants to create lightweight workflows:

• IMPORTRANGE

• QUERY

Let me share a recent example of why these functions are so useful and how nicely they can work together.

A real-life use case

Our Associate General Counsel keeps a running list of what they’re working on in a Google Sheet, with items grouped by category.

Recently, our Partnerships team wanted visibility into that queue so they could check in on the status of their deals without constantly pinging Legal.

The QUERY function is basically SQL for Sheets. You write a SELECT statement over a range of cells.

On a separate tab, I filtered the master list down to just the Partnerships-related rows:

=QUERY('Full List'!A:I,"SELECT A,B,C,D,E,F,I WHERE A = 'Contract: Partner' ORDER BY D")

No surprise: if you try to include a column in the SELECT statement that’s not in the provided range, the formula errors out.

At that point, I could have simply shared the AGC’s sheet and restricted access to the “Full List” tab. But that doc had other tabs, and it’s cleaner and safer to keep the “viewer” version separate.

That’s where IMPORTRANGE comes in. It pulls data from one Google Sheet into another automatically.

In a brand-new Google Sheet, I imported the filtered tab:

=IMPORTRANGE("https://docs.google.com/spreadsheets/XX","Partnerships!A1:J200")

The result was a dedicated sheet the Partnerships team could bookmark and check anytime for the current status, with no extra work needed from Legal.

Note: when you use IMPORTRANGE, Google Sheets will return #REF! and prompt you to “Allow access.” That’s normal.

What AI suggested

I was happy to find that AI (Claude, in this case) landed on the same solution I did.

It first suggested creating a Partnerships view using QUERY or FILTER. Once I explained that the source spreadsheet had other tabs I didn’t want exposed, it added the next step: use IMPORTRANGE to pull that filtered view into a brand-new sheet.

I hadn’t discussed this exact scenario with Claude beforehand, so this wasn’t it just parroting my own answer back to me.

A quick note on Gemini in Sheets

Since Gemini is built into Google Sheets, I’m really curious to see where this goes.

I’ve been testing it out, and it’s pretty cool that you can ask it to do things you previously would have had to do manually. For example, I asked it to conditionally format a column, and it did.

But it’s not fully there yet. I also asked: “Can you make a tab isolating just the Contract: Partner values?” The result was nonsensical.

Gemini will surely make workflows like this easier to build in the future. Until then, knowing a few formulas is still a real advantage.

I’ve owned terriblyorganized.com and suddenlyrevops.com for years, always intending to publish under them. But now, Suddenly Automated is the one that fits. It captures exactly what I’m trying to do: take the stuff I’ve learned and revisit it with an eye toward automation.

A lot of this isn’t on the internet. I’ve searched. Many times. And when the answer wasn’t there, I’d end up going internal: asking a colleague, thinking back to what a previous company did, or building the solution from scratch.

AI makes this more worth documenting, not less. In theory, it should be able to answer the exact questions I used to hunt for. In practice, it still needs structure: clear processes, good examples, and a source of truth. So this Substack is me building a library of how I work: the approaches, workflows, workarounds, and the “gotchas” that get learned, forgotten, and re-learned on repeat, so both humans and AI can use them. And while part of this is about creating a reference for AI, part of it is about pressure-testing what I’ve always done and asking: is there a better way now?

I also genuinely love this stuff. I like documentation. I like making things repeatable and efficient. I like building workflows that don’t collapse the second one person goes on vacation. One reference-check question I always come back to is: “What did <NAME> do at your company that still exists today?” That’s the kind of impact I want to have.

Most posts will be about RevOps. Some will fall outside of it. But all will be about the ways I’ve tried to organize or automate the chaos around me.

Good stuff ahead.