Should an Agency Build Its Own Product, and What Breaks When Client Work Gets Urgent?

Two kinds of work sit in the same week and draw on the same pool of hours. One has an external party attached to it, a date, and an invoice at the end. The other has none of those things. Whatever intentions were declared at the start of the month, the second kind is the one that gives way, and it gives way quietly, because nobody outside the building notices when it does. That is not a failure of resolve. It is the predictable consequence of two obligations with very different response windows sharing one budget of attention, and it can be described precisely enough to design against.

Everything below is structural analysis of a situation many firms are in. It is not a description of internal practice at Zealsync, and nothing in it should be read as one. The public facts are plain enough and stop well short of an allocation model: Zealsync is a parent technology company, it develops four focused products, and it operates Intense Path, its Brand, Growth and Technology agency. Both kinds of work therefore exist under one roof. How capacity moves between them is not set out here, and a reader should not infer a model from the fact that the article exists.

The reason to be explicit about that is the same reason the conflicts section later in this piece exists. A firm that both advises and builds has an interest in what it recommends, and the honest thing to do with an interest is to name it before the argument rather than after it. If you want the company structure itself rather than the operating question, the company page states it, and the Intense Path page sets out what the agency brand covers. This article stays on the general question: how two kinds of capacity can be divided, and what fails when the division does not hold.

Billable capacity is linear. An hour spent on a client engagement converts into revenue on a schedule you can more or less predict, at a rate that does not improve much with repetition. Ten hours produce roughly ten hours of value. The relationship is close enough to one to one that it can be planned, sold and reconciled, and that legibility is exactly what makes an agency a viable business rather than a hopeful one.

Product capacity behaves differently. Its return arrives later, arrives unevenly, and compounds: a data model built once makes the next six features cheaper, a deployment path built once makes every subsequent release cheaper, a component built once removes a decision from every screen that follows. The value of an hour spent on it is not knowable on the day it is spent, and much of it is only realised if further hours follow. Work with that shape is worth doing and impossible to schedule with the same confidence as delivery work.

The conflict is not between importance and unimportance. It is between clocks. Client work has an external clock: somebody outside the firm is waiting, has an expectation of when, and will register a slip. Product work has no external clock at all in its early life. Nobody writes in to ask why the internal schema migration did not happen this week. Because the cost of postponing it is invisible on the day of the decision, postponing it is never the visibly wrong call in the moment, and a sequence of individually reasonable moments is enough to drain a year.

Product work is never urgent, which is why it is always the cheapest thing to postpone and never the wrong thing to postpone today.

The counter-case deserves a hearing, because it is often right. For a good many firms the agency work is the business, and the product is a distraction wearing the costume of a strategy. A product that never earns is not an asset in waiting, it is a standing liability with a maintenance calendar that arrives whether or not anyone used it, as the upkeep argument sets out in detail. If the honest answer to what this would be worth if nothing more were added to it in six months is nothing at all, and it would still cost money to keep alive, then the correct reserve for product work is zero and the rest of this article describes a problem you do not have. That question is worth asking annually rather than once.

A fence is any rule that makes moving capacity from product to client work a deliberate act rather than a default. All four models below are stated as allocations of capacity, not of named people, because the arithmetic does not depend on how many people there are. They differ in where the breach has to happen, how visible it is when it does, and what the fence costs when it holds.

Fenced days

Named days in the week are reserved for product work. It is the cheapest fence to state and the easiest for everyone to hold in their heads, which is a real advantage: a rule nobody can recite is not operating. It suits small allocations, and it keeps product work in continuous contact with the people doing it rather than in quarterly bursts.

Its failure mode is drift. A reserved day is a visible empty space in the week, and empty space attracts anything that did not fit elsewhere. The tell is linguistic before it is numerical: the reserved day starts being described as a catch-up day, and nobody objects, because catching up is obviously virtuous. Its second cost is fragmentation. Work arriving in single-day slices pays a re-entry charge every time, and some work does not fit the slice at all. A migration, a dependency upgrade with a broad blast radius, or a change that touches many files at once needs an unbroken run, and a fence that only ever grants days will quietly filter the roadmap down to work that fits a day.

Fenced capacity, reserved before the month is sold

A proportion of total capacity is reserved before any commitments are made, and only the remainder is sold. This is the strongest of the four, for one reason: it moves the breach forward in time and into daylight. To take from the reserve you have to take from it at the point of sale, in front of a number, while deciding whether to accept a piece of work. That is a conversation with an owner and a record. Breaching a day-fence happens at four o'clock on a Thursday with nobody present.

Its failure mode is the nominal reserve: a number that exists in a plan and is drawn down silently everywhere else. The reserve only works if it appears in the same artefact as the commitments, in the same units, so that a sold hour and a reserved hour are visibly competing for the same total. If capacity is planned in one place and the reserve is asserted in another, it is not a reserve, it is an intention. The cost of this fence when it holds is real and should be stated: in a strong month you sell less than you could have, and in a thin month you carry the reserve anyway, which is precisely when carrying it is hardest to justify and most valuable to have done.

