The ability to build software is spreading inside organizations, beyond professional software teams. Recent publications have started to put words to some of the patterns I have also been observing in the field. Together, they suggest that the interesting question is becoming less whether people can build software for themselves, and more what this practice generates inside an organization. (View Highlight)
“Personal software is not necessarily an early stage of another kind of software. It has different success criteria.” (View Highlight)
Its value often comes precisely from preserving some of its original characteristics: built for immediacy, finished when it fits, human in scale. The natural trajectory of personal software is therefore not necessarily from small experiment to enterprise application. (View Highlight)
This is different from much of the logic of commercial and enterprise software. There, a successful solution tends to be generalized so that the same product can serve progressively more users and situations. Personal software makes another possibility economically plausible: many narrower pieces of software, each adapted to the work of the people using them. (View Highlight)
One example from a recent Harvard Business Review article “Turn Vibe-Coded Prototypes Into Tools Your Company Can Actually Use”. At a Swiss enterprise software company of around 1,200 employees, teams have been using generative AI to replace spreadsheets and small human-resources modules. The tools are deliberately kept narrow: one job, one team, without a growing list of features. The people building them are also the people using them, which means that knowledge of both the problem and the software remains close to where a change or repair would be needed. Almost two years later, the tools are still in regular use. (View Highlight)
Keeping a tool small does not mean that its usefulness cannot spread. Another team may recognize the same pattern and build something appropriate to its own context. A successful tool can become an example, a method, or a starting point without necessarily becoming shared code or shared infrastructure. (View Highlight)
Once personal software is understood as a practice, another question appears: how do people become better at it? (View Highlight)
AI makes it possible for someone with relatively little software-development experience to get surprisingly far. But being able to make something work does not mean that the person already knows what they will need if the tool persists. They may not yet recognize architectural constraints, dependencies, maintenance costs, or simply the practices that make a growing piece of software easier to manage. (View Highlight)
The Harvard Business Review authors describe this as a problem of myopia. The issue is not that non-technical people may not yet see some of the consequences of the choices they are making. I have started to notice an interesting role for people with more technical experience in mitigating this myopia. I think of one recurring transition as the Git moment. (View Highlight)
Someone begins with a problem from their own work. The first solution may involve a spreadsheet. Later, the spreadsheet becomes limiting and someone introduces a simple database such as SQLite. With AI assistance, the person starts producing code and goes through several successful iterations. Eventually, a more experienced colleague suggests putting the project into a code repository. (View Highlight)
The repository itself is not the important part. What interests me is how the transition happens. The maker is introduced, just when it becomes useful, to a practice that software developers consider ordinary: keeping versions, being able to recover earlier states, understanding what changed, and eventually collaborating around the same code. (View Highlight)
The path resembles a form of apprenticeship. The person does not begin by learning all the constraints and conventions of software engineering. They build something they need, encounter a new limitation, and acquire another practice at the point when that practice becomes meaningful. (View Highlight)
I have seen similar transitions with databases, repositories, deployment, and other parts of the development environment. This suggests that technical people retain an important role in personal software, although perhaps not always the role they had before. (View Highlight)
Part of that role is to establish a basic environment in which others can get started safely. Another part is to help makers see what they cannot yet see: when a spreadsheet should become a database, when code needs version control, when an integration introduces an important dependency, or when a locally useful tool could be made available to others. (View Highlight)
When personal software develops as a distributed practice, technical expertise also becomes more distributed. Rather than a simple distinction between developers and non-developers, different levels of proficiency begin to appear among the people making things. (View Highlight)
Some personal software will become important enough, interconnected enough, or widely used enough that it begins to require professional engineering. The transition is not always smooth. The authors of the HBR article describe this as the deployment gap: the distance between making a working tool and making something reliable enough to operate across more users, situations, and systems. (View Highlight)
Lowering the cost of creating software does not necessarily lower the cost of operating every piece of software at scale. As a tool expands, it accumulates dependencies, edge cases, security requirements, maintenance work, and expectations that were absent when it served one person or one team. What was relatively easy to make can become difficult to finish and later to sustain. (View Highlight)
“Many of the needs addressed through personal software were previously difficult for the organization to see.” (View Highlight)
This is also where the role of more experienced technical people becomes clearer. The authors suggest involving technical expertise early enough to help determine which parts of a solution a non-technical person can reasonably build themselves, and where deeper engineering knowledge becomes useful. (View Highlight)
This does not mean that every personal tool should be reviewed or professionalized from the beginning. That would undermine much of the immediacy that makes the practice useful. It suggests instead that organizations may need ways of recognizing when the nature of a tool has the potential to change and scale. (View Highlight)
Much AI-assisted software creation still starts as an individual activity. People experiment independently, around problems very close to their own work. But after enough of this activity occurs, there seems to be a moment when makers start finding one another. At that point, software creation begins to acquire a social structure. (View Highlight)
BBVA, one of Europe’s largest banks, offers one example at considerable scale. A recent Harvard Business Review article “The Hidden Demand for AI Inside Your Company” analyzes its AI adoption program. A network developed around roles such as Champions, Co-Champions and more experienced users known as Wizards. The Community of Practice gave employees a place to share what they were doing, solve problems together, and discover work happening in other parts of the bank. One important effect of this structure was that individual experimentation became visible to other people. (View Highlight)
I have been observing a similar process inside other organizations, although it developed more informally. People who were building with AI began organizing themselves into an AI builders community with their own online forum and meeting regularly. The sessions are practical: people show what they have made, explain how something works, and help colleagues trying to solve similar problems. (View Highlight)
Over time, a smaller group of active makers emerge from the community. They forme an AI Hub that connects this distributed activity with senior leadership and IT. The group typically takes a more formal role in deciding what should be pursued and how. (View Highlight)
What interests me is the sequence in which the structure followed the practice. This is almost the reverse of a conventional transformation program, where roles, governance and structures are usually defined before participation begins. (View Highlight)
Through repeated interaction, some people became recognizable as particularly experienced or useful to others. A smaller coordination structure emerged afterwards. (View Highlight)
These communities create channels through which knowledge can circulate. Tools may have been created locally, but the learning around them can travel through the organization. A pattern developed by one team can become an example for another without requiring the original software to be deployed everywhere. (View Highlight)
This seems to be one of the important lessons from the BBVA case. Its Community of Practice created a way for distributed creation to become visible and for knowledge to move between people and units. That visibility also provides a view of the long tail of needs. (View Highlight)
Many of the needs addressed through personal software were previously difficult for the organization to see. They were too small, too specific, or too local to appear in a conventional software roadmap. Once people begin building around those needs and sharing what they build, some of that previously invisible demand becomes observable. (View Highlight)
This can also give IT and organizational leadership a better view of which experiments are becoming consequential. The community therefore does more than share knowledge. It becomes one of the places where needs, solutions and emerging capabilities become visible to the organization. It also allows governance to become more informed. Decisions about what should remain local, what needs technical support, and what should eventually become professionally maintained software can be based on activity that already exists rather than on hypothetical demand. (View Highlight)
A significant proportion of personal software may remain close to the people and situations for which it was created. Around those tools, however, other things can mature: better starting environments, technical guidance, repositories and, and the institutional ability to monitor when something a solution should remain small and when it is becoming something else. (View Highlight)
Seen this way, what scales is not necessarily each piece of personal software. What can scale is the capacity to make software as an organizational capability. That capacity includes the technical practices that makers gradually acquire, the colleagues who mentor them, and the communities through which knowledge circulates. (View Highlight)
