The seams in big software
Software built by a large organisation carries the shape of the organisation that built it. One group designs, another builds, a third maintains, and between each pair is a seam — a handoff where context is lost, intent is approximated, and the thing that ships is a negotiated average of several groups' half-understandings. You can feel these seams as a user: the settings that contradict the onboarding, the feature that clearly belongs to a team that has since moved on, the parts that do not quite know about each other.
These seams are not a failure of talent. They are a property of scale. Past a certain size, no single person holds the whole product in their head, so coordination replaces comprehension, and the software becomes a map of the meetings that produced it. More people did not make it more coherent; they made it a committee, and committees do not have a point of view.
Fewer things, done properly
A small team is forced to choose, and the forcing is a gift. It cannot ship forty features, so it ships the few that matter and makes them good. It cannot chase every market, so it picks the ones it can actually serve and serves them properly. Scarcity of hands turns out to be a discipline that abundance never imposes — you build what earns its place, because there is no room for anything that does not.
This is why we build a small number of products and hold each to a high bar, rather than a large number held to whatever bar the schedule allows. Docusift, Memoria and Lekha are few on purpose. Fewer things, done properly, is not a limitation we are apologising for; it is the strategy. The alternative — more things, done to a deadline — is how software gets wide and shallow, and we would rather be narrow and deep.
The whole thing held in one head
The real advantage of a small team is coherence. When the same few people carry a product from idea to design to code to the thing a user touches, there are no seams to lose meaning across. The design knows what the code can do. The code knows what the product is for. Decisions made at one end of the product are answerable at the other, because it is the same hands at both ends.
That coherence is not visible as a feature, but it is felt in everything. Software made by people who hold the whole thing in their heads simply fits together in a way that committee-built software cannot. It is the difference between a house designed by one architect and one assembled from the leftovers of six. A small team cannot do everything — and because it cannot, what it does do can be whole.