Fenced calendar weeks

Whole weeks are given to product work, with client delivery held at a defined minimum during them. This is the only one of the four that reliably produces work requiring continuity, and it is the correct choice when the roadmap is dominated by changes that cannot be started and stopped cheaply.

It has a precondition that is often skipped. Client obligations do not pause because a calendar was marked, so a product week is only survivable if there is an explicit answer to what still gets answered during it, agreed with clients before the week rather than discovered inside it. A response commitment of one working day is compatible with a product week. A commitment to same-day turnaround on anything raised is not, and no amount of internal resolve changes that. The characteristic failure is not the interrupted week but the moved week. A week that is moved rather than defended is a cancelled week with better manners, and the second move is always easier than the first.

The product treated as a client

Internal work is put through the same machinery as external work: a brief, a defined scope, an estimate, a schedule, a review, the same status reporting. The appeal is that it requires no new discipline. A delivery firm already has apparatus for turning a brief into scheduled work, and pointing that apparatus inward costs almost nothing to set up.

Two things go wrong. The first is that an internal client can be deprioritised without consequence, because there is no relationship to damage and no invoice to forgo, so the fence has the shape of accountability without the substance of it. It only works if someone is genuinely answerable for the internal brief in the way an account lead is answerable for an external one, and answerable to a person who will actually ask. The second is a mismatch of shape. Agency machinery is generally tuned for fixed scope and a defined endpoint, and early product work is neither. Forcing it into that mould produces a plan-shaped artefact for work whose whole purpose is to change shape in response to what it learns, and the plan then becomes a reason not to change course.

When demand exceeds capacity, obligations do not degrade at random. They degrade in an order, and the order follows from one structural property: the obligation with the shortest enforced response window has the least slack, and an obligation with no enforced window has unlimited slack. Whatever has the most slack absorbs the overflow first. That is the whole mechanism. It is worth stating plainly because it is an assumption rather than an observation, and a reader who thinks it is wrong should be able to see exactly what they are rejecting.

From that property the sequence follows. First to go is internal product work, because its response window is undefined and its slippage is invisible outside the firm. The tell is not that product work stops. It is that product activity clusters at the very end of a planning period or does not appear at all, and that the same roadmap item is carried forward across three or four consecutive plans without anyone deciding to drop it.

Second to go, once product capacity is fully drained and demand still exceeds supply, is the client work with the longest response window. That means the parts of an engagement nobody is waiting on today: documentation, the maintenance item raised weeks ago, the analysis that informs next quarter rather than this one, the retrospective. These are still client obligations, but they have slack, and slack is what gets consumed. The tell is a recurring promise to pick that up after this push, attached to the same item on three separate occasions.

Third is quality inside the work that is already dated. When the date is fixed and the scope is fixed, the only remaining variable is what happens inside the box: review time shortens, checks are skipped, accessibility conformance moves from something verified to something assumed. This stage is dangerous because output volume looks unchanged. The tells are indirect. Review turnaround falls while the volume of work under review does not. Defects are found after handover that would previously have been found before it. Items that are conformance obligations under a published standard such as WCAG 2.2, where the success criteria are stated and testable, start appearing on post-launch fix lists rather than in the build itself.

Fourth, and only fourth, is the dated commitment itself. This is the one an external party notices, and by the time it happens three earlier failures have already occurred without any external signal at all. That is the practical value of the ordering. It says that the first externally visible symptom is a late indicator, and that the monitoring worth building sits on stages one and two, which are both cheap to observe and cheap to correct.

By the time a client can see the fence has failed, it is the fourth thing to have broken, not the first.

What would make this order wrong. The ranking is by enforced response window, not by category, so anything that changes a window changes the order. If an agreement puts a hard, enforced clock on exactly the low-visibility items, documentation with a delivery date and a consequence attached, then that work leaves the second position and stops absorbing overflow. More significantly, if the product acquires an external date, an announced release, a commitment made to somebody outside the firm, then it acquires a clock and stops being the thing with the most slack. The order then reverses at the top, and quality inside client delivery begins to erode before product work does. Both cases are consistent with the mechanism rather than exceptions to it, but both mean the sequence has to be re-derived rather than assumed. The model predicts nothing at all about what matters most. It predicts only where the slack is.

• Stage one tell: the same product item is carried across consecutive plans without an explicit decision to drop it.
• Stage two tell: low-urgency client items accumulate into a queue that only ever grows, each deferral individually reasonable.
• Stage three tell: review and verification time contracts while the volume of work does not, and defects migrate from before handover to after it.
• Stage four tell: the first missed date, which is confirmation rather than warning.

A request arrives inside a client engagement and looks reusable. Whether the thing in front of you is best understood as a product, a service or a feature is a separate question with its own answer, and it is set out in the piece on telling the three apart. The question here is narrower and purely one of allocation: which pool pays for the work?

Three tests settle most cases. Who is the work accountable to: if there is a named external party who can reject it, it is client work regardless of how general the solution turns out to be. Who bears the cost if it is wrong: if the consequence of a bad decision lands on the client's timeline or the client's budget, the client's engagement pays for the decision. And is the deliverable the thing itself or the capability to make the thing: building the artefact a client asked for is billable, while building a general mechanism so that this whole class of artefact becomes cheaper to produce in future is product work, even when the first instance of it happens to be a client's.

Two misclassifications matter, and they cost differently. Charging product work to a client is the more damaging: the client pays for generality they did not ask for, the timeline stretches to accommodate work that has nothing to do with their outcome, and the firm builds an asset on somebody else's budget. It is also the easier one to do without noticing, because from the inside it feels like doing a thorough job rather than a self-interested one. The reverse, spending product reserve on what is genuinely bespoke, burns the scarcest capacity in the business on something that will never be reused. It is less unfair and often more expensive.

One thing that is not a capacity question at all: whether reuse is permitted. Who owns work produced inside a paid engagement, and whether a general mechanism derived from it can be carried into a product, is determined by what the agreement says. It should be settled in writing before the work starts rather than assumed at the point where the reuse has become attractive, because by then both parties have an interest in remembering the original conversation differently.

The strongest argument for running both kinds of work under one roof is evidential. A firm doing client work sees the same problem stated in different vocabularies by parties who have never met, and repetition across unrelated engagements is a far better signal than any single request, however forcefully it is made. That is a genuine advantage, and it is not available to a product-only firm without buying it expensively through research.

The boundary is abstraction. What legitimately crosses from an engagement into a roadmap is the pattern: the shape of the problem, stripped of particulars, corroborated across several unrelated instances. What must not cross is the specific: a client's confidential material, their internal process, their commercial position, or a requirement so particular that the resulting feature is traceable back to them. A useful check is whether the person who first described the problem would recognise themselves in the feature. If they would, it is not abstraction, it is transcription.

The sharper conflict is advisory. When a client pays for a recommendation they are buying independence, and a firm that also owns a candidate answer has an interest in the outcome. There are only two defensible ways to handle that. Disclose the interest and set the product aside entirely, or disclose the interest and evaluate the product against alternatives on the client's stated criteria, with the disclosure made before the work is agreed rather than in the final presentation. Zealsync operates Intense Path as its Brand, Growth and Technology agency alongside the products it develops, which is precisely the arrangement this section describes, and is the reason the disclosure in this article sits at the top rather than in a footnote.

A quieter conflict is worth naming because it is harder to see from the inside: using paid engagements as unbilled product research. Scope creeps in the direction the roadmap needs rather than the direction the client's problem needs, and every individual instance is defensible on its own terms. The tell is directional. Scope drift is normal and ordinarily drifts both ways. Drift that consistently runs towards the same handful of capabilities is not drift, it is steering, and the person doing it is usually the last to see it.

An allocation is a hypothesis about how much compounding work a business can afford to carry, and it should be revised on evidence rather than defended on principle. Four signals are worth acting on, and each points at a different correction.

The reserve is systematically breached rather than occasionally. An occasional breach is what a reserve is for. A reserve consumed in most periods is not a reserve that is too small, it is a set of commitments that is too large, and the correction belongs at the point of sale rather than in the fence. Raising the reserve without reducing what is sold simply moves the same shortfall onto a different line and buys a month of feeling organised.

The product has started generating obligations of its own. Once something is released it produces support, incidents and upkeep on a calendar nobody controls, and that load is not optional. If it is absorbed silently out of the same reserve that was meant for development, then the development reserve has already gone and the plan has not noticed. The correction is to separate upkeep from development inside the reserve itself, so that the two stop competing invisibly and the trade-off between running what exists and building what does not becomes a decision somebody makes.

Work happens but nothing completes. This is a signal about the type of fence rather than its size. Continuous partial progress with no completions is the signature of fragmentation, and the answer is to convert the same total capacity into fewer, longer blocks rather than to increase it. The opposite reading is worth ruling out first: if the fence is respected, the capacity is genuinely used, and yet the work chosen is always the least demanding item available, then the fence is functioning and the prioritisation is not. That is a different problem with a different fix, and enlarging the reserve will not touch it.

Nothing external has changed the product's shape in several cycles. Compounding work only compounds if it stays in contact with something outside itself. A roadmap that has not been altered by any external input for several periods is being built on internal conviction alone, and the reserve is funding certainty rather than learning. That is a signal to reduce the allocation, not because the work is bad but because the return on it can no longer be checked, and an unverifiable return is indistinguishable from no return until much later.

The question in the title does not resolve into a verdict about what kind of company you are. It resolves into three answerable operating questions. Can you name the reserve as a number rather than an intention? Does it appear in the same place commitments are made, so that taking from it is a visible act rather than a quiet one? And can you say, before it happens, what breaks first when it is breached? A firm that can answer all three can run both kinds of work at that size of reserve, and can change it deliberately when the signals change. A firm that cannot has not yet decided its allocation. It has left the decision to the default, and the default is already described above: whatever has the most slack absorbs everything, until the only thing with any slack left is the work nobody outside the building was waiting for.