Maintenance and Efficiency

The Economics of an AI Studio: Expertise, Price and the Full Cost of Work

How an expert AI studio earns money from judgement and accountability, prices work by scope and risk, separates revenue, profit and cash, and calculates…

Chapter 70Maintenance and Efficiency

In the demo, the agent built a working prototype in an hour. Before release, the founder spent another half day untangling ambiguous decisions, re-running checks, talking to the client and fixing an access-control bug. The client was not buying the speed of code generation; they were buying a result they could safely accept and maintain. To understand the economics of the work, you have to count both what the agent did and the human judgement around it.

Learning outcome. After this unit the reader can connect a studio's specialisation to the problems it solves; run a diagnostic conversation without giving away a full design for free; choose between time-based billing, a fixed price, a productised service and support; calculate human and technical costs; distinguish revenue, profit and cash flow; and estimate the cost of an accepted task, including retries and human review.

All the calculations below are for teaching. They show a way of thinking, not a market rate, an income forecast or advice on contracts or taxes. Real figures depend on the client, the currency, the contract, the country, the services involved and the specific month.

An expert studio sells judgement and accountability for the work

The client pays for a solved problem, not for a number of tokens

A finished feature, agent, report or integration is an output of the work, but it is not necessarily the client's business outcome. The client may be buying faster processing of requests, fewer manual errors, steadier service or a way to make a decision with incomplete data. Before estimating a job, find out what change the client expects to see, how it will be accepted and which parts of the result remain outside the studio's control.

A service is work a specialist performs for a particular client. A project has an agreed goal, boundaries, a sequence of work and a completion condition. A productised service has a repeatable package of inputs, deliverables, price and process; it may still require human judgement. Support, or a retainer, reserves an agreed capacity or list of activities for a defined period. These labels do not by themselves define the scope of responsibility: that is set by the agreement, the access rules, the acceptance conditions and the description of exceptions.

In Managing the Professional Service Firm, David Maister examines the balance between client service, the development of professionals and the financial health of the firm. In the officially published excerpt of the first chapter, the publisher emphasises this balance and the fact that the composition of the team affects it. In his article The Anatomy of a Consulting Firm, Maister separately describes four metaphorical types of service, ranging from procedural work to complex diagnosis and trusted advisory work.

These ideas help you ask the right questions: how much of the work is repeatable procedure, how much is uncertain judgement, and how much close interaction with the client does it need? They are not a ready-made staffing plan, nor a reason for a two-person studio to copy the structure of a large consulting firm.

For a service with high uncertainty, time for diagnosis and experienced review matter more. A repeatable run on a proven connector can be standardised, but only once the studio knows the exceptions and the acceptance criteria. A fast model response does not turn an unexamined problem into a service with a defined scope.

Specialisation helps you recognise patterns, but does not guarantee sales

Specialisation is not a longer list of technologies on the website. It can relate to a particular type of client, a recurring problem, a domain or a way of working. A studio that regularly connects booking systems to accounting will, over time, learn to spot the risks of time zones, recurring events, conflicting records and access rights. That experience improves the questions it asks the next client. It does not remove the need to check that client's specific business rules.

In the materials accompanying The Business of Expertise: How Entrepreneurial Experts Convert Insight to Impact + Wealth, David C. Baker describes the book's three core ideas: expertise helps you find patterns in data; those patterns can be turned into a distinctive positioning with few close substitutes; and confidence in that positioning grows as the market accepts its application.

For a small studio, the practical conclusion is more modest than the promise of "finding a profitable niche": write down which recurring problems the team has already seen, which solutions it can justify with evidence, and what signals will tell it that clients need exactly this kind of help.

Baker also stresses the difference between strategy and execution. A studio may implement solutions well and still have no automatic right to call itself a strategic adviser if it cannot demonstrate the quality of its diagnosis. Conversely, strong judgement does not mean the team has to carry out every technical step itself.

In The Win Without Pitching Manifesto, Blair Enns urges experts to specialise, start with diagnosis, discuss money early, choose the right work and not solve the whole problem before being paid. These are principles for selling an expert creative service; they do not prove that specialisation will automatically increase revenue or that every client should pay for the same discovery stage. Use them to build an honest conversation about the need and about the limits of unpaid work.

Narrowness has a price too. If most revenue depends on one client, one type of platform or a short-lived regulatory change, the studio may find itself with no accessible next market. Test a specialisation through conversations, repeat orders, willingness to pay for diagnosis and whether the team can maintain quality. Do not invent uniqueness in place of experience, and do not treat silence from a few prospects as proof that there is no market.

