Software for One: Why Process Knowledge Matters Now

AI is shifting the economics of custom software. For small and medium-sized businesses, that opens a door: people who genuinely understand a process can take a more active part in digitizing it. The role of developers changes along with it.

A friend recently showed me a console game from his childhood. He had been using AI tools to turn the executable program back into something he could work on. After a few weeks, he had a running version to show me. What stayed with me was not the game itself but the question underneath it: what becomes possible when the road from a finished product back to a comprehensible blueprint gets considerably shorter?

This is a personal observation, not a performance comparison. It does not show that every program can be rebuilt in weeks, and it says nothing about whether such projects are legally simple. Still, the scene captures a shift we keep running into in our consulting work.

More and more, companies ask us to help their teams build their own capabilities: how can product owners, business teams, and developers write better software together with AI? How do we set up a working process that holds up in practice? Increasingly, the engagement begins with the company's own people and the way they work.

For us, this points to one central proposition: for a manageable internal tool, it may become easier to teach someone who knows the process to implement it with AI than to first hand all their practical knowledge over to an external development team.

In this article

1. A tool does not have to pay its way across a thousand customers
2. The blueprint gets closer. Running the system stays hard
3. The person who knows the process gets a seat at the workbench
4. Process knowledge becomes an asset when it can be tested
5. A prototype becomes a working tool only when someone takes responsibility
6. Cheaper code does not automatically mean smaller budgets
7. How a medium-sized business can put this change to the test

A tool does not have to pay its way across a thousand customers

Standard software follows a plain logic: heavy development costs are divided among many customers. To make that work, the product has to find enough common ground among them. Each business then bends its way of working to the available features — or pays extra for customization.

Much good has come of this. Accounting, communication, and a long list of administrative tasks benefit from mature, widely available solutions. Nobody gains an edge simply by writing their own address book.

Trouble starts where a company's process departs from the assumed norm. An approval hinges on a particular agreement with a customer. An order has to travel through three systems whose data refuses to line up. A veteran employee knows why a file that looks complete still has to be held back. Differences like these often end up living in spreadsheets, emails, and handwritten notes in the margin.

For a long time, the effort of a dedicated solution was hard to defend. A tool for eight people faced roughly the same basic development hurdles as a product for several thousand users. The result was a strange situation: an important business process stayed clumsy because its market was too small.

AI-assisted development can change that arithmetic. When early interfaces, data models, integrations, and tests take less work to produce, smaller projects come within reach. An application can serve exactly one company. It does not need the potential to grow into a general software product for the investment to have been worthwhile.

That is what we mean by software for one — also called bespoke or one-of-one software: a tool whose shape grows out of a specific business need. Unique does not mean rebuilding every technical component. Standard building blocks help ensure that only the genuinely distinctive business logic gets built individually.

The decisive calculation stays a commercial one: what does the current process cost, counting errors, waiting, and rework? What will the right solution cost across its entire useful life? Cheaper code is one term in that equation. Value appears only in daily use.

The blueprint gets closer. Running the system stays hard

Public projects show how far developers can get with the new tools. One example is PhotoCraft, an open-source image editor written in Rust. Projects like this matter because they demonstrate that implementing substantial software concepts is coming within reach of a wider circle of people and teams.

Context, though, matters. PhotoCraft describes itself as an early alpha and says plainly that it is not yet a replacement for Photoshop in everyday professional use. The project itself lists gaps in tools, typography, professional workflows, and compatibility. The story of a fully reconstructed Adobe suite runs well ahead of what this evidence supports.

Between an impressive implementation and a dependable working tool lies a wide gap: unusual files, integrations accumulated over years, accessibility, support, updates, and the question of who fixes a fault the following morning. A business customer buys that reliability too. Rarely do they pay merely for a menu item to exist.

What may plausibly shift is the relative weight of different competitive defenses. For some providers, leaning solely on how hard it is for outsiders to understand or recreate an implementation may provide less protection. Trust, integration, data quality, workflows, and reliable service over time gain importance alongside it. The degree will differ from product to product.

Switching programming languages is not a legal reset

Functionality and protected program code are legally separate things. In the SAS Institute case, the Court of Justice of the European Union distinguished, among other things, a program's functionality and its programming language as such from its protected form of expression. That is not a general permission to copy someone else's source or object code.

The EU Software Directive likewise treats translations and adaptations as acts that generally require authorization; the exceptions come with specific conditions. Implementing a function independently therefore calls for a different legal assessment from translating copied code into Rust. On any given project, the rights, the provenance, and the approach all need to be examined. The language alone settles none of these questions.

