Little Software

The Rise of Little Software

A few weeks ago I got annoyed by a tiny workflow tax.

After a day of meetings my notes folder looked like chaos: random titles, half-finished bullets, action items buried in messy notes. By Friday, finding one decision from Tuesday felt like digital archaeology.

Old me would have shrugged and lived with it. Building software for this would have been ridiculous.

So I opened the Codex app and asked it to scaffold a local script.

It scans my notes directory, sends filenames plus short snippets to OpenAI for organization suggestions, then applies the changes locally: rename files, move them into folders, and generate a daily recap of decisions and follow-ups.

No roadmap. No sprint ticket. No architecture ceremony. Just a tiny piece of software that quietly did one job well. That was the moment it clicked:

we are entering the era of little software.

Little software is small, focused code written to solve one sharp problem for one person or one team.

Big software tries to serve millions of users. Little software serves exactly one.

The kind you build because something broke your patience on a random Tuesday.

The Idea-to-Software Gap

For a long time, software had a minimum weight class.

Even a small idea came with a long receipt: learn enough of a language to be dangerous, pick a framework and hope it survives the next six months, fight dependencies, figure out hosting, wrangle secrets, debug runtime weirdness at 11:47 PM, then deploy and pray.

If you are an engineer, this pattern is normal. If you are not, it is a brick wall.

So most people did what people always do with friction: copy and paste between tabs, maintain giant checklists, and repeat the same workflow every week.

The idea-to-software gap was huge, so good ideas died in the gap.

What LLMs Actually Changed

LLMs did not just make coding faster. They changed the economics.

The cost of building small tools dropped below the cost of living with annoying workflows.

You still need judgment, taste, and testing. But the loop is now short enough that more people ship fixes instead of tolerating pain.

What Little Software Looks Like

Little software is usually not trying to serve millions of users. It handles one sharp pain point for one person or one team.

It looks like this:

• a local notes organizer that cleans meeting notes and builds daily recaps
• a script that cleans ugly CSV exports before finance touches them
• a file renamer that fixes 400 assets in one shot
• a script that converts screenshots into docs-ready markdown
• a dashboard used by one team, for one workflow, for one quarter

Common pattern: one user, one painful task, one afternoon to build.

That is not a bug in the model. That is the model.

A Real Example: Tiny Tool, Real Value

Here is the shape of the script I mentioned earlier. The whole thing is basically this:

import { listNotes, readPreview, applyPlan } from "./fs-notes";
import { organizeNotes } from "./openai-client";
import { writeDailyRecap } from "./recap";
 
async function run() {
  const files = await listNotes("~/Notes/Meetings");
  const previews = await Promise.all(files.map(readPreview));
  const plan = await organizeNotes(previews);
 
  await applyPlan(plan); // rename/move/tag local files
  await writeDailyRecap(plan, "~/Notes/_recaps/today.md");
}
 
run().catch((err) => {
  console.error("notes-autopilot failed", err);
  process.exit(1);
});

Not impressive as a product. Very impressive as a Tuesday fix.

That script gave me searchable notes, cleaner follow-ups, and fewer dropped action items. Tiny code, measurable impact.

That pattern is showing up everywhere: small, local tools solving narrow problems that used to be too annoying to automate.

Why Engineers Should Care

If you are a software engineer, it is tempting to dismiss this as toy software. I think that misses the point. This is one of the first waves of software democratization that actually ships real code, not boxed-in templates.

LLMs let people move through a ladder:

Prompting -> Editing -> Understanding -> Building

That ladder matters. The person writing a five-line script today can be shipping internal apps next year. Most of us got into engineering through tiny wins exactly like that: small programs, small confidence boosts, then bigger bets.

The bigger shift underneath all of this is mindset. When a workflow breaks, more people now think, "I can probably build a fix." That turns passive software consumers into active builders, and once a team starts behaving that way, the compounding effect is hard to overstate.

Guardrails for Little Software

If you want little software without little disasters, use lightweight guardrails:

• keep scope narrow and explicit
• put secrets in proper env management, not in the script
• add a --dry-run mode before any rename, move, or delete action
• write one happy-path test before sharing with a team

Think of this as good workshop hygiene for software.

You do not need enterprise bureaucracy for every script. You do need enough discipline that future-you can trust it and run it before morning coffee.

Final Take

The promise here is not AI replacing programmers. It is millions more people writing small, useful software for their own workflows.

Most of these tools will never become products. They will never raise funding, launch on Product Hunt, or get a logo. But they will quietly remove thousands of tiny workflow frustrations from everyday work.

And that might be the most important kind of software there is.