Sales and pricing begin with a conversation about risk

Diagnose before you prescribe, and do not sell unknown work as certain

The first conversation should establish what prompted the client to get in touch now, what consequences the problem has, what has already been tried, who will use the result and who will accept it. Then establish the constraints: deadlines, access, sensitive data, compatibility with existing systems, the budget range and the authority to approve changes. Present these questions as a way to avoid a mistaken proposal, not as a pressure technique.

Before writing a detailed architecture or building a demo, agree which level of work is being paid for. A short introductory call can determine fit and the next step. Discovery, a paid diagnostic stage, can end with a requirements map, options, risks, a range estimate and an acceptance plan, without obliging the client to buy the implementation. If uncertainty is still high, do not present a rough estimate as a guaranteed price. Say which assumptions could change the estimate and what you need to learn before you promise a deadline.

Worked example 1: a full free pitch versus a bounded diagnosis. An illustrative studio receives four enquiries about an agent for processing orders. For each one, the owner prepares an eight-hour solution design before the client decides whether to buy the work. For internal calculation, an hour of the founder's time costs €80: this is the full cost rate of their time, not a market fee. Four proposals take 4 × 8 × €80 = €2 560 and 32 founder hours. One enquiry becomes a project; the other three never reach payment. The €2 560 of sales work stays on the cost side; the fact that the team "won" one client does not pay back the time spent on the other proposals.

An alternative illustrative process: for each enquiry the studio spends one hour on a conversation about fit and risks. That is 4 × 1 × €80 = €320 to qualify all four enquiries. Only one enquiry is a fit, and the client buys a separate six-hour diagnosis for €1 200. Its delivery cost is 6 × €80 + €120 of allocated operating costs = €600, so €600 remains after the cost of delivery itself, before sales time is counted. If, to evaluate this single sale, you assign all €320 of qualification time to it, €280 remains after both items, and the cost of the other three enquiries brings in no revenue. An internal management report may show the €320 separately as the overall cost of acquisition; the allocation rule must not make that time free. The client receives a result that is useful on its own: a definition of the problem, tested assumptions, possible options, risks and acceptance criteria. Further development has a separate budget and may be given to the studio or to another team. This does not prove that paid diagnosis will always improve conversion; it makes the price of the work and the parties' choices visible.

Discussing money early helps reveal whether expectations and budget are aligned. Declining can also be the right recommendation: if the problem lies outside the studio's competence, the studio should name that boundary rather than sell confidence it does not have. The amount of unpaid pre-sales work can be larger for a simple, repeatable order and smaller for an unfamiliar, high-risk system.

Price should reflect scope, value and who carries the risk

A cost is a resource used to do the work. A price is the agreed sum the client pays for a specific promise. Value is the benefit the client expects, taking into account their alternatives, uncertainty and the limits of the team's influence. Profit is what remains of revenue after defined costs. Do not substitute one for another: a low cost of running the agent does not prove the product is valuable, and a large effect the client expects is not permission to charge an arbitrary price.

A value-aware approach starts by asking what the solved client risk is worth compared with the alternatives, how measurable the result is and what exactly the studio controls. It is a way to argue for a price and a choice of scope, not a guarantee of the client's income or a right to claim a share of their future revenue. If the result depends on the client's staff, market, product pricing or the actions of another supplier, state those dependencies explicitly. Enns's slogan "charge more" is no substitute for evidence of competence, a transparent scope and the client's agreement.

The payment model changes how risk is distributed:

  • Time and materials: the client pays for agreed hours and direct costs. This can suit research-heavy work whose requirements are clarified along the way; the client carries the risk of a variable number of hours. Reduce the uncertainty with budget caps, short stages and regular reviews of priorities.
  • Fixed price: the parties agree on a defined result and a sum. The client gets a predictable budget, and the studio takes on the risk of underestimating its own delivery. This needs explicit assumptions, acceptance criteria and boundaries for changes, support and external costs; a change in the request goes through a separate approval.
  • Productised service: the client buys a bounded package with predefined conditions, deliverable, price and method of delivery. Reusing methods can lower the cost of delivery, but a package does not fit every system. Define in advance which data, platforms, volume and exceptions make an order eligible.
  • Retainer or support: the client pays for availability, regular work or a defined volume of support in a period. Specify the response time, hours per month, the escalation procedure, overage rates, access rights, changes outside the agreed list and whether unused hours roll over. The word "retainer" by itself does not mean unlimited work.