For small and medium-sized businesses, the more attractive opportunity often sits closer to home anyway: building a solution for a process they understand and are responsible for.

The person who knows the process gets a seat at the workbench

Significant friction can arise before the first version goes into use. People from the business describe their work. A project team turns what it hears into requirements. Developers turn those requirements into a system. Only in use does it surface which rules were never spoken aloud.

This rarely comes down to carelessness. Experienced people carry a large store of tacit knowledge. They know which supplier reliably supplies items that are still outstanding, which discrepancy warrants a query, and when a formally correct entry is wrong in practice. Someone who lives inside a process every day may no longer even register certain decisions as distinct rules.

When that person can help shape a small prototype directly, feedback arrives earlier. A form gets tried out. An exception shows itself. A rule gets stated explicitly. The next version reveals whether the explanation actually holds. Practical knowledge stays close to its implementation.

The changing requests we receive for consulting support this reading. Whether it holds in any given company has to be established through a concrete project.

The person responsible for the process does not need to design a distributed system architecture on day one. But they should understand what an application may read and change, how its results will be checked, and when technical support is required. In the other direction, a developer does not need to know every corner of the business from the outset, provided they work closely enough with the person responsible for the process.

That reshapes the collaboration. Business specialists contribute more than requirements. Developers do more than translate a specification. They design a sound technical environment, help with the difficult decisions, and make the move into daily operation dependable. The connection between these responsibilities becomes more valuable.

What the productivity studies actually show

Even among professional developers, the effects of AI are uneven. A study covering three field experiments and 4,867 developers estimates, in its pooled model, roughly 26 percent more weekly pull requests from the use of earlier versions of Copilot. The individual experiments were statistically imprecise. And the study measured an output metric — not the overall value of the finished products, nor their maintainability over time.

In a study from the first half of 2025 involving experienced open-source developers and the tools available at the time, METR found that tasks took 19 percent longer. In its February 2026 update, the research team also explains why its newer data cannot establish a reliable estimate of the current effect. Tools, tasks, participants, and working practices are all in motion.

Both findings call for a measured assessment. They establish neither that AI generally slows development nor that some universal acceleration factor exists. Nor do they provide a direct comparison between people who know a business process and external development teams. Which is exactly why a company should measure its own process rather than turn a figure from another setting into its business case.

Process knowledge becomes an asset when it can be tested

As a first implementation gets easier, one thing that cannot simply be generated stands out more sharply: the knowledge of what the right solution would be for this particular company. A distinction matters here as well. A long-established process is not good merely because it is old and difficult to explain.

Some distinctive practices create a real advantage. Others only compensate for weaknesses in existing software. Still others persist because nobody remembers why a rule was introduced. Automating all three without scrutiny is an especially efficient way to rebuild the past.

Good process work therefore starts with questions: what outcome do we need? Which decisions contribute to it? Which rules are necessary, and which are mere habits? Only then does implementation have a direction. That may lead to a custom application. It may equally reveal that an existing standard feature does the job.

Take a fictional example: a manufacturing business records delivery documents, matches them against purchase orders, and resolves discrepancies. A first application can extract information from documents and suggest matching orders. Its real value, though, emerges with partial deliveries, illegible documents, returns, and the cases where the order number matches but the contents do not.

The experienced employee knows these cases. Together with a technical partner, she can turn them into a set of examples that can be tested: this is what a normal transaction looks like. Here, the application must ask a question. There, it may make a suggestion but must not post anything to the system. This case goes to a particular person.

Practical knowledge then becomes a basis for development and acceptance alike. A small collection of good real-world cases can be more useful than a lengthy specification full of general wishes. Appropriate data and clearly defined access matter here; sensitive documents should not be placed in arbitrary tools without careful consideration.

Collaboration with external partners can also grow more precise this way. It requires clear agreements on confidentiality, usage rights, source code, data export, and operation. Process knowledge is not protected simply by avoiding all collaboration. What matters is which information and rights are shared for a defined purpose.

A prototype becomes a working tool only when someone takes responsibility

A demonstration is a promise: this approach could work. Production use additionally demands an answer to what happens when things go differently. A document gets uploaded twice. A service is unavailable. A permission changes. Two people work on the same transaction.

These cases are not finishing touches to be bolted on later. They are part of the functionality. Small internal tools often reach into sensitive points of everyday work precisely because they are meant to close a gap an experienced person used to manage.

