Development notes · September 2026

On keeping
a tool small.

A few decisions behind Linework.

A small tool has an advantage that is easy to lose. It can make its whole purpose visible. A person arrives with a particular piece of work, changes one or two things and leaves with a result they understand. There is no need to learn a workspace, invite a team or choose a plan. The tool succeeds by making the task smaller than it was before.

I built Linework after repeatedly cleaning short lists by hand. The lists were not important enough to justify a large application, but they were long enough to make the repetition annoying. Some lines had extra spaces. Some appeared twice. Sometimes the order mattered and sometimes alphabetical order was more useful. The first prototype was a textarea and a button. That was enough to expose the actual decisions.

The central decision was to make every transformation explicit. Trimming whitespace is different from removing blank lines. Removing duplicates can be case-sensitive or case-insensitive. Sorting changes order and should not happen merely because it looks tidier. A tool that performs all of these actions automatically can destroy information while appearing helpful. I wanted the output to be predictable from the controls.

The implementation reads the input as lines and applies the selected operations in a fixed order. Trimming happens first, followed by blank-line removal, duplicate removal and optional sorting. That order is visible in the explanation. If duplicates are removed without trimming, two lines with different surrounding spaces remain different. If case is ignored for duplicate detection, the first original spelling is retained. Those details are small, but they are the behavior.

I deliberately kept the input and output separate. The source text remains available after processing, so a person can compare the result or change the options without reconstructing what they started with. Copying uses the visible output. Downloading uses the same output. There is no second transformation hidden inside the export path. The tool should not surprise someone at the moment they try to leave with their work.

Empty input is a valid state. It does not need an error banner or a red border. The tool can say that there are no lines to process and show an empty output. A clipboard failure is different: the person has requested an action that the browser did not permit. In that case, the interface explains the limitation and leaves the output selectable. The distinction keeps feedback proportional to what happened.

I also chose not to store the text automatically. A list can contain private material even when the tool itself seems harmless. The browser does all the processing locally, and the page does not send the input anywhere. Closing the page clears the working text. That behavior is explained beside the tool, where it matters. It is a deliberate limitation rather than an invitation to add an account system.

The result is not a revolutionary product. It is a useful object with a small surface area. I can explain its behavior in a few paragraphs, test its edge cases and maintain it without a large framework. That is the kind of development I want this portfolio to show: enough care to make the ordinary action dependable, and enough restraint to stop when the task is complete.