There's a kind of software that doesn't start with a market, a roadmap, or a pitch. It starts with a specific need, on a specific day, in front of a specific problem. Someone needs something that doesn't exist yet, and builds it.
It's usually small. It solves one thing. And more often than not, it's made by the same person who's going to use it.
This isn't new. Spreadsheets with too many tabs, scripts that live in a folder, macros nobody else understands. What's new is how far it can go. With the AI and development tools we have today, the distance between noticing a problem and having something that works has shrunk to an afternoon. That opens a new layer of software, and it's worth looking at it without cheering or mourning. Just trying to understand how it behaves.
#01. Born from a need
Small software attends a real problem in a tailored way. It doesn't try to cover every case; it covers the one that's there. That's why it fits so well: it was made to measure.
Since it's built by whoever lives with the problem, it's understood deeply. It carries the particularities of that context, the shortcuts, the exceptions, the names things have in that corner of the world. Things a product team would take weeks to discover are already inside, because the person building it never had to discover them.
This is where conventional software loses ground. It's built for many, so it has to be one size fits all: it covers the average case and asks everyone else to adapt to it. Small software goes the other way. It solves the concrete problem, the way this person has it, and when the problem changes it can change too, iterating until it fits better. It doesn't compete on reach. It competes on fit.
#02. The user becomes the builder
This is the real paradigm shift. For a long time there was a clear line between who makes software and who uses it, and a whole discipline in between, translating needs into requirements and requirements into interfaces.
With small software that line blurs. The person who uses it is the one who builds it. There's no translation, and with it goes a lot of the noise, but also some of the distance that allowed someone else to ask whether the problem was well posed.
#03. No onboarding
Small software has no onboarding, and it doesn't need one. Its creator already knows how it works, where the button is, what that field with the strange name means.
That's also where its problems start. It still needs to be usable, and everyday use doesn't necessarily produce the best solution to a problem. You get used to things. You stop seeing the friction because you walk around it every day. What comes out of that routine is rarely the best answer, but it's a good first one. And a good first answer is worth a lot.
#04. An artifact, not an answer
Small software carries a hard part that isn't visible at the start: maintenance. Dependencies change, the problem shifts, the person who built it forgets why they did something the way they did. Keeping it alive requires constant updating and, above all, constant understanding.
That's why it often works better as an artifact than as a final solution. A way to solve something today, or to understand a problem better by touching it. Sometimes what it leaves behind isn't the tool itself, but the clarity about what the tool should have been.
#05. When it leaves home
For small software to become a final solution, it needs one of two things: a real commitment from whoever builds it, or turning it into something more collaborative.
Because once it leaves its creator's environment and becomes part of a group, even a small and very niche one, it turns into a responsibility. To maintain it, to take care of it, to teach it, to explain it, to update it, to expand it. The onboarding it never had is suddenly missing. The shortcuts that only made sense to one person now have to make sense to others. What used to be a personal tool becomes, whether we like it or not, a product.
#06. Outside the manual
A lot of this software is born from people who don't necessarily know every good practice of product design or engineering. Some decisions are made by intuition, others by trial and error.
It's also an opportunity. To create things that wouldn't exist otherwise, and to think about problems that would never make it onto anyone's roadmap. Problems too small, too specific, too close to someone's daily work to be seen from far away. Small software brings them to the surface.
#07. More design, more mediocre design
When more people design, there's also more mediocre design. That's not a bad thing. It's a condition we'll have to live with, the same way more people writing never meant that every text was good.
What changes is the weight of the rest. The more there is, the more meaningful design matters: design that knows why it exists, that has a purpose and holds it. Not as a gate to keep people out, but as a direction for those who choose to care.
#08. Cells that talk
There's an interesting layer forming between these pieces. Small software rarely stays alone for long. One tool exports what another reads, a script feeds a dashboard someone else built, a team's helper ends up calling another team's. Small cells, each born from its own need, start talking to each other. Nobody designed that network, and still it works, sometimes better than the integrations that were planned.
That changes the role of everyone around them. Developers, designers, devops, QA, PMs: slowly, all of us become enablers. Less the ones who build every piece, more the ones who make the pieces possible. The ones who provide the APIs, the guardrails, the shared components, the review when it's needed, the place where things can be found. The work moves from making the thing to making the conditions for things to be made.
I don't think small software is the future of all software, at least not for now. Nor is it a threat to the way we build products. Conventional software will keep doing what it does best; it just loses ground on the concrete problems it was never shaped for. It's a new layer, opening up around the AI and development tools we have today, and it's already here. It lives next to everything else, in folders, in teams, in the way people solve their own problems now that they can.
Small software emerges. It's spontaneous, it grows from the bottom up, and no roadmap will produce it on demand. Trying to control it won't work, and neither will ignoring it. What we can do is accept it, understand its patterns, and create the conditions for it to shine the way it should.
That's the key for technology teams today: to become enablers of this new way of building.