For a manageable starting point, a small collaboration with clearly assigned responsibilities is often enough: one person owns the business process, another owns the technical soundness of the solution. Depending on the risks, privacy, security, or other responsible functions may also need to be involved. Not every project needs a large team. Every project needs people who take responsibility for decisions and their consequences.

A useful solution therefore includes things that do not make a demo particularly spectacular: traceable changes, appropriate access permissions, a backup, a way back when something goes wrong, and a named point of contact. Just as important is the decision how long the tool will be maintained — and when it will be retired.

Software for one can be individual in its functionality. For operation and quality, it should draw on reusable standards wherever possible. A company developing ten internal tools does not need ten entirely different approaches to authentication, backups, and maintenance.

This is also where the story about free software reaches its limit. Some programming work is becoming cheaper. Responsibility for a dependable result does not disappear as a consequence. It is redistributed — and it must be included in the calculation from the start.

Cheaper code does not automatically mean smaller budgets

The time dimension is often missing from this discussion. If a tool makes a given task cheaper, we can keep the savings. But we can also tackle tasks that previously required too much effort. Capabilities then grow while the budget stays similar — or even rises.

A company might begin with simpler document capture. Once that works, matching, queries, approvals, and analysis become interesting. A small aid develops into a better-connected process. The first improvement has revealed additional possibilities.

This echoes earlier changes in office work. Word processing made it easier to revise documents. At the same time, expectations rose for design, variations, speed, and availability. We rarely keep using new tools solely to produce the old result a little more cheaply.

In that sense, the Jevons paradox as applied to AI and work offers a useful way of thinking: falling costs can stimulate additional demand. For software, that means more projects may become economically viable. It does not necessarily mean more employment, and it guarantees the future of no particular profession or business model.

Fewer working hours per project and a larger number of projects can emerge at the same time. Which effect dominates depends, among other things, on demand, available budgets, skills, and the limits of implementation. A blanket number for developer demand would be false precision here.

There is nevertheless an interesting prospect for developers. If straightforward implementation steps take less time, architecture, difficult integrations, operation, and collaboration with business specialists can move to the center. At the same time, certain routine activities lose value. The transition can create opportunities while being uncomfortable for individual people or companies.

The business question is therefore: what additional capability do we want to gain? Simply producing more and more applications can also create more and more maintenance work. Choosing well becomes more important as the number of feasible projects grows.

How a medium-sized business can put this change to the test

There is no need for a blanket decision against standard software or a program to reinvent the entire IT environment. A useful approach is a bounded project that allows this new division of work to be tested.

1. Choose a specific point of friction. Describe a recurring process with a clearly identifiable beginning and outcome. Record where waiting, errors, or rework occur today. A wish such as "We need more AI" is too vague for this purpose.
2. Bring practical expertise to the table. Involve the person who knows the process from daily work and a technical partner. Collect typical cases and important exceptions. Also clarify which distinctive practices really need to be preserved.
3. Compare buying, adapting, and building. Check existing features and suitable standard products before developing a custom solution. Include implementation, integrations, data maintenance, operation, and a possible later move to another solution in the calculation.
4. Limit the prototype and make it testable. Define in advance what a successful run looks like. Compare processing time, corrections, and the correctness of results with the current approach. Where consequences matter, keep the decision with a person initially.
5. Settle operational responsibilities before expanding. Who approves changes? Who responds to errors? How is data backed up, and how is access revoked? Only when these questions have answers can the experiment become a lasting working tool.

A good trial can also end with a decision not to build something yourself. Perhaps an existing product meets the need adequately. Perhaps the process is still too unclear. Perhaps a custom solution is worthwhile precisely because its value lies in a few distinctive rules. Each of these answers is more useful than another unattended prototype.

For us, the real opportunity in this development is a closer connection between knowledge and the ability to shape how work gets done. People who see every day where work becomes unnecessarily complicated can gain more influence over their tools. Technical specialists can help them turn a good idea into a dependable system.

We take the new possibilities seriously and test them against the work that should actually improve. Software for one becomes interesting when it fits a process, makes people's work easier, and proves itself in everyday operation.

Assess a suitable process together

In the 15-minute AI Sprint Check, we clarify which specific process would suit a first trial and whether an existing solution, an adaptation, or a custom tool makes sense.

Book a 15-minute AI Sprint Check

Read more

• The golden age of industry-specific software
• It's not over: the Jevons paradox, AI, and work
• Agentic systems and process optimization