Contract or permanent designers: which should you hire?
Comparing a day rate to a salary produces a number that is almost always wrong and never decisive. A contractor at three times the daily cost of an employee can still be the cheaper option for a fixed piece of work, and the same contractor becomes ruinous as a permanent substitute. What actually decides it is whether the work has an end, and who is left holding the design system and the accumulated knowledge of your users afterwards.
When is a contractor clearly the right answer?
When the work is bounded and the output is transferable. A brand refresh, a design system build, a prototype answering a specific question, a discovery phase, a one-off audit, a burst of screens to unblock an engineering team with a deadline. All of these have a defined end, and hiring permanently for them leaves you with a role that has quietly changed six months later.
It is also right when you need a skill you will use once. Building an accessibility remediation plan, designing a first design system, or prototyping a hardware interaction all demand experience you cannot reasonably grow internally for a single project, and paying a specialist rate for four weeks is cheaper than a year of someone learning.
Contracting is the wrong answer for continuing product judgement. Design decisions on a live product depend on a large amount of undocumented context, and that context is expensive to rebuild every time a person rotates out. The cost of contracting is not the rate, it is the repeated cost of rebuilding context.
What does a permanent designer buy that a contractor does not?
Accumulated judgement about your specific users. After a year, an in-house designer knows which customers complain about what, which internal team will object to a change, which parts of the product carry revenue and which screens quietly break every quarter. None of that is in any document, and it makes their decisions faster and better in ways that do not show up in a portfolio.
They also absorb the unglamorous work that contractors are never asked to do: keeping the design system current, chasing down inconsistencies, reviewing what engineering actually shipped, updating the components when a browser changes behaviour. This maintenance is invisible until it stops, and then everything degrades slowly.
The third thing is the ability to say no. An employee can refuse a bad request and argue for a fortnight. A contractor on a renewable engagement is structurally weaker in that argument, and while good ones push back anyway, do not build a process that relies on it.
How do the options actually compare?
Cost per day is the least useful column. Compare on time to usefulness, what happens to the design system, and what you are left with when the arrangement ends.
| Option | Time to useful | Owns the system? | What you keep at the end |
|---|---|---|---|
| Permanent designer | Four to eight weeks | Yes, if given the time | Everything, until they leave |
| Long contractor, six months plus | Two to four weeks | In practice yes, on paper no | Files and a gap in judgement |
| Short contractor, under eight weeks | Days, if scoped tightly | No | A defined deliverable, if you specified one |
| Design agency or studio | Days, they bring a process | No, and their system is not yours | Polished output, thin internal understanding |
| Fractional design lead | Immediately for direction | Sets direction, does not maintain | Standards and hiring decisions, not screens |
What breaks when a contract design engagement ends?
The system stops being maintained, usually silently. Design systems decay through small additions rather than large ones: a slightly different card, a one-off spacing, a new colour for a specific screen. A departing contractor leaves a system that was consistent on the day they left, and six months later nobody can say what the rules were.
The second thing to break is the rationale. Files record what was decided, not why. When the person who knows that the two-step confirmation exists because customers were double-ordering leaves, the next person removes it as friction, and the double-orders come back. Requiring short written rationale for the non-obvious decisions is the cheapest insurance available, and it is almost never in the contract.
Third, whatever was in progress gets finished by someone with less context. Plan the last two weeks of any design engagement as handover rather than delivery, and expect to defend that time, because it always looks like the moment to squeeze in one more screen.
What should be in a design contract that usually is not?
Source files and ownership, stated explicitly. Design work commonly lives in a tool account owned by the contractor, and teams discover after the fact that their files are in someone else's workspace, alongside licensing questions about fonts and stock imagery bought under the contractor's licence rather than yours.
Fonts deserve their own clause. A typeface licensed for a contractor's design work is frequently not licensed for your web traffic or your application, and this surfaces at launch when someone reads the licence properly. Settle who buys which licence, for what volume, before the design is finished.
Then the deliverable definition. Not screens, which is a quantity, but states: for each flow, the empty, loading, error and permission-denied cases. Contracts specified in screens produce happy paths, and the missing states get invented by engineers under time pressure, which is where most inconsistency in shipped products comes from.
What is the sensible default?
One permanent designer as early as you can justify it, then contractors around them for bursts and specialisms. That structure keeps ownership and continuity in the building while letting you buy depth you do not need year-round. It also gives contractors someone to hand back to, which is the difference between a useful engagement and a delivery of files.
If you cannot yet justify a permanent hire, the next best structure is one long-running contractor with continuity, deliberately treated as though they were staff for the purposes of context, plus written rationale as a standing requirement. It is more expensive per day and considerably cheaper than rotating three people through the same product.
The arrangement to avoid is a series of short engagements with no internal owner. Each new contractor re-litigates decisions the last one made, the system forks, and the product acquires layers that look like the work of five different companies, because it is.
Common questions
- Should I hire a contract or permanent designer?
- Contract suits bounded work with a transferable output: a brand refresh, a design system build, a discovery phase, a prototype answering one question, or a burst of screens against a deadline. Permanent suits continuing product judgement, because decisions on a live product depend on undocumented context about users, internal politics and which screens quietly break. The deciding factor is whether the work has an end, not the day rate.
- Are contract designers more expensive than employees?
- Per day, yes, and that comparison rarely decides anything. A contractor at several times the daily cost of an employee can be cheaper for a fixed piece of work with a defined output, while the same person is poor value as a permanent substitute. The real cost of contracting is the repeated expense of rebuilding context each time someone rotates out.
- What happens when a design contractor leaves?
- The design system stops being maintained and decays through small additions nobody governs, and the rationale for non-obvious decisions disappears because files record what was decided rather than why. Work in progress is finished by someone with less context. Plan the final two weeks of any engagement as handover, and require short written rationale for decisions that would look like friction to a newcomer.
- What should a design contract include?
- Explicit ownership of source files and the account they live in, since design work often sits in a workspace the contractor owns. Font and stock imagery licensing, because a licence bought for design work frequently does not cover your web traffic or application. And a deliverable defined by states rather than screen counts, covering empty, loading, error and permission-denied cases for each flow.
- What is the best mix of permanent and contract designers?
- One permanent designer as early as it can be justified, with contractors around them for bursts and specialisms. That keeps ownership and continuity internal while allowing you to buy depth you would not use year-round, and it gives contractors someone to hand back to. The arrangement to avoid is a run of short engagements with no internal owner, which forks the system and produces a product that looks like five companies built it.
