The Best Software Solves Small Problems Completely

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."

— Antoine de Saint-Exupéry

The Moment I Almost Leaked a Client's SSN

Last Tuesday, 11:47 PM. I was drafting a market analysis for a client—the kind of late-night hustle that's become normal since starting the MBA and launching Textstone Labs simultaneously.

I had their data open in one window. Claude in another. My fingers were moving faster than my brain.

I was about to paste a spreadsheet into the AI when I caught it: a Social Security number, sitting right there in column D. And next to it, their full legal name. Their home address.

I'd done this dance a hundred times before—manually hunting for sensitive data, redacting it by hand, then trying to remember what I'd changed so I could restore it later. It was tedious. Error-prone. The kind of friction that makes you cut corners at midnight when you're tired.

So I stopped working on the client deliverable. And I built a tool instead.

Forty-eight hours later, Anancy was born—a CLI that masks PII automatically, stores the mapping locally, and unmasks when you need the original back. One command to protect. One command to restore.

Total users: 1. Me.

Around the same time, my reading partner and I kept arguing about which book to read next. We'd both nominate options, forget what we'd already read, accidentally skip books in a series. So I built The C&W Book Club Picker—a Discord bot plus web app that tracks our library, enforces series order, and picks fairly.

Total users: 2.

Combined user base of my entire software portfolio: 3 people.

In a world obsessed with scale, this sounds like a punchline.

Here's why it's not.

The Audience of One

"The artist who aims at perfection in everything achieves it in nothing."

— Eugène Delacroix

Look at Agnes Martin's grids. They don't try to be everything. They don't have features. They don't scale. They simply are—complete within their constraints.

The conventional startup wisdom goes: identify a market, validate the problem, build an MVP, iterate based on feedback, scale.

There's another path. Build for yourself. Solve your own problem completely. Call it done.

This isn't a stepping stone to "real" products. It's a valid end state.

When you build for yourself, you have advantages no amount of user research provides:

You understand the problem. I don't need to interview users about AI privacy concerns—I am the user. I know exactly which data types matter (SSNs, client names, project codenames) and which don't (public company names, generic job titles). I know the workflow because it's my workflow.

You know when it's done. There's no metric to optimize, no engagement chart to inflate. The tool is done when the problem is solved. For Anancy, that meant: I can mask a document, send it to Claude, get a response, and unmask it. End to end. When that worked reliably, it was done.

You can be opinionated. I don't need settings panels for preferences I don't have. Anancy has one way to mask data. The bookclub picker has one set of rules. No customization, no "power user" features, no configuration hell.

If someone else doesn't like my opinions, they can build their own tool.

This pattern isn't new. Git started because Linus Torvalds needed version control for the Linux kernel. Ruby on Rails emerged from DHH's work on Basecamp. Most Unix utilities were built by one person solving one problem.

The pattern is everywhere if you look.

The MVP Trap

"Beware the barrenness of a busy life."

— Socrates

"MVP" has become one of the most abused terms in software.

The original idea was elegant: build the minimum product that's still viable. Ship something small. Learn from real usage. Iterate.

In practice, "MVP" became an excuse for incomplete work. Most MVPs are neither minimum (scope creeps because we're afraid to commit to small) nor viable (corners are cut, bugs are shipped, "we'll fix it later").

The result: a graveyard of half-finished SaaS products that do 17 things poorly instead of one thing well.

There's an alternative.

Small scope. Complete execution.

Anancy does ONE thing: mask PII in text. That's it. It doesn't integrate with Slack. It doesn't have a dashboard. It doesn't sync to the cloud. It masks text, stores the mapping locally, and unmasks when you need it back.

The scope is tiny. But within that scope, it's thorough:

• ● Every pattern I care about is handled
• ● The mapping persists across sessions
• ● The vocabulary system lets me customize how masked data looks
• ● Tests pass
• ● Documentation exists

The Book Club Picker does ONE thing: select the next book fairly. It doesn't track reading progress. It doesn't integrate with Goodreads. It doesn't have AI recommendations. It picks from an eligible pool, enforces series order, and remembers decisions.

That's the scope. Within that scope, it's complete:

• ● The rules are implemented correctly
• ● The UI works on mobile
• ● The state syncs between Discord and web

Not "good enough." Actually done.

What "Complete" Actually Means

"The details are not the details. They make the design."

— Charles Eames

"Complete" doesn't mean "feature-rich."

It means the tool solves the stated problem from start to finish without requiring you to leave and use something else.

The completeness test: Can you run the full workflow inside the tool?

For Anancy:

The cycle is complete. I don't need a separate tool to manage mappings, a database to store them, or a manual process to remember what was masked.

For the Book Club Picker:

I don't need a spreadsheet to track what's eligible. I don't need to remember series order. The tool enforces it.

This is what "complete" means: no workarounds required.

It also means:

• ● Edge cases handled. What if all series are paused? The picker knows. What if someone tries to mask already-masked text? Anancy handles it.
• ● Tests exist. Not "I clicked around and it seemed to work." Actual tests that run and pass.
• ● Documentation exists. Someone (including future-me) can understand what the tool does without reading source code.

None of this requires scale. None of it requires a business model.

It just requires caring about completeness.

The Takeaway

"Have no fear of perfection—you'll never reach it."

— Salvador Dalí

Here's the permission I wish someone had given me earlier:

You can build for yourself. You don't need a market. You don't need validation. You don't need 10 users before it "counts."

You can call it done. If the problem is solved, it's done. You don't have to add features. You don't have to grow it. You can move on.

Small is not a weakness. The world doesn't need another half-finished SaaS with a waitlist and a pitch deck. It might need your weird little tool that solves your weird little problem.

I'm building Textstone Labs while finishing an MBA at Rollins. Time is the scarcest resource I have. That constraint forced small scope—and it turned out to be a gift.

If a kid from the Midwest who bounced through Davenport and Cedar Rapids, stumbled into the Army in 2007, and is now juggling grad school with a consulting practice can ship complete software for an audience of three—imagine what you could build if you stopped waiting for permission to start small.

Like Agnes Martin's grids—nothing extra, nothing missing—the best tools are complete not because they do everything, but because they do their thing entirely.

I built two tools this month for 3 users.

They're done. They work.

That's the whole point.

Part 1 of "The Craft of Small Tools" series.

Textstone Labs — AI implementation for people who build things.