An estimate, a proposal, a budget and a contractual promise represent different degrees of certainty. An estimate gives a range under known assumptions. A budget can be a planning limit. A proposal describes the scope and commercial terms. An agreed promise must be specific enough for both parties to know what "done" means. Legal wording and accounting rules depend on the contract and local requirements; where needed, they are agreed with a qualified professional.

Worked example 2: the same basic task in three pricing formats. A client asks for a web order form to be connected to a supported customer-management system. The standard teaching scope: one form, one system, up to five fields, error checking, one launch and a handover of instructions. Later data migration, custom authentication and unknown order-processing rules are not part of the baseline assumption.

For comparison, the studio estimates the full cost of exactly this standard project:

Cost item Calculation Amount
Diagnosis and founder review 8 h × €80 €640
Engineer implementation 30 h × €50 €1 500
Service costs, testing and infrastructure illustrative direct amount €200
Share of rent, administration and software illustrative overhead allocation €500
Reserve for agreed fixes and support expected full cost €200
Full cost in the example sum of rows €3 040

Under time and materials, the founder's rate is €130/h and the engineer's €85/h. The invoice comes to 8 × €130 + 30 × €85 + €200 = €3 790. After the full cost, €3 790 − €3 040 = €750 remains; that remainder is €750 / €3 790 ≈ 19.8% of the invoice. If the actual engineering time grows, the client's invoice and the costs rise together within the agreed rules; the client needs budget checkpoints.

At a fixed price of €4 700 and the same expected costs, €4 700 − €3 040 = €1 660 remains; that remainder is €1 660 / €4 700 ≈ 35.3% of the price. If, because of the studio's estimation error, another 20 engineering hours are needed at an internal cost of €50/h, the additional cost is €1 000. Without an agreed change of scope, the remainder falls to €660 (€4 700 − €4 040), or about 14.0% of the price. If, on the other hand, the client's request itself changed, first agree the new boundary, deadline and price, rather than hiding the change inside the same promise.

A productised package might cost €2 600 if the task passes the eligibility check and the team uses a repeatable route. For this package, the founder's work is 3 × €80 = €240, the engineer's 10 × €50 = €500, service costs €80, overhead €250 and the support reserve €100. The cost is €1 170 and the remainder €2 600 − €1 170 = €1 430, or 55.0% of the price. It is not the same deal if the client needs legacy data migrated or a non-standard integration: such a requirement either fails the package criteria or is estimated separately. A higher calculated remainder does not guarantee sales, and standardisation must preserve quality and the team's learning.

The percentages in this example are a teaching ratio of what remains after all the listed costs to the price; this is not the standard gross margin, because the calculation already includes overhead and the support reserve. Other teams may classify direct and overhead costs differently. Write down your own rule and apply it consistently; do not compare percentages whose denominators and accounting methods differ.

Scope changes and support need separate agreements

In the proposal, record what the client provides, what the studio does, how review works, how many rounds of fixes are included, how new requirements are approved, who is responsible for accounts and external bills, and who responds after release. Do not reduce acceptance to "the client likes it": name visible criteria, for example "for a valid order, one record with the agreed fields is created; for an invalid one, no record changes and the owner receives a clear message".

Discovery is better paid for separately when the right scope cannot be determined without examining the data, environment or rules. Support after completion is also separate work: fixing a defect within the agreed boundary may fall under the warranty arrangement; a new feature or a change to an external application programming interface (API) does not, unless the parties agreed otherwise. Clear boundaries reduce surprises on both sides and make it possible to forecast capacity honestly.

Delivery economics count people's work and money over time

Separate revenue, costs, remainder and cash flow

For any single calculation, fix the period, the currency and the rule for allocating time. In this unit, revenue means the amount for work completed and accepted in the teaching example; actual revenue recognition in accounting depends on policy and contract. Direct delivery costs are the people's time and technical resources without which the specific work cannot be delivered: implementation, architecture, testing, review, models, tools, infrastructure and agreed fixes. Overhead supports the studio as a whole: sales, bookkeeping, non-project administration, the working environment and internal systems. Gross profit, in this simplified model, is revenue minus direct costs, and gross margin is that remainder divided by revenue.

