You Can Build Anything. But Should You?

Good morning from the AI in BC Education Leadership Exchange. I’m excited to meet colleagues and learn about the innovations and risks they are seeing.

This has been the most fun I’ve had with software in 20 years.

In my last post, I wrote about my journey with AI and how AI coding agents are changing both how I build things at Plaid and what I think I should focus on in my analytics teaching.

It feels like I can build anything I can dream up. Thanks to AI agents, I can.

But just because I can build anything, should I?

For most of the last 20 or 30 years, software had a built-in constraint: it was expensive to create. An idea had to be valuable enough to justify the time required to define requirements, write code, test it, deploy it, support it and maintain it. A lot of ideas never made it past that test.

AI coding agents are rapidly removing that constraint. Something that might once have taken days or weeks can sometimes be mocked up in an hour. Something that wasn’t worth automating because writing the code would take longer than doing the work manually suddenly might be. Here’s the thing: 

Cost wasn’t just preventing us from building good ideas. It was preventing us from building bad ones too. 

Disposable Software

I first heard the term “disposable software” from my former classmate Jayme Cochrane in his Web Summit presentation in June.

There are so many problems that could benefit from software but don’t require production-grade software. Maybe it runs locally. Maybe it serves one person. Maybe it doesn’t communicate with the internet. Maybe it only needs to exist for an afternoon.

Historically, many of these problems weren’t worth solving with software because the cost of creating it was too high.

Things look different now.

Back when I worked at UBC as an Institutional Research analyst, we were inundated with spreadsheet templates from external organizations: government, accreditors, consortia, and many others. We usually had the right data, but never in the format the spreadsheet demanded.

Getting our data into the expected format could easily take four hours. A reasonable automation might have taken me 6–10 hours to develop, so it wasn’t worth it for an annual or one-off request.

Now? An AI tool can create a good-enough automation in 20 minutes, often including tests to make sure the data returns expected results. And importantly, this can result in deterministic Python code doing the transformation, rather than an LLM interpreting the data each time.

I might never use that software again. But it took 20 minutes of my life and made my life easier.

Sometimes You Need to Build the Idea

Sometimes you don’t know whether an idea is any good until you can interact with it.

I’ve seen this with project and product managers. Explaining an idea through requirements documents, diagrams and PowerPoint mockups can be surprisingly difficult. Now, someone with relatively little software development experience can build a working version of what they’re imagining.

It doesn’t need real data, proper authentication or the ability to scale. The buttons just need to work well enough that someone else can understand the idea.

I do this too. Recently, I had an idea for a completely different way of setting enrolment targets in Plaid Forecast. There weren’t any good models in the market to emulate, so I started experimenting with a coding agent using synthetic data to see if what I was imagining was even possible.

It took some effort, but I built something that lets you set specific targets at any level of the hierarchy, while the system helps populate whatever you haven’t explicitly set.

Once I could interact with it, I started changing the idea. Things that made sense in my head didn’t work as well on screen. Other possibilities only became obvious once I could actually use them.

Eventually, that disposable prototype became the basis for a real feature we’re building into Plaid Forecast.

But that wasn’t the goal. It was allowed to be wrong or ugly, and if the idea didn’t work, I could simply throw it away.

What Happens If It Works?

The ability to create software is spreading far beyond the people who traditionally created it, which I mostly think is a good thing.

An analyst can automate an annoying process. A project manager can make an idea tangible. Someone can build a visualization for one meeting and throw it away afterwards.

But what happens when the little tool is really useful?

You build it, show it to a colleague, and suddenly five people are using it. Three months later, an entire department depends on it. Confidential data is getting inserted beyond anything you ever imagined.

Then you leave the institution. Maybe you get a new job or win the lottery.

There’s likely no plan for maintaining it, a lot of the vision was in your head, and IT may not even know it exists.

When we’re building disposable software, I think it’s important to keep two questions in mind:

What happens if it fails? What happens if it succeeds?

Cheap to Build Isn’t Free to Have

AI is making software cheaper to create, but it isn’t making all the other costs disappear. Software still needs maintenance, support, updated dependencies, security reviews and awareness of changing data definitions.

And once people depend on it, it becomes hard to turn off.

The use case matters. An app handling student data, perhaps scoring their likelihood of persistence, needs careful oversight to make sure it’s doing what it should and that confidential data isn’t leaving the institution. Some code that generates a spreadsheet in a specific format has much lower stakes.

As software gets easier to create, knowing the difference between those two cases matters more.

We Need to Get Better at Throwing Things Away

For years, organizations have had processes designed around deciding what software they’re willing to build.

I wonder whether we now need better processes for deciding what software we’re willing to keep.

Disposable software only works as a concept if we’re comfortable disposing of it once its purpose is used up.

Judgment Becomes the Constraint

I think this all circles back to how much human judgment matters. Should we build this at all? Should we keep it? How big could this idea grow, and how will we handle that?

I want analysts to build little tools that save them four hours of tedious work. I want project managers to make interactive prototypes instead of writing 30-page requirements documents. I want people to experiment with ideas that previously never would have survived a cost-benefit analysis.

I certainly intend to keep doing it myself. But the ability to build more software means we need to get much better at understanding where the value lies.

In the end, our ability to answer one question matters much more than it used to:

Stay tuned: next blog I’m going to talk about my journey in people analytics.