Founder letter

Building with limited resources

Constraint as a useful forcing function

What you cannot afford to waste

There is a version of building a company that involves large amounts of capital deployed across many experiments simultaneously, with the expectation that some will land. That version is not available to everyone. For most builders, at most stages, resources are finite, sometimes severely so, and the real skill is not choosing between good options. It is making something worth keeping from the materials you actually have.

November 2015 is that kind of month for us. Not a dramatic moment of crisis, but a quiet, clarifying one. The work is real. The constraints are real. And between the two, something useful is beginning to take shape.

What follows is an attempt to think honestly about what working within limits actually demands, and what it quietly teaches.

---

Constraint does not simplify. It reveals.

The common mistake is to treat a limited budget as a smaller version of an unlimited one: the same choices, just with fewer of them. In practice it works differently. When you cannot afford to do ten things, you do not simply pick the best two. You have to go further back and interrogate whether the ten things were ever the right frame to begin with.

Constraint forces you back to the question of what is actually necessary. Not what would be nice, not what you would build if you had three engineers and eighteen months of runway, but what the smallest version of a useful thing looks like. That is a harder question than it appears. It requires that you have a clear enough model of what you are building that you can distinguish structure from decoration.

The inability to do everything is, in this sense, a form of enforced clarity. It will not save a bad idea. But it will strip away the scaffolding that can hide one.

---

Small by necessity, useful by design

The early experiments that come out of this period are small. They have to be. A single person or a small team working without significant capital cannot build a large surface area and maintain it. Every feature that exists is a feature that has to be debugged, explained, supported, and improved. The carrying cost of complexity is real even when the building cost feels manageable.

So the work becomes: can you find the smallest thing that is genuinely useful, and make it very well?

This is not a philosophy of minimalism for its own sake. It is a philosophy born of necessity that, when taken seriously, produces better work than the alternative. The features that survive the culling process are the ones that actually matter. The interactions that get kept are the ones people would miss. The things that get cut are often, in retrospect, the things that were adding noise rather than signal.

There is a discipline available here that is harder to access when money removes the forcing function. When you have limited capacity, every hour spent on something is an hour not spent on something else, and that trade-off is visible in a way it is not when teams are large and budgets are loose. The visibility of the trade-off tends to produce better decisions.

---

What capital accelerates, and what it cannot

It is worth being honest about what capital does and does not change.

Money can buy speed. It can hire the engineers who would otherwise take you years to become. It can run experiments in parallel that would otherwise have to run sequentially. It can purchase distribution, absorb the cost of mistakes, and give a team time to learn without needing immediate revenue to survive. These are real advantages, and they matter.

But capital does not buy taste. It does not buy the hard-earned knowledge of what your users actually need rather than what they say they want. It does not buy the organisational judgment required to know which direction to point the speed in. And it cannot compress the time it takes to understand a problem deeply enough to build a genuinely good solution.

What this period is producing, through necessity, is the slower knowledge. The kind that comes from watching what breaks, noticing what gets used and what gets ignored, building a slightly better version, watching again. It is not glamorous work, and it is not fast. But it compounds in ways that shortcuts bought with capital do not.

---

The long view required

There is a particular patience required when you cannot accelerate. Not the patience of waiting, that is passive and produces nothing, but the patience of continuing to work steadily while resisting the pressure to measure progress by speed alone.

The pressure to move faster than your resources allow tends to produce a specific kind of mistake: sacrificing the durability of what you are building in exchange for the appearance of progress. Features shipped before they are stable. Systems designed to impress rather than to function. Work done quickly to meet a self-imposed deadline rather than carefully to meet an actual need.

The constraint of limited resources, when held with some discipline, protects against this. You cannot afford to rebuild the same thing three times because you did not think it through the first time. So you think it through. You cannot afford to build something large that turns out to be wrong. So you build something small and check.

The long view is not a preference when capital is limited. It is a requirement. You are not going to sprint to an exit. You are going to build something that earns its right to exist by being useful for long enough that the economics can eventually work.

---

What it teaches about what matters

The practical lesson of building with limited resources is that it forces a kind of honesty about value.

When you can do only a few things, the things you do have to be worth doing. This sounds obvious but in practice it requires that you resist a long list of pressures: to build what looks impressive rather than what is useful, to ship something to prove momentum rather than because it is ready, to optimise for an audience that is watching rather than for the users who are working.

The early work at Mustard Seed Group is going through that filtering process. The ideas that survive are the ones that hold up when resources are tight and timelines are long. They survive not because they are defensible in a pitch but because they are genuinely solving something. Because when you strip away the features that would be nice and keep only the ones that are necessary, what is left still makes sense.

That is the test worth passing.

---

Building toward structure

This period is not defined by what has been launched so far. It is defined by what is being assembled: an understanding of the problems worth solving, a set of early experiments against them, and a thesis about how those experiments connect to each other.

The portfolio logic of Mustard Seed Group, research feeding product, product proving patterns, patterns informing the next layer of research, is not yet visible to anyone outside. From outside it looks like small, unconnected work. From inside it is the beginning of a system.

That is the nature of early-stage institution-building when capital is limited. You cannot show the whole thing at once because the whole thing does not yet exist. What you can do is make sure that each piece is true: that it solves something real, that it holds up over time, and that it points in the right direction.

The resources available right now are small. The ambition behind the work is not.

The task is to make sure the gap between those two things does not become a reason to cut corners, but a reason to be more precise about which corners were ever worth building in the first place.

That is the work. It continues.