A friend needed something built. In 1985, Jeremy Seigel designed his first barcode product. Years later, looking back on the request, he gave the friend credit for the idea. It is an agreeably practical beginning for a software business: somebody had a use for the thing before there was a company biography to explain it.
Seigel had been an electrical engineer in Silicon Valley. He left Intel that year and started Seagull Scientific, the business behind BarTender. A barcode is a modest-looking object on which people place considerable trust. Its bars and spaces have to survive the journey from information in a computer to something a machine can read. A mistake can be printed very neatly.
The company’s early work included a pair of jobs with rather different qualifications. Seigel wrote its first code. He also taped its first boxes shut. Software still had to leave the building, and apparently the founder’s responsibilities extended to the adhesive.
A friend, a request, a first product
Seigel’s account of that first product is unusually free of retrospective destiny. A friend suggested it; he made it; the timing turned out to be fortunate. The useful distinction is between having a problem to solve and knowing in advance where solving it will lead. The second is a luxury generally available to people writing the anniversary brochure.
He stayed with the work. His company biography describes a business that financed its expansion through profits and remained debt-free for more than thirty years. That historical description matters because it tells us what Seigel considered worth emphasizing about his record. Alongside hiring technical and business talent, he took pride in how the growth had been paid for.
There is a certain coherence between that account and the subject of the business. Labeling belongs to the working middle of an operation. It sits among purchasing, production, inventory and dispatch, where somebody eventually has to reconcile an instruction with an object. Attractive software is welcome there. Software that fits the job gets invited back.
The electricity had to come from somewhere
Seigel’s engineering record includes a wonderfully literal connection problem. A scanner needs power. A computer has a serial port. Could the port provide what the peripheral needed, including during moments when the scanner wanted more power than the port could supply directly?
US patent 5,313,642, granted on May 17, 1994, names Seigel as inventor and Seagull Scientific Systems as assignee. Its application dates to October 1990. The proposed interface stores energy while the peripheral’s requirements are lower, then makes that energy available when demand rises. It also describes controls intended to prevent operation when the available power is inadequate.
The drawing is a useful counterweight to the executive title. Here are the light source, photodetector, decoder and control circuit, each with a particular duty. “Founder” can describe someone’s relationship to a company without revealing much about the work. This diagram gets us closer to Seigel’s technical concerns.
A related patent, 5,514,859, followed in May 1996, again naming him as inventor. It addressed power and data interfaces for peripherals. Its claims include transferring scanner power and unformatted pulse data through the computer connection. These are specific engineering proposals, with the practical constraints spelled out rather than wished away.
Read beside the BarTender story, the patents offer a recurring question: what has to happen between two things before either becomes useful? In the hardware, the issue involves electricity and signals. In the software, it involves getting the right information to the right printed object. The connection deserves as much thought as the components.
The day the data reached the design
By September 2008, Seigel was discussing a very ordinary nuisance: running out of printer supplies. BarTender 9.0 included tools to track media usage, show remaining labels and ribbon, and send low-supply warnings. He explained that resellers could receive those messages too, helping them know when a customer might need fresh stock.
The release also dealt with what happened after printing. A history could record who printed a job, the data involved, and warnings or errors. Operators could inspect earlier work and reprint damaged or missing labels. The product was paying attention to the part of the working day that begins when the first attempt has already happened.
Functions described in the 2008 release. A workflow diagram, not a performance measurement.
Then came a glimpse of Seigel enjoying a smaller victory. In March 2011, BarTender 9.4 brought live database information into the design area. A designer could see actual records in place while working, instead of switching to a print preview to check them. Seigel said he had been asking his programmers for the capability for ten years.
He was pleased by its speed and by the way the controls fitted alongside the scroll bar without consuming extra space. His response was a small piece of office comedy:
“I may actually need to give somebody down there a raise!”
Jeremy Seigel, on BarTender 9.4, 2011
There is a recognizable person in that remark: a founder delighted that a long-requested feature has arrived, inspecting the placement of the controls, then making a joke about compensation. The enthusiasm has a particular object. Someone using the software can now see something sooner and do less shuttling between views.
In March 2012, BarTender version 10 moved into card printing. Seigel’s explanation was commercial as well as technical. He thought existing card-software suppliers charged more for design functions BarTender already offered, making drivers for card printers a sensible addition. The company could apply capabilities it had developed to another kind of output.
It is an expansion argument with identifiable parts: existing design tools, a nearby customer task and the drivers needed to connect them. No mysterious change in the founder’s vocation was required. Labels, tags and cards gave the engineering a series of related places to go.
A title catches up with the work
The organization was changing along with the software. Harold Boe had joined Seagull in 1988 as a developer. He became its first chief technology officer, then president and CTO in 1996, and president in 2013. Responsibility accumulated across sales, support, marketing, accounting and human resources.
By June 2016, when Boe became president and CEO, Seigel described a promotion that recognized the breadth of work already being done. Seigel retained the chairmanship. Boe described their continuing relationship in terms of Seigel’s role as a long-term strategist and majority shareholder.
- 1988Boe joins as a developer
- 1996President and CTO
- 2013President
- 2016President and CEO; Seigel remains chairman
The sequence gives the announcement its substance. The colleague who eventually took the CEO title had spent twenty-eight years at the business. There had been time to learn the software, manage people and acquire the daily obligations that make a company rather more complicated than its product.
A founder’s early versatility can be a necessity: code in one moment, shipping tape in another. As the business grows, the work has to become something other people can own. Seigel’s public account of Boe’s progression gives a concrete example of that change, responsibility by responsibility.
The product’s surrounding systems were becoming more explicit too. Released in late 2015, BarTender 2016 included Integration Builder, Print Portal and Administration Console. Integration Builder could start printing in response to events such as a saved file or changed database. The software had places to listen for work, as well as places to design it.
The work travels on
In December 2022, an affiliate of Peak Rock Capital completed its acquisition of Seagull Scientific. At the time, the buyer described BarTender as serving more than 100,000 businesses and producing more than 40 billion labels annually. Those are historical operating figures for the company, a way to picture the scale the original request had eventually reached.
For a labeling business, the number carries a pleasing physical implication. Each finished label has somewhere to go. Software reaches a printer; the printed result joins an item; the item continues through someone else’s working day. The company’s work becomes part of a sequence much larger than the application itself.
Seigel’s story is particularly legible at those junctions. A friend asks for a product. A port supplies a scanner. A database record appears in a design. A developer takes on the operations and eventually the CEO title. The steps are different, but each makes the next person’s task possible.
There is room for ambition in that kind of work, and room for a joke when the toolbar finally arrives. The first box still has to close. The scanner still needs power. And somebody, somewhere, would quite like to get the correct label printed and carry on with the day.