Stephan Schmidt - January 25, 2026

I stopped using dependencies and started generating code

Something changed in how I think about software, and it happened recently enough that I’m still working out the implications. I used to add dependencies without thinking twice. Someone already solved this problem? Use their solution. That’s what everyone does, and for good reason - writing code takes time, and time was expensive. But last week I made a different choice, and it surprised me.

I was working on a small tool to migrate Go projects to Rust, and I needed functionality that another library already provided: tracking tasks and requirements. The old me would have added it as a dependency without hesitation. Instead I asked Claude to generate just the slice I needed. The code appeared in minutes, it worked, and it fit my exact use case in a way no library ever quite does. Something about this felt different than normal code generation. I wasn’t using AI to write faster. I was making a different decision entirely - choosing to build rather than borrow, because the economics had shifted underneath me.

For decades the calculation was clear: building was expensive, so you bought. You used dependencies because writing code took time, and time was money. You subscribed to SaaS because a team of specialists could build better software than you could in the same hours. And it was cheaper. That made sense when it was true.

But the cost of building collapsed, and it collapsed fast enough that the old rules stopped working. A developer wrote that a project that would have taken a month now takes a week.¹ He’s not exaggerating. I’ve experienced the same compression in my own work - not on everything, but on enough things that I’ve had to reconsider assumptions I’ve held for thirty years. The calculation that said “just use the existing thing” gives different answers when building costs almost nothing.

I started noticing I was building things I never would have built before: a newsletter tool because the existing options didn’t fit how I work, a small SaaS for managing my coaching clients, a handful of blog utilities, an HTML compressor, a CDN uploader. None of these are products. They’re not side projects I hope will become startups, and they’re not open source contributions waiting for stars. They’re tools with an audience of exactly one person - me - built because AI made building cheap enough that using third party open source tools no longer made sense.

I’ve started calling these audience-of-one apps, and I think they represent something genuinely new in how we relate to software.

Before AI, building a custom tool meant weeks of work. You’d do the cost-benefit calculation and almost always conclude: just use the existing thing, live with its limitations, work around its quirks. The build cost was simply too high to justify for personal use. Now the calculation runs differently. I can describe what I want, iterate quickly, and have something working in an afternoon. Not polished, not something to sell, but something I can use - and that turns out to be enough.

And here’s what surprised me most: the iteration speed is genuinely new, but so is something else that matters even more. Coming back to code six months later used to feel like reading a foreign language. ⊕I once had a period of work where I mostly worked at night into early mornings in the office and then had trouble to understand my code the next day. I stared at that code like ancient hieroglyphs. You’d stare at functions you wrote and wonder what past-you was thinking. Now I can ask the AI to explain what past-me was doing, and suddenly the code makes sense again. The reason custom tools used to rot is that understanding them again was nearly as expensive as writing them fresh. When understanding becomes free, the maintenance burden largely disappears.

So creating is cheap, and maintenance is solved. The two reasons not to build custom tools - the initial investment and the ongoing burden - both collapsed at the same time. I find myself wondering how many subscriptions I’m paying for that I could replace with an afternoon of prompting.

The dependency decision made me realize something broader is happening. It’s not just about building apps. It’s about a different relationship to code itself.

Why did I generate instead of depend? When I thought about it, the reasons multiplied. The generated code does exactly what I need and nothing more. It doesn’t include functionality I’ll never use. It won’t change out from under me when some maintainer decides to refactor. It won’t bring in transitive dependencies I don’t want. It won’t have security vulnerabilities in code paths I never touch. Dependencies are social contracts ⊕We used to call this “Not Invented Here syndrome” and it was considered a vice. The economics made it so. - you’re trusting other people to maintain code you rely on, to keep the API stable, to care about the same things you care about. That contract made sense when writing the code yourself was prohibitive. When it isn’t, the terms of that contract start to look different.

I remember arguing about this in the late 90s. We had debates - also about GPL vs. LGPL in my own open source projects - about static versus dynamic linking, about whether to vendor dependencies or trust the system libraries. First time this hit me big time was with Perl and CPAN. Many, many libraries but most of very low quality if you’ve used them. In Java we got into upgrade hell, and much more so later with Scala - which was a nightmare to upgrade itself, SBT and Scala librsaries. Everything just broke. Depending on other people’s code means depending on other people’s priorities, and schedules, and mistakes. I only want that one bug fix, not that new incompatible API. We just accepted this as the cost of not reinventing everything. Now the cost has changed.

