A field journal of enterprise software, bound in cloth
On the long-form practice of building software the way an atlas is bound — slowly, with evident craft, and a serif body set on a generous leading.
Chapter the First
In the long winter of 2003, lsware was founded between two filing cabinets and one gas heater, in a room above a print shop where the smell of warm paper never quite left the air. There was no roadmap pinned to a wall, no investor deck, no founder photograph in front of a brick facade — only a contract with a regional logistics firm, a borrowed compiler, and a stubborn conviction that software, like a well-bound atlas, ought to outlast the season it was made in.
The first product was unremarkable on paper: a scheduling engine for a freight company that ran on margins thinner than the paper our invoices were printed on. But the way it was made set the grain for everything since. We wrote it the way a typesetter sets a long book — line by considered line, with the body governing the rhythm and the clever bits riding the margin. When the freight company doubled in size, the engine did not buckle; it inhaled the load the way a heavy page turns, weighted and unhurried.
By 2006 there were four of us, then nine, then the slow accretion that comes when work is done well enough that the people who commissioned it tell other people, in the quiet way that mattered before logo walls existed. We never put their names on a marketing page. We bound them, instead, into the index of commissions you will find further down this monograph — set in oldstyle figures, the way a serious book sets its dates.
“We did not set out to disrupt anything. We set out to build the kind of software you could hand to your successor without an apology.”
— from the 2003 founding memorandum, kept in a clothbound folder
What carried forward from that cold room was not a technology stack — those have turned over four times since — but a temperament. We are slow where slowness compounds and quick where it does not. We refuse the gradient, the neon, the dashboard that mistakes activity for progress. We earn trust the way an old Britannica volume earns it: through evident craft, dense considered work, and the unhurried confidence of a thing built to be read for a long time.
Chapter the Second
Visit the workshop and you will not find an open-plan floor of identical monitors. You will find something closer to a bindery: long tables, good light from the north, and on the shelves the accumulated apparatus of two decades of careful work — a deployment pipeline kept as scrupulously as a press is kept clean, a test corpus that has been added to and never carelessly pruned, and a documentation room where every system we have ever shipped has its own clothbound folder.
We organise the practice the way a monograph is organised: a reading column where the main work happens, and a margin rail where the supporting craft rides alongside. The reading column is the product itself — the engine, the interface, the data spine that has to hold weight for years. The margin rail is everything that keeps it honest: the runbooks, the migration notes, the small typeset cautions that a future engineer will be grateful for at two in the morning.
Nothing in the workshop is provisional in the way startup workshops are provisional. We do not ship a thing and then describe it later; we describe it as we build it, in running prose, so that the description and the system grow on the same page. When a client asks for a feature, the first artefact they receive is not a Gantt chart — it is a typeset case-study paragraph describing exactly what we propose to make and why, which they can read over a coffee and disagree with before a single line is written.
“A workshop is judged not by what hangs on the wall for visitors but by the condition of the tools when no one is looking.”
— pinned above the proofing lamp, attributed to no one in particular
The shelves hold, among other things: a logistics scheduling engine now in its fifth major revision; a clinical-records spine for a hospital group, built to be read by auditors a decade hence; a settlement system for a commodities desk that has not lost a transaction in eleven years; and a quiet little library of internal tools, each one bound and indexed, that we lend between projects the way a workshop lends a good plane.
Chapter the Third
What follows is not a logo wall and not a testimonial carousel. It is an index, in the manner a monograph indexes its sources: each commission a line, each line a date and a sentence, set in the same body type as the prose because the work and the record of the work belong to one document. We name only what we have leave to name; the rest are described by their shape, which is usually the more honest description anyway.
“An index is a courtesy to the reader who comes after you. We try to write the whole company as a courtesy to the engineers who come after us.”
— from the workshop handbook, revised annually since 2007
Chapter the Fourth
If there is a method at lsware it is the bindery's method, scaled to software: nothing provisional, nothing undocumented, nothing shipped that has not first been written down in running prose. We work in chapters, not sprints — a chapter being a unit of work small enough to read in one sitting and complete enough to bind. Each begins with a typeset proposal the client can disagree with, and ends with a folder on the documentation-room shelf.
We hold a few principles the way a workshop holds its squares and its straightedges — not for ceremony, but because the work goes crooked without them. The first: the body governs the rhythm. The product itself, the part that holds weight, sets the pace; the clever margin can wait. The second: describe as you build. A system and its description grow on the same page or they grow apart. The third: keep the proofs. Nothing superseded is deleted; it is stamped, dated, and shelved, because a record worth keeping is worth keeping findable.
The fourth principle is restraint, and it is the hardest. There is always a more elaborate dashboard, a more saturated colour, a more clever abstraction available; we decline most of them. The page you are reading uses exactly one bright colour, once, in the seal at the top — the way a chop seal is used on a Sumi painting. The software we make is built on the same discipline: one strong gesture where it counts, and the rest bound quietly to a working palette.
When the chapter is done we do not throw a launch party; we turn the page, which is to say we bind the folder, update the index, and begin the next proposal. It is a slow way to work and we have no intention of speeding it up. If you have a system that needs to be read carefully for a long time — by auditors, by successors, by the engineer at two in the morning — this is the workshop above the print shop, and the door is the anchor link in the colophon below.
“Turning a heavy page is not slow because the page resists. It is slow because the page is worth the turning.”
— closing line of every workshop handbook since 2007