Build vs Buy a Seat Map for a Flutter Ticketing App

The seat-selection screen is rarely the feature that breaks the estimate. The system behind that screen is.

The short version

If a product needs a small, fixed, non-concurrent selector, build it. A Flutter team can render a grid, animate selection and ship a useful internal tool without buying a seating platform.

If the product sells reusable venue charts to many organisers, needs live inventory, supports temporary holds, or must recover cleanly when two buyers want the same seat, the decision is no longer “which widget should we use?” It is whether the team wants to own a small distributed reservation system alongside the rest of the product.

The right comparison is therefore not “custom UI versus SDK price.” It is differentiating work versus infrastructure work, including the maintenance and exit cost of each path.

On this page

• What “seat map” includes
• Three implementation paths
• The worksheet
• Where estimates slip
• Team ownership
• A phased delivery plan
• The vendor questions that matter

What “seat map” includes

Most proposals start with a screenshot: a venue outline, rows, seat labels, a legend, and a checkout button. That screenshot hides at least nine separate responsibilities.

Workstream	The question the team must answer
Venue model	Can one chart represent rows, curves, tables, sections, floors, categories, and blocked objects?
Authoring	Who creates and edits that chart, and how are revisions published?
Buyer rendering	How does the map pan, zoom, focus, label, and remain usable on small screens?
Accessibility	Can a keyboard or assistive-technology user understand and operate seat state?
Event state	Which published chart does this event use, and where is its live inventory?
Holds	How long is a temporary selection valid, and what happens when it expires?
Concurrency	What does the second buyer see when the first buyer wins the same seat?
Booking	How does payment connect to an idempotent inventory transition?
Operations	Who blocks house seats, handles a failed payment, audits a change, or reconciles a timeout?

The renderer is visible. The other workstreams are where a proposal needs a real owner.

Three implementation paths

Path one: build a small selector

In our experience this is the correct choice more often than vendors admit. Build the selector when:

• the layout is fixed or generated from a small trusted data set;
• one team or operator uses it internally;
• seats are not sold concurrently;
• the selection is a preference, not a scarce inventory commitment;
• the product team wants total control over the interaction model.

You can use Flutter’s normal layout and gesture primitives, a canvas, or a focused open-source widget. Keep the data model simple. State clearly that local selected state is not a commercial hold.

We watch for one moment: the first “temporary booking” requirement. At that moment, the team must add an authoritative store, atomic transitions, expiry, retries, server-side price authority, and a recovery path for conflicts. That is a new system, not a small callback.

Good fit: an internal hospitality planner where one coordinator assigns guests to a fixed room layout. Bad fit: a public onsale where thousands of sessions can contest the same inventory. The screen may look identical in both products; the state contract is not.

Path two: assemble a renderer and own the reservation backend

This is appropriate when seating is a strategic domain. A venue marketplace, airline, or specialist ticketing company may reasonably want its own chart compiler, inventory rules, staff tools, and data model.

The cost is not only engineering time. It is also the on-call responsibility for every edge case: stale holds, partial payment, duplicated retries, chart revisions after events are published, device-specific gestures, screen-reader semantics, and operational corrections.

The advantage is control. The disadvantage is that the reservation layer becomes a product you must continue to operate even when the original feature team moves on.

Good fit: a transport or venue platform whose routing, seat eligibility, and operational rules are proprietary. Bad fit: a small event marketplace that needs reserved seating but earns its advantage through discovery, organiser tools, or checkout. Owning a chart compiler in that product can consume the same engineers who should be improving the marketplace.

Path three: integrate a seat-map SDK/API

We think a commercial platform is the rational choice when reserved seating is necessary but the venue chart engine is not your product’s differentiation. The integration should cover more than rendering:

• a reusable chart and event model;
• buyer selection and live inventory;
• temporary holds and expiry;
• server-confirmed booking;
• real-time updates or a documented refresh strategy;
• webhooks, auditability, and operational boundaries;
• export, test mode, and a clear exit path.

SeatLayer’s developer platform is one example of this category. The host application still owns identity, checkout, payment, commercial orders, tickets, refunds, and customer support. The value is the seating/inventory boundary, not a claim that the SDK replaces the ticketing product.

Good fit: a ticketing product that can keep commerce in its own backend while delegating chart and inventory behavior. Bad fit: a product that requires an undocumented object model, cannot accept the provider’s data boundary, or has no workable export path. An SDK is not automatically the lowest-risk choice; maturity, dependency, support, and switching are real rows in the worksheet.

The worksheet

Don’t start with a total. We start with buckets and assumptions. A useful build-vs-buy worksheet has three columns: work, owner, and evidence needed to call it complete.

