Kumu / Micro/Macro Econ / Perfect Competition
Perfect Competition — Decision Analysis
You are a farmer on a 1.5-acre market garden. Sixty-four beds, one pair of hands, and the budget for up to four temporary workers. In a few weeks you have to commit the entire season to a planting plan — tomatoes, carrots, mesclun, in some combination — and you cannot undo it in July. Nobody will tell you the prices; the farmers' market sets those. The only thing you control is what goes in the ground.
So you do what a consultant does with a decision that can't be taken back: write down what you think the answer is before you look, build the model that can prove you wrong, and then write the recommendation for the person who has to live with it — who, this time, is you.
The economics, briefly
A market garden selling into a farmers' market is a textbook price taker: it is far too small to move the price of a tomato, so the price it faces is simply given — a flat line, at any quantity it could plausibly grow. That single fact is what "perfect competition" means from the seller's side, and it collapses an enormous question ("what should we produce?") into a small one: keep planting while the next bed costs less than it earns, and stop. That rule has a name — P = MC — and it is the whole supply side of the model.
What makes it a real decision rather than an arithmetic exercise is that marginal cost does not sit still. Each extra bed of a crop makes every bed a little more labor-hungry — pest pressure, harvest bottlenecks, walking time — so cost per bed climbs as you plant more. You control three things and only three: how many beds of each crop go in. Everything else — prices, the season's length, the fixed costs, the caps on how much ground each crop can take — is handed to you. Your job is to find where rising cost meets a flat price, for three crops at once, under constraints that will stop at least one of them before the economics does.
The givens
Everything in the two tables below is handed to you: the prices the farmers' market sets, the ground you have, the hours you can put in the field, and how fast each crop punishes you for planting more of it. None of it is a decision. The only decision is how many beds of each crop go in — and these are the numbers that decision has to be defended against.
| Crop | Bed cap | Revenue / bed | Field hrs / wk / bed | Fertilizer / bed | Diminishing-returns rate |
|---|---|---|---|---|---|
| Tomatoes | 20 beds | $8,800 | 2.5 | $880 | 10% |
| Carrots | 20 beds | $2,094 | 0.833 | $440 | 2.5% |
| Mesclun | 30 beds | $2,700 | 1.25 | $880 | 1.25% |
The bed caps sum to 70 and you have 64, so you cannot max every crop — something has to give. Notice also that the crop paying the most per bed is the one whose labor requirement climbs fastest, which is exactly why "plant the expensive thing" is not the answer.
| The farm | What you are given |
|---|---|
| Season | 36 weeks |
| Fixed costs | $20,000 for the season |
| Beds available | 64 (across all crops) |
| Your own field hours | 720 hrs (implied $34.72/hr) |
| Temporary workers | up to 4, at $17.36/hr, 1,440 hrs each |
| Labor hours for q beds of one crop | Labor(q) = q × hrs/wk/bed × 36 × (1 + dim)q |
That last row is the engine of the whole case. Each extra bed multiplies the labor requirement
of every bed of that crop by (1 + dim) — which is what makes marginal cost
actually rise, rather than being asserted to. Two labor rates and one exponent are the entire
reason this is a model instead of a division problem.
What you'll be able to do afterwards
- Read P = MC off a table, off a chart, and out of an optimizer's answer — and explain why the highest-revenue product is not automatically the one to make more of
- Model diminishing returns as the thing that actually makes marginal cost rise, instead of asserting that it does
- Use MC vs AVC to settle the question that traps everyone: why it can be correct to keep producing something that loses money on its own
- Recognize a binding constraint, price what relaxing it would be worth (its shadow price), and turn that number into a recommendation someone can act on
- Build and document a constrained optimization model in Excel — decision cells, named ranges, constraints, GRG Solver — so that a stranger could rerun it
How the engagement runs
Three stages, each with its own page. Every stage follows the same rhythm — what you're doing, what you need to know, the work itself, the deliverable, and a check on whether it stuck. Every one of them commits into the portfolio repo, which is not built here: the workspace belongs to the course, gets stood up once, and is finished before this engagement starts. Stage 2 drives Excel's Solver, so if you have never opened it — or are working in Excel for the web, which does not have it — the Excel Solver page is ten minutes, once, and better spent now than in the middle of the build.
Repository first — that is Stage 0, and it belongs to the course
If you have landed here without a portfolio repo, stop and build it: Stage 0 sits at the top of the course page and takes one sitting. It has two parts — the GitHub account (plus the Git mechanics walkthrough, if GitHub is new to you) and then the workspace itself. Everything below assumes a repo you can commit and push to.
Engagement Brief
State the problem in your own words and commit a hypothesis — a specific mix, with economic reasoning — before you have run anything.
Spec, Build, Audit
Specify the model before it exists — inputs, logic, and the rules it must pass — then have AI build it from your spec and audit what comes back. There is no starter workbook. The published check figures become your acceptance criteria.
Report the Findings
Explain the answer with your own model's evidence, in figures and prose — then write the half-page memo that says what to plant, which ground to buy next, and what would change your mind.
Feel the model before you build it
The Farm Profit Lab is this exact model, with sliders
The Farm Profit Lab runs the same labor function, the same three crops, and the same optimizer. Predict the mix, drag the bed counts, and watch marginal cost cross the price line — then open the spreadsheet already knowing what every formula is supposed to produce. Twenty minutes here saves two hours of debugging later, and it is the fastest way to see the one thing in this model that surprises everyone.
Where AI fits, and where it doesn't
Use AI hard, and use it in the open. The line is the same in every stage of this engagement and in every other one this term:
| Good uses — log them | Yours alone |
|---|---|
| Explaining the economics until it actually clicks; quizzing you on MC, AVC, and the shutdown rule | The hypothesis, written before you optimize anything |
| Building the workbook from your committed spec; debugging what it returns; explaining a Solver setting | Writing the spec — and auditing the result against it |
| Critiquing your draft explanation and telling you where it's hand-waving | Writing the brief, the analysis, the memo, and the reflection |
Every AI-supplied number is a draft until you have checked it. That habit is the point of the prompt log — and it is the difference between using a tool and being used by one.