There’s another angle here that I didn’t fully appreciate until someone else pointed it out. Someone wrote about what they call “data jails”² - the way SaaS creates isolated silos that prevent AI from accessing your own data. Your newsletter subscribers live in one tool, your coaching notes in another, your blog analytics somewhere else. Each vendor guards their walls, and your data sits fragmented across a dozen services that don’t talk to each other.

When you build for yourself, there are no walls. Your data lives where you put it, connected however you want, accessible to whatever tools you choose to point at it. This turns out to matter more than I initially thought.

Shopify’s CEO posted about using AI to build personal tools, and the example he gave stuck with me.³ He had MRI scans from a hospital visit sitting on a USB drive - unorganized, different formats, medical filenames that meant nothing to him. He described what he wanted: organize these, convert them to viewable formats, generate an index I can browse. The agent used ImageMagick, wrote scripts, organized files into folders by date and body part, generated an annotated HTML page. One prompt, personal tool, audience of one.

This isn’t experimental anymore. It’s becoming a daily pattern for people who can articulate what they want. And the pool of people who can articulate what they want keeps growing as the tools get better at understanding intent.

Some signals are hard to ignore. Tailwind CSS laid off 75% of their engineering team. The founder wrote⁴: “Tailwind is growing faster than ever and bigger than ever, and our revenue is down close to 80%.” How does that make sense? The framework is more popular than ever, but the business is cratering.

Their docs traffic is down 40% since 2023, and that tells you what’s happening. People generate what they need from Tailwind’s ideas without needing Tailwind itself. A utility CSS framework is exactly the kind of thing AI can produce on demand - it’s well-documented, it follows clear patterns, and it’s been in training data for years. Why pay for documented, maintained classes when you can describe what you want and get the CSS directly? I’m a paying Tailwind customer, but I haven’t used it in a year. AI is great at CSS.

What else lives in this category? CRUD applications. Admin dashboards. Data integrations. Reporting tools. I think about half the apps in the Shopify app store, honestly - little tools that do one thing, charge $29/month, and could be replaced by a prompt - because the users can’t code. ⊕Also that famous ‘is-odd’ npm which has as of today 32M downloads. The entire commodity middle of the SaaS market is software that isn’t doing anything particularly novel, just providing standard functionality wrapped in a subscription. Most of it was never defensible. The only moat was that building it yourself was too expensive. If AI can generate it, and it doesn’t require network effects or aggregated data to be valuable, the subscription model is in trouble. And frankly, a lot of these tools deserved to go away anyway - they were always just rent-seeking on the inconvenience of building things yourself - they hook you and then they increase price year after year after year with your data as hostage (happened to me several times - or the exported data is incomplete and unusable).

The big platforms survive, of course. Anything with network effects survives. Anything requiring aggregated data from many users survives. But the thousands of small SaaS tools doing straightforward things for straightforward needs? I don’t see how they compete against free and custom. Someone predicted that rigid SaaS will become “legacy software” in the AI era. That sounds dramatic, but it might be right.

What about the apps I’m building - will they rot? Will this bite me? My intuition says no, because AI makes maintenance easier too. I can come back to old code, have it explained, make changes, iterate. The usual decay curve of personal software doesn’t apply when understanding becomes free.

But I’ve only been doing this for a year. I don’t actually know what these apps look like after five years of accumulated changes. Maybe the AI that wrote them can also maintain them indefinitely. Maybe there’s some failure mode I haven’t hit yet - some kind of gradual drift or accumulated confusion that doesn’t show up until later. I’m genuinely uncertain, and I think anyone claiming certainty about this is guessing. We’re all guessing. The honest position is to notice what’s working now while remaining curious about what breaks later.

What I do know is that my relationship to software changed. I used to think of tools as things I find or buy. Now I think of them as things I describe. The constraint shifted from “does this exist” to “can I articulate what I want.” That’s a fundamentally different question, and it has fundamentally different answers.

The current AI tools still require someone who can at least read code, debug problems, understand what’s possible. That’s a real limitation, and it means audience-of-one apps are currently limited to people with technical backgrounds. But that bar keeps dropping. If you can prompt, and soon if you can just talk, maybe the audience for audience-of-one apps expands dramatically.

What would it mean if everyone could have software built exactly for them? Not just developers describing what they want, but everyone. The receptionist who needs a specific scheduling tool that matches how her office actually works. The teacher who wants exactly this kind of gradebook with exactly these fields. The small business owner with a workflow that matches no existing product and has been forcing his processes into ill-fitting software for years. ⊕IT departments called this “shadow IT” and fought it for decades. Turns out people just wanted software that actually fit their work.

I don’t know where this ends. But I notice I’m building more than I ever have, for an audience of exactly one. And it keeps working.