Bucket	DIY ownership question	SDK evaluation question
Chart authoring	Will we build a designer, import pipeline, or both?	Can we create, revise, publish, and export charts?
Browser/mobile rendering	Which surfaces and gesture models do we support?	Which packages are stable, preview, or WebView-based?
Inventory authority	Which store serializes seat transitions?	What is the event/inventory contract and conflict behavior?
Holds and expiry	How are TTL, release, and stale carts handled?	Is the hold opaque, inspectable, and tied to authoritative items?
Pricing	Where do tiers and prices come from?	Does the server calculate the payable line items?
Booking	How are timeouts retried safely?	Is there a stable idempotency/order reference?
Realtime	How does a buyer learn that a seat changed?	Snapshot/delta, polling, or documented refresh behavior?
Accessibility	Who tests labels, focus, contrast, and keyboard flow?	Is accessibility part of the buyer surface or your wrapper?
Operations	Who blocks seats and investigates a disputed sale?	Which staff tools, logs, and webhooks exist?
Exit	Can charts/data be exported and re-rendered elsewhere?	What remains portable if the contract changes?

We always include a confidence column. “We know” means the team has exercised the path. “We assume” means it needs a spike. “Vendor says” means it needs a source or test. Those labels are more useful than an impressive single number.

Here’s the worksheet we use, in relative effort points rather than dollars. Eleven workstreams, three implementation paths, a confidence field, and an explicit note on what each decision still costs you after launch:

Workstream — the question it answers	Static selector	Custom build	SDK integration	Confidence	What persists regardless of path
Discovery and venue model — how many reusable layouts, object types, and imports exist?	2	5	3	medium	Venue data cleanup survives every implementation choice
Renderer and interaction — who owns pan, zoom, hit testing, responsive layout, large-chart behavior?	3	8	3	medium	A custom renderer creates long-term framework ownership
Chart authoring and import — how do operators create, revise, validate, and publish layouts?	1	8	2	low	SDK path depends on authoring, export, and revision contracts
Live inventory — which service owns free, held, blocked, and booked state?	1	8	3	high	Two inventory authorities create reconciliation risk
Holds and expiry — how are temporary claims created, restored, released, expired?	1	8	3	high	Provider maturity and conflict semantics must be verified
Checkout and booking — where are prices inspected, payment taken, booking confirmed?	2	7	4	high	Host retains commerce and idempotency ownership
Accessibility and devices — what keyboard, screen-reader, touch, safe-area, zoom cases must pass?	3	6	4	medium	The device matrix grows with every supported surface
Staff operations — how do support and box-office staff reconcile or correct inventory?	1	7	3	medium	Operational UI and audit trail are often omitted from prototypes
Observability and support — can the team trace hold, expiry, conflict, webhook, uncertain booking?	1	6	3	medium	Provider support quality matters during live sale windows
Annual maintenance — who absorbs browser, OS, framework, and provider changes?	2	7	4	low	Use annual planning points, not a one-time build estimate
Switching and export — can charts, event mappings, and commercial records leave the system?	1	6	4	low	Test exports and contract termination before signing

Points, not dollars — and that choice is deliberate. A rate multiplied by an invented number of days looks more precise than it is. Replace the points with your staffed-day ranges only after the venue-model and concurrency spikes have exposed the hard parts.

When you do add money, calculate each scenario from staffed days × the team’s loaded day rate, then show contingency separately. Keep annual maintenance and switching work outside the launch subtotal; otherwise a low first-release number hides the decision the worksheet exists to expose.

Do not total rows marked “not applicable” as zero. A static selector receives “not applicable” for concurrent inventory because that path refuses the requirement; it does not solve it for free. If the product later adds public selling, reopen the architecture decision rather than quietly changing the cell to a two-day task.

A worksheet that can survive a review

For each workstream, record four values rather than one estimate:

Field	Example question
Effort range	How much engineering work is visible after the spike?
Confidence	Is this measured, compared with a known project, or only assumed?
Dependency	What must be true before this work can start?
Rework trigger	Which discovery would invalidate the estimate?

For example, “buyer renderer” may look high-confidence after a static prototype. Its rework trigger could be a venue with curved rows, multiple floors, a screen-reader requirement, and an operational need to block individual objects. “Booking” may look small because the endpoint is one request; its rework trigger is a payment timeout that leaves the commercial order uncertain.

Do not hide that uncertainty inside a blended number. A buyer can make a better build-vs-buy decision when the unknowns are visible.

A practical risk heat map

The heat map should describe risk to the product, not score vendors by colour alone:

Capability	Small DIY selector	Custom production system	SDK/API path
Fixed layout rendering	Low	Low–medium	Low after integration
Reusable chart authoring	High if required	Owned by team	Validate designer/import surface
Two-buyer contention	Out of scope	High ownership	Validate conflict/hold contract
Payment/booking ambiguity	Out of scope	High ownership	Validate idempotent server flow
Mobile/assistive QA	Medium	High over time	Shared responsibility at wrapper boundary
Operations and reconciliation	Out of scope	High ownership	Validate tools/webhooks/exports
Vendor exit	None	Data/model migration risk	Contract/export/maturity risk

The important row is “out of scope.” A green cell must not mean “the problem disappears”; it should mean “this path does not claim to solve that problem.”

The production JavaScript seating-chart guide is a useful companion for separating browser rendering from the inventory systems a production selector still needs. It is a guide, not a command to buy an SDK.

Where estimates slip

Rendering is mistaken for authoring