What remains after overhead is the operating result, not necessarily the owner's net profit: there may still be depreciation, financing costs, taxes and other items. Cash flow shows when payment actually arrived and when the studio paid its bills. An issued invoice is not money received, and a positive result in a report does not guarantee funds in the bank today. Taxes and formal revenue recognition depend on the country, the form of business and the contract; we do not determine them for any specific company here.

The founder should log time spent on sales, diagnosis, task framing, architecture, directing the agent, review, fixes, support, training and administration. If the founder does not receive a salary for separately tracked hours, that does not mean their time is free. For internal calculation, use a reasonable replacement cost for that work or another consistent management rate; do not add it a second time if the same work is already counted in pay or overhead.

Worked example 3: four projects and an empty till at month end. An illustrative studio accepted four orders at €8 000 each: revenue for completed work is €32 000. Direct labour by the delivery team cost €12 000; the founder logged 48 hours of architecture and review at an internal rate of €80/h (48 × €80 = €3 840); and external services, models and infrastructure cost €720. Direct costs are €12 000 + €3 840 + €720 = €16 560. Gross profit is €32 000 − €16 560 = €15 440, and gross margin is €15 440 / €32 000 ≈ 48.3%.

In the same month, overhead came to €6 000. The illustrative operating result before taxes and financing items is €15 440 − €6 000 = €9 440. However, clients paid only two invoices of €8 000. Cash in was €16 000, while the studio's bank payments were €12 000 to the delivery team, €720 to external services and €6 000 of overhead: €16 000 − €18 720 = −€2 720 before any payments to the owner and taxes. Another €16 000 is still awaiting payment. The internal valuation of the founder's time (€3 840) is included in the cost even though no money for it left the account this month. Had the founder received a salary or fee, it would show up as a real cash outflow according to the company's accounting.

The point of the example is not that the studio is loss-making, nor that invoicing should be replaced with prepayment in every contract. It reveals two different management problems: whether the work pays for itself after all costs, and whether the timing of incoming payments matches outgoing ones. The team chooses advance or milestone payment terms, a liquidity reserve and a debt-collection procedure with the client, the contract and local rules in mind.

Utilisation is not a goal in itself

Maister shows that the same financial result can arise in different ways: through more billed hours, a higher rate, a better margin or a different team composition. In his article on firm results, he calls some of these factors "hygiene" and others the long-term health of the practice; he also warns that growth in volume does not by itself guarantee higher profit per partner. These measures were formulated for professional firms; a small studio can learn from their logic of cause and effect, rather than adopting their structures or benchmarks as a ready-made standard.

In the publisher's available excerpt from the third edition of Peopleware: Productive Projects and Teams, DeMarco and Lister distinguish being present at work from focused working time. They criticise timesheets that force people to add up hours without distinguishing meaningful work from interruptions, calling them an unreliable source for assessing productivity. Their excerpt is not a universal utilisation benchmark for every studio. Do not turn the flow-time ratio the authors mention into a target, and do not use billable utilisation as a basis for individual bonuses without context.

Worked example 4: the founder reviews everything personally. In the previous example, the founder's 48 hours went on four reviews, 12 hours per project. The studio trains a colleague to do the first review pass: 6 hours per project at an internal rate of €50/h. The founder keeps 3 hours of review per project at €80/h and spends 8 hours on initial training.

Component Before After delegation
Founder review 4 × 12 h × €80 = €3 840 (48 h) 4 × 3 h × €80 = €960 (12 h)
Colleague's first review — 4 × 6 h × €50 = €1 200 (24 h)
Initial training — 8 h × €80 = €640 (8 h)
Total cost €3 840 €2 800
Founder time 48 h 20 h

The calculated saving in the first month is €1 040.

The result depends on assumptions: the colleague really has the time; quality does not drop; fixes and support do not increase; and €50/h correctly reflects the colleague's full internal cost. The founder's freed 28 hours are capacity, not revenue. They become profit only if the studio does useful work with them, can sell that work, deliver it without creating a new queue and get paid. Handing work over without training and review may merely postpone a more expensive mistake.

Agent costs must be counted up to the accepted result

The full cost starts with a usage log

A token is a piece of text or other model input that the model processes. What matters on the bill is not only input and output tokens, but also context that is sent again, cache writes and reads, the number of calls, retries, parallel workers and paid tools. A tool with its own price can add a separate charge on top of tokens, and its results can enlarge the input context. Do not assume that two agents with the same name consume the same resources per task.

