Retainer or Fixed Project for Exhibition Software?

Most exhibition organisers don't think hard about contract structure until they're already locked into the wrong one. By then, the symptoms are familiar: a fixed-price project running out of scope three weeks before the show, or a retainer burning through hours on work that should have been a one-off deliverable.\n\nThe good news is the decision isn't complicated. But it does require being honest about where you are in your build.\n\n## What you're actually choosing between\n\nA fixed-price project is a scoped, bounded piece of work with an agreed deliverable, timeline and cost. You get a defined outcome. The studio carries the risk if the build takes longer than quoted — in theory. In practice, the risk only stays with them if your scope stays put, which it rarely does once a real show looms.\n\nA retainer is ongoing access to a team's capacity, typically billed monthly against an agreed number of hours or sprint cycles. You direct the work week to week. Scope can shift. The studio isn't carrying the overrun risk — you are, though you also get the flexibility that comes with it.\n\nNeither model is inherently better. The right one depends on what you're building, how well-defined it is, and whether you're in initial delivery or ongoing product ownership.\n\n## When a fixed project is the right call\n\nIf you're commissioning exhibition software for the first time — a registration system, an exhibitor portal, a floor-plan tool — and you can write down what done looks like, start with a fixed project. The discipline of scoping forces clarity. You'll know what's in, what's out, and what triggers a change order.\n\nThis matters more than most organisers expect. A 200-stand trade show with three people on the registration desk has genuinely different requirements from a 60-stand hosted-buyer event with a VIP matching layer. Scoping those before you start isn't overhead — it's the only way to get a quote that reflects what you actually need.\n\nFixed projects also work well when the software is a one-time migration or integration: pulling legacy exhibitor data into a new CRM, building an API bridge between your floor-plan tool and your badge printer, or producing a custom reporting layer on top of a platform you already own. The work has a start and an end. Once it's done, it's done.\n\nThe honest trade-off: fixed-price contracts get expensive when you change your mind. Every scope addition becomes a negotiation. If you expect requirements to evolve mid-build — and with exhibition software they almost always do, because the first show reveals problems you didn't know you had — a fixed contract will grind against that.\n\nSee What a UK MVP Actually Costs — and What Drives It Up for a breakdown of what actually inflates fixed-price quotes before you sign.\n\n## When a retainer makes more sense\n\nYou've shipped the first version. The core is live. Real exhibitors have used it and your team has a list of things that need changing before the next show. This is when the fixed-project model starts to chafe.\n\nChange requests under a fixed contract require re-scoping, re-quoting, and sometimes re-contracting. Each round takes days. If a show is eight weeks out and three things need fixing before registration opens, you don't want to spend a week negotiating a change order — you want the team to pick it up on Monday.\n\nA retainer solves that. You're buying capacity, not a specific deliverable. The team knows your system, your show calendar, and what a typical cycle looks like. They can pull in a high-priority fix, ship it to staging, and have it live within a sprint without anyone writing a new statement of work.\n\nRetainers also suit organisers running more than one event format — a hosted-buyer conference, a public trade show and a roadshow series, each with slightly different registration requirements. The surface area of the software changes throughout the year. Maintaining it on a project basis would mean constantly re-engaging, re-briefing, and re-testing context the team already has.\n\nThe trade-off is accountability. Without a defined deliverable, it's easy for retainer hours to drift into meetings, minor tweaks, and exploratory work that doesn't move the needle. You need to run the engagement actively — set priorities at the start of each sprint, review what shipped, and push back when the hours don't match the output. Studios that work well on retainer will expect this rigour from you.\n\nDiscovery Theatre Is Costing You the Build covers how vague engagement structures inflate hours without producing working software — worth reading before you sign either model.\n\n## The hybrid approach most organisers end up on\n\nIn practice, the cleanest path is to start with a scoped, fixed-price MVP to get the core system live, then move to a retainer once you're past the first show and know what the real maintenance and iteration load looks like.\n\nThis isn't a novel structure — most studios offer it. The MVP phase gives you certainty on the initial build cost. The retainer phase gives you flexibility on what comes next. The transition point is usually after two or three events, when you have enough real usage data to know what's actually worth improving and what you thought would matter but doesn't.\n\nOne thing to negotiate upfront: what happens to the code if you end the retainer? IP assignment, documentation standards, and handover terms matter more on an ongoing retainer than on a one-off project. Make sure these are in the contract before you start, not after you want to switch studios.\n\nWhat Goes Into a Software Development Brief That Actually Gets Built has a section on IP and handover terms worth reviewing before you brief any studio.\n\n## Red flags in how each model gets sold\n\nFixed projects get mis-sold when a studio quotes a low number to win the work, then expands scope through change orders once you're committed. The tell: a quote that doesn't include a detailed feature list or defined exclusions. If you can't see exactly what's in and out, the quote is a placeholder, not a price.\n\nRetainers get mis-sold when a studio pitches flexibility but doesn't provide sprint reporting, velocity tracking or any mechanism for you to verify what's being built. A retainer without output visibility is a subscription to a black box. Ask to see examples of sprint summaries and a sample retainer agreement before you sign.\n\nAI-assisted delivery is changing how studios work, but it doesn't eliminate either of these risks. A studio using AI to accelerate scaffolding and spec generation can still pad a retainer or under-quote a fixed build. The contract structure still determines your exposure.\n\n## Comparing the two models side by side\n\nSee the table below for a direct comparison across the dimensions that matter most to exhibition software buyers.\n\n## Which studios handle which model well\n\nNot every studio is set up for both. Some are project shops that do excellent initial builds but have no infrastructure for ongoing product ownership — no dedicated client leads, no sprint ceremonies, no structured retainer reporting. Others are product studios that work best on retainer but get sloppy on fixed-price delivery because they're not used to holding a scope line.\n\nAsk directly: what percentage of your active clients are on retainers versus project engagements? A studio that's 90% project work won't have the operating rhythm for a well-run retainer, and vice versa.\n\nFor more on how to stress-test a studio's claims, Five Questions That Separate Good Dev Studios from Expensive Ones is the right starting point.\n\n## What to do before you decide\n\nGet your scope onto paper first, even if you're leaning towards a retainer. The act of writing down what the system needs to do, what data it touches, and what a successful first show looks like will tell you more about which model fits than any studio sales conversation will. If you can write it down clearly, a fixed project probably works. If you keep stopping because you're not sure what the requirements are yet, a retainer might suit the early phase better — but only if the studio has a structured discovery process, not just open-ended billable hours.