This is the slip we hit most often. A buyer map can be rendered from JSON. Somebody still has to create the JSON, decide how rows bend, label sections, represent tables and accessibility objects, publish revisions, and test whether the buyer view matches the venue. A team demos a rendered chart in week two, and the estimate quietly assumes the authoring tooling is free.

A client lock is mistaken for a hold

Disabling a seat after a tap only changes one client’s screen. It does not serialize a second buyer on another device. The hold has to be created by an authoritative inventory system and carry an expiry.

Payment and booking are treated as one request

Payment can succeed while the network response to booking disappears. The product needs a stable order reference and a retry policy. It must know whether to retry, inspect, release, or show a pending state to an operator.

Accessibility is postponed

Seat maps have unusual semantics: a visual color, a label, a status, a price tier, a section, and a selection action all need to make sense without relying on position or color alone. Retrofitting this after the canvas is finished is not a small polish sprint.

Preview and maturity are hidden in the proposal

An SDK can have a stable web surface and preview mobile packages at the same time. A proposal that lists “Flutter support” without the maturity label is not complete. Pin the exact version or revision you evaluate, run a test event on the target devices, and record which commands and failure states passed. A preview can still be the right choice; it just needs an explicit risk owner.

The maintenance line is missing

The first release is only one cost. DIY teams own framework upgrades, browser changes, chart imports, device QA, operational tooling, and every unusual venue shape added later. SDK buyers own integration and provider evaluation, but they should budget contract changes, package maturity, support, and exit planning.

Exit cost is postponed until procurement

Exit is an engineering question before it is a contract question. Can the team export chart geometry with stable object identity? Can it retain the host’s commercial orders independently? What mapping connects host events to provider event keys? Which staff workflows stop working on the day the integration is removed? A cheap first year can still be an expensive architecture if those answers are “we will work it out later.”

For a custom system, exit cost appears differently: the team may be locked into its own undocumented coordinate format, renderer assumptions, and the one engineer who understands the reconciliation job. “No vendor” does not mean “no switching cost.”

Team ownership

A serious proposal names a person for each boundary:

• Flutter lead: native surface, gestures, lifecycle, and accessibility wrapper;
• backend engineer: event/hold/booking adapter, retries, secrets, and webhook verification;
• product owner: chart revision policy, price authority, checkout behavior, and failure copy;
• QA/accessibility reviewer: physical devices, keyboard/screen-reader paths, conflicts, and resume;
• operations owner: blocks, refunds, disputed states, reconciliation, and audit access.

If the team cannot name the backend and operations owners, the project is not scoped by screen count yet.

A phased delivery plan

Use gates instead of promises about calendar weeks:

1. Renderer gate: a synthetic chart can be rendered, focused, selected, and reset.
2. Inventory gate: two clients receive one accepted hold and one recoverable conflict.
3. Checkout gate: the host inspects authoritative hold items, charges, and books with a stable reference.
4. Recovery gate: expiry, release, timeout, duplicate webhook, and retry paths are visible.
5. Operations gate: an authorised operator can block/release and investigate an uncertain state.
6. Accessibility gate: the buyer journey works with the target input and assistive technologies.
7. Ownership gate: the team has documented what remains host-owned and what the provider owns.

If a commercial SDK clears the first four gates in test mode, the team can spend its differentiation budget on catalogue, checkout, discovery, or venue workflows. If it fails a gate, the defect belongs in the vendor evaluation—not in an optimistic launch estimate.

A small spike beats a large proposal

Before asking a team for a fixed quote, make the riskiest transition executable:

1. Load one synthetic event chart.
2. Select two seats from the intended buyer surface.
3. Create a temporary hold.
4. Inspect the authoritative hold on the server.
5. Simulate payment success and book with a stable order reference.
6. Repeat the contested request from a second client.
7. Expire the hold and confirm that the buyer gets a useful recovery state.

This is not a full product. It is a contract test for the part of the product most likely to be underestimated. Attach the result to the worksheet with the exact runtime, assumptions, and open failures.

The vendor questions that matter

Ask these before comparing logos:

• Can we export charts and event data in an open format?
• Which mobile packages are stable, preview, or WebView wrappers?
• What exactly is public in the browser, and where does the secret stay?
• How are holds inspected, expired, released, and retried?
• What is the server’s price authority?
• What happens on 409, timeout, duplicate delivery, or a chart revision?
• Do the buyer surface and operational tools share one inventory state?
• Which features are preview, and how do we pin the version we test?
• Can we run the complete flow without charging a real card?
• What remains in our product if we stop using the service?

Ask for the answer in a runnable form when possible. A vendor’s diagram is useful; a test event with an observable hold, conflict, and retry is more useful.

The decision

Build when the seating domain is your differentiator or the problem is genuinely small and static. Buy when the product needs reserved seating but your differentiation sits elsewhere—and verify the complete hold→inspect→pay→book path, not a pretty demo.

That is the difference between buying a widget and choosing an infrastructure boundary.

Worksheet note

Copy the worksheet, heat map, and delivery gates above straight into your own sheet. They’re a project-scoping method, not a salary survey, vendor ranking, or promise of delivery time. Review the assumptions with the Flutter, backend, QA/accessibility, and operations owners before attaching currency to the model.

Frequently asked questions