Store data by client and by task: project identifier, model and version, instruction revision, context size, input/output/cached tokens, paid tool calls, retries, duration, environment costs and the evaluation outcome. For every change, also count the human minutes spent on review, fixes, escalation and expected support. Records should contain the minimum necessary data; do not store access secrets or private client data in logs just for the sake of costing.

Two useful formulas:

Full cost of an accepted task = cost of all model calls and retries + tools and external APIs + environment, continuous integration (CI), storage and hosting + people's time for evaluation, review and fixes + expected support + a justified share of overhead.

Cost per accepted result = total costs across all attempts / number of results accepted under the defined criterion.

If clients accepted two out of ten runs, do not divide the bill only by the ten initial calls: count every attempt and the human work needed to fix the results. If a task has no accepted result yet, the numerator still exists, but the "cost per accepted result" is not yet defined.

Subscriptions, APIs and infrastructure bills are separate items

A subscription to a consumer product and API usage can have different capabilities, limits, rules and bills. For example, OpenAI's help centre explicitly separates billing for ChatGPT from billing for the API Platform. Do not put zero API cost into your cost model just because the founder has a subscription to a consumer product; equally, do not turn the cost of an entire company subscription into a single project's bill without a clear allocation rule.

The full cost is also affected by network requests, a search index, storage, a deployment service, an external database, a code execution environment and CI job runners. For GitHub Actions, the general rules depend on the repository type, the plan and the runner type: the official documentation distinguishes free use of standard GitHub-hosted runners in public repositories and of self-hosted runners from possible charges for private repositories beyond the included quota. Check your own usage records page rather than multiplying minutes by someone else's rate.

Worked example 5: retries, the model and review change the cost of an accepted result. Let us compare two illustrative ways of completing the same set of ten tasks with the same acceptance criteria. The usage counters and human time below are invented for this teaching calculation: they are not measurements of real models, a forecast of their quality or a benchmark. You can replace them with data from your own controlled run.

The table gives OpenAI's standard short-context rates, checked on 10 October 2026, per million tokens:

Model Standard input Cached input Cache write Output
gpt-6-luna $0.10 $0.01 $0.125 $0.50
gpt-6-sol $2.00 $0.20 $2.50 $10.00

Fast mode, Batch/Flex, long context, taxes, contractual discounts and regional surcharges are not included. Built-in web search is charged separately in both scenarios at $10 per 1 000 calls; the text of the returned results is billed at the model's rate and is included in the standard input tokens.

Component for ten accepted tasks Luna scenario: 14 attempts Sol scenario: 11 attempts
Standard input 1.70M × $0.10 / M = $0.17 1.20M × $2.00 / M = $2.40
Cached input reads 0.30M × $0.01 / M = $0.003 0.20M × $0.20 / M = $0.04
Cache writes 0.20M × $0.125 / M = $0.025 0.10M × $2.50 / M = $0.25
Output 0.28M × $0.50 / M = $0.14 0.15M × $10.00 / M = $1.50
Model tokens $0.338 $4.19
Built-in web search 30 / 1 000 × $10 = $0.30 20 / 1 000 × $10 = $0.20
Model and paid tools $0.638 $4.39
Human review of attempts 14 × 12 min / 60 × $60 = $168 11 × 8 min / 60 × $60 = $88
Fixing the ten accepted tasks 10 × 15 min / 60 × $60 = $150 10 × 6 min / 60 × $60 = $60
Support reserve 10 × 3 min / 60 × $60 = $30 10 × 3 min / 60 × $60 = $30
Direct costs in the example, excluding overhead $0.638 + $168 + $150 + $30 = $348.638 $4.39 + $88 + $60 + $30 = $182.39
Accepted tasks 10 10
Direct cost per accepted task $348.638 / 10 = $34.86 $182.39 / 10 = $18.24

In both columns, ten results passed the same criterion within the illustrative scenario, but that is a given assumption, not evidence that one model on average needs fewer attempts or less review. Here Sol's tokens are more expensive, yet human time and total direct cost are lower in the assumed scenario; on real tasks the relationship could be the opposite.

The human labour rate of $60 per hour is an illustrative full internal cost. A separate CI runner, storage, hosting, a paid external database and a share of studio overhead are not included. Compare, on representative tasks, the number of results that passed acceptance, the number of attempts, human review, fixes, latency and the bill; do not draw conclusions from a single token price.

