Build, buy or hire: contracts by how clear the scope is

Every piece of a project's work can be built by the team, bought ready-made or hired out to a contractor or freelancer. The choice is made per piece, not once for the whole project.

A simple rule covers most cases. Build what is core to the business and will keep changing, because the people who build it will maintain it. Buy what already exists as a product: there is no reason to rebuild a solved problem. Hire for clear, bounded pieces the team can't do well itself.

The most useful question is who will maintain it after launch. At Klasna the diagnostic test was built: Danylo's team will keep tuning it every week once real learners use it. Video rooms for live lessons are bought: a solved problem Klasna already pays for. The 120 practice-set diagrams were hired out: a fixed list of problems in an agreed style, which doesn't change weekly. Platform work whose size nobody knew was hired too, but on different terms, as the next cards show.

The contract type should follow how clear the scope is before work starts.

A fixed price pays an agreed sum for an agreed result. It suits work whose scope and acceptance criteria are clear up front, and then the contractor carries the risk of extra effort. At Klasna the illustrator was paid a fixed price: 120 diagrams at 450 UAH, 54,000 UAH in total, in three batches of 40. It worked because the problems, the style and the file format were known.

With an unclear scope, a fixed price backfires. The contractor either pads the price to cover what nobody knows, or treats every clarification as a change and renegotiates. Klasna pays for the uncertainty either way, often more.

Time and materials pays hours at an agreed rate. It fits work whose size is still being discovered, like the platform's booking by subject in November. The risk of growth now sits with the buyer, so it needs limits, covered in the next card. Neither type is always safer: each is safe for one kind of scope.

When the scope is unclear, time and materials is the honest contract: Klasna pays hours at an agreed rate and accepts that the work may grow. Because the buyer now carries that risk, two limits make it manageable.

A cap sets the most the work can cost without a new decision: for example, a number of days or a sum, after which the contractor stops and the project lead decides whether to continue. It turns open-ended growth into a checkpoint. A weekly check of what was delivered shows progress in working pieces, not hours logged: what can be tried on the test site this Friday. Hours tell you what was spent; delivered work tells you what was bought.

Without these limits, time and materials becomes a blank cheque, and nobody notices growth until the invoice. With them, it gives the flexibility unclear work needs and keeps the project in control. Paying everything up front fails both ways: nothing is tied to delivery and acceptance stays undefined.

To compare bids fairly, score them on a few weighted criteria decided before the bids arrive. Each criterion gets a weight (the weights add up to 100%) and a written direction: what earns a 5. For Klasna's 40 diagrams: quality 40%, price 30% (5 = the lowest), date 20% (5 = the earliest), revisions included 10%.

The direction looks obvious until someone scores price by size and the dearest bid wins. Written down, two people score a bid the same way.

The mechanics: apply the gates first (next card), then for each remaining bid multiply each score by its weight and add. With a gate of quality at least 4, bid B (quality 3, price 5, date 5, revisions 2) is out despite its weighted 3.9. Bid A: 0.4 × 5 + 0.3 × 2 + 0.2 × 3 + 0.1 × 4 = 3.6. Bid C: 0.4 × 4 + 0.3 × 4 + 0.2 × 3 + 0.1 × 3 = 3.7. C wins: the best quality alone doesn't decide, the balance does.

Some requirements aren't trade-offs: without them the work is useless, however cheap or fast. These are gates, checked before any scoring. A bid that fails a gate is out; weights then rank only the bids that passed.

For Klasna's diagrams, correct physics is such a requirement. Suppose it were a weight instead, even a big one like 50%. A bid with wrong physics but the lowest price and the earliest date could still collect enough points to win, and Klasna would pay for diagrams that teach the wrong thing. As a gate it can't happen: a two-diagram sample with a wrong arrow is out.

Keep gates few and checkable: correct physics in the sample, Ukrainian labels, an editable vector file, a delivery date before Vira's deadline. Everything that can genuinely be traded against something else, such as more quality for more money, belongs in the weights. Mixing the two is the most common way a scoring table picks the wrong winner while looking objective.

The safest payment rule with any contractor is to pay for accepted deliverables, not for hours or promises. Acceptance criteria written into the contract make "done" checkable by both sides, and payment follows the check.

At Klasna the illustrator's contract listed Vira's checks: each diagram matches its problem, Ukrainian labels, an editable vector file. Batch two came with six wrong arrows; Klasna paid once they were fixed.

For the new order of 40 diagrams, split the work into two batches of 20, each paid after Vira's check. A small advance can be fair for a freelancer who reserves time, but most of the money stays tied to accepted work: half up front, or one payment at the very end, removes the checkpoints. And acceptance needs a named signer: Hanna pays against a batch signed by a named person in an agreed place, not a chat message saying "looks fine". The same rule protects the freelancer, who knows exactly what earns each payment.

Hiring a contractor follows a short sequence, and each step needs the one before it:

1. Decide that this piece is hired, not built or bought.
2. Write the scope and acceptance criteria: what exactly, and how "done" will be checked.
3. Choose the contract type from how clear that scope is.
4. Send the request with weighted criteria, their directions and the gates.
5. Apply the gates, then score the bids that pass.
6. Sign and pay per accepted batch.

The order isn't bureaucracy; it prevents specific mistakes. You can't pick a contract type before you know how clear the scope is. You can't score bids fairly before the request says how you'll score. Gates come before weights so a cheap but unusable bid never wins. Payment comes last because it follows acceptance.

At Klasna there's one more point: from 1 February physics is operations, so Vira owns the April order and pays from the operating budget, not the project's 600,000. The project's job is to leave her this sequence as a template, not another task.

A request for proposals is a short document that tells possible suppliers what you need and how you will choose.

It says: the scope (the list of problems, the style) and the deadline; how each piece will be checked before acceptance; the contract type and payment (fixed price per accepted batch); the weighted criteria with what earns a 5 for each; the gates; a request for a two-diagram sample, the cheapest quality check before signing; and the date of the decision, so nobody waits forever. At Klasna the April mock exams start on 5 April and Vira needs the diagrams by 20 March to check them.

Two things stay out. Other bidders' prices are confidential, and sharing them turns the request into an auction. And a request to start drawing before anything is signed is unfair to the freelancer and leaves acceptance undefined.

How it fits together: decide per piece, match the contract to the scope, compare bids with gates and directed weights, and pay for accepted work. The next lesson covers the handover: who runs physics from Monday, and with what.