To choose a plan today, open the specific provider's price list and check the model, mode, context window, caching, tools and unit of measurement. Anthropic's pricing page, for example, separately describes tool tokens and additional costs for some server-side tools; one provider's figures do not carry over to another. OpenAI likewise documents that API usage may be billed separately for tokens, tools and storage. Rates change, so for an estimate keep the date you checked them, and after launch keep the actual usage data.

Optimise for the accepted result, not the cheapest call

It is often cheaper to select the right context, stop re-reading unchanged materials, cache a suitable prefix or use a script for deterministic checks. But a shorter prompt can drop a necessary source, a cheaper model can increase the number of retries, and parallel agents can double the cost of the same research. Evaluate changes on representative tasks, as described in agent evaluation: the quality of the accepted result, risks, the number of fixes, latency, technical cost and human time.

Before a run, set the permitted budget per task, the number of retries, the stopping conditions and the escalation threshold. The counter should stop an infinite loop, and the agent should report that it has hit the limit instead of quietly generating extra costs. Do not give the agent permission to raise a spending limit or change the payment method just because its task exceeded the budget.

Distinguish alerts from limits. OpenAI's help centre separately describes spend alerts, which notify you about usage, and configured hard spend limits, which can stop requests. An organisation-level limit and a project-level limit can apply at the same time.

For some paid usage-based products, GitHub lets you enable stopping usage once a budget limit is reached. Without that option, a budget may only send notifications while usage continues. Check the specific configuration and the billing delay: the word "budget" alone does not prove that spending will stop.

A provider's dashboard helps reconcile API usage by model and project with the bill. OpenAI specifically warns that detailed usage statistics may differ slightly from the data of the Costs endpoint, which it recommends for financial reconciliation with the invoice. For internal accounting, link the external bill to your own task log rather than replacing the bill with an estimate built from tokens.

Sources and further reading

Expertise, services and specialisation

  • David H. Maister, Managing the Professional Service Firm, Free Press, 1993. Checked the official Simon & Schuster page and the available excerpt of the first chapter; the full text of the book was not reviewed. Accessed 25 September 2026. Publisher and excerpt.
  • David H. Maister, "The Anatomy of a Consulting Firm", the author's article on different types of services and their economics; page checked 25 September 2026. This is an online article, not the full text of a book.
  • David C. Baker, The Business of Expertise: How Entrepreneurial Experts Convert Insight to Impact + Wealth, RockBench. Checked the author's official page and the publisher's listing, including the description of the main ideas; the publisher's page lists a hardcover but gives no year or edition number. The downloaded sample could not be read, and the full text was not reviewed. Accessed 25 September 2026. Author's page; RockBench publisher page.
  • Blair Enns, The Win Without Pitching Manifesto, RockBench, first edition 2010. Checked the author's page with the twelve principles and a conversation with Enns about publishing the book; the full text was not reviewed. Accessed 25 September 2026. The twelve principles; conversation about publishing the book.

Sales and pricing

  • Blair Enns, The Win Without Pitching Manifesto, RockBench, first edition 2010; the author's page with the principles of specialisation, diagnosis before prescription, early money conversations and limits on solving problems for free. Checked 25 September 2026; the full text of the book was not reviewed. Author's page.
  • David C. Baker, The Business of Expertise: How Entrepreneurial Experts Convert Insight to Impact + Wealth, the author's and publisher's official description of patterns, positioning and testing demand. Checked 25 September 2026; the full text of the book was not reviewed. Book page.
  • David H. Maister, "Responding to Fee Pressure", the author's article on productivity, pricing and the conditions for results-based fees. Checked 25 September 2026. Maister article.

Delivery economics and utilisation

  • David H. Maister, "Results and Rewards in the Multi-Group Firm", the author's article on margin, rates, utilisation, team composition and balanced results. Checked 25 September 2026; the claims are used as a conceptual caution, not as a benchmark for small studios. Maister article.
  • Tom DeMarco and Tim Lister, Peopleware: Productive Projects and Teams, 3rd edition, Addison-Wesley Professional, 2013/2014. Checked the publisher's page and the free excerpt of chapter 10 (pages 63–70) on time reporting, interruptions and focused work; the full text was not reviewed. Accessed 25 September 2026. Pearson page; publisher's excerpt.
  • David H. Maister, Managing the Professional Service Firm, Free Press, 1993. Publisher's page and the available excerpt of the first chapter; the full text of the book was not reviewed. Accessed 25 September 2026. Simon & Schuster.

Agent and infrastructure costs