Fireworks company software: a buyer's guide for UK display operators

Until recently there was no such thing as fireworks company software. There was a spreadsheet for stock, another for the diary, a paper register in the magazine, a WhatsApp group for crew and an email folder called "RAs". Nothing talked to anything else.

This guide is for the operator who has decided that has to change and wants to know what to look for. It is written by people who build one of the products in this category, so read it with that in mind. We have tried to keep it useful whichever product you end up with. The section about our own product is short, and at the end.

Why the category exists now

A spreadsheet works at ten shows a year. At forty it starts to fail, and not in one place. Stock gets counted twice. The same racks get promised to two shows on the same Saturday. An operator turns up to the wrong postcode because the venue changed in the email thread but not in the diary. Nobody knows what actually left the magazine last weekend until someone goes and counts.

The failure is rarely any one tool. It is the gaps between them. Every gap is a retype, and every retype is a chance for the numbers to drift. By the end of a November week the register, the spreadsheet and the van are three different opinions about what you hold.

So the category is forming. It is young in the UK. At least one other UK-built product launched in 2026 alongside ours, and that is healthy: competition sharpens everyone, and it means you now have a choice to make rather than a single option to accept. The rest of this guide is about how to make that choice.

What to look for

We have grouped this by where the work happens, because that is how you will feel the gaps.

The office

The core object is the display. One record that starts as an enquiry and ends as a fired, reviewed show, without being retyped in between. Look for statuses that match how you already talk: prospect, verbal, booked, designed, picking, ready, fired, reviewed. If the product's stages are "lead, opportunity, closed-won" you will be translating for the rest of your life.

Ask how enquiries that go nowhere are handled. A lost reason recorded against each one tells you next spring why the diary is thinner than it should be.

Annual shows should clone. The bonfire night for the same rugby club is the same venue, the same rough design and the same crew, so last year's record should be one click from this year's.

Date and price are separate facts. A client can agree the date and still be arguing about the price. The record should be able to say so.

Every display should carry its own money: the price, the payments taken, and the cost. The cost is the interesting part, and we will come back to it.

The magazine

This is where fireworks software either earns its keep or does not. You already know the rules. The question is whether the software can hold what you hold.

Multiple stores, each with its own limits by hazard type, is the minimum. A second unit, a temporary store for a big show, a store that is only licensed for one hazard type: the software should model each as its own place with its own caps, and show you at any moment how much of each cap is used and by what, so you are never reconstructing it from a register after the fact.

Every change to stock should be a typed movement: in, out, transfer, adjustment, stock-take, write-off. Each one should record when, who, how many, and the unit cost at the time. That last detail matters more than it looks. If the cost is snapshotted on the movement, your margins are computed from what actually moved, not from whatever the price list says today.

Ask whether a movement records what it was for. "Out, 24 units" is a number. "Out, 24 units, to the Henley show" is a record.

Stock-take should work on a phone in the store, with the count written back as a proper movement. If the product's answer is "export to Excel, count, import", it does not really do stock-take.

One thing worth saying plainly: the software keeps the register. It does not hold the licence and it does not carry the responsibility. That stays with you, whatever the brochure implies.

The crew

Crew should be assigned per show with a role and a pay amount, and they should see only their own shows. An operator who works for three companies on the same platform must see three separate worlds, and that isolation should be enforced at the database, not just hidden in the interface.

One-tap confirm or decline from a phone. The office should see the answer without a phone call. Once you have paid someone, they should see it, so you stop getting the "did that go through?" text.

Training records with expiry dates, visible at the point where you assign someone. You do not need the software to block the assignment. You need to be able to see the record before you make it.

Per-show PPE sign-off, item by item, by the person wearing it. If a manager ticks on someone's behalf, that should be recorded in the manager's name, not disguised as a self-confirmation.

Two things some products will not have yet, and it is fair to ask about them rather than assume: an availability calendar, and automatic call-sheet emails or texts.

The show day

The design tool should produce a firing order and a bill of materials, with NEQ and hazard-type totals rolling up as you build. You should know what the magazine has to issue before the design is finished, not after.

The pick sheet should print, and it should also work on a phone in the store with a sign-off when the pick is complete. Half-checked picks are how a rack of cakes ends up in the wrong van.

Pre-show and post-show checklists, built by you, filled in by the show manager on site. Photos. Warnings that must be acknowledged by name before the list will complete. Ideally a location stamp, so the office can see the checks were done at the venue rather than in the cab on the way home.

Weather at the venue around setup and firing time, and the Fire Severity Index for the site, should be on the display record rather than in a separate browser tab.

On the day itself, a view with the contacts that matter and tap-to-call. Nobody scrolls a CRM at half past six in a wet field.

The client

One permanent link per booking is the pattern to look for. The client checks the date, the venue and the price and confirms in one place, and that confirmation lands on your display record as a fact, not as an email you have to file. A message box for gate codes and parking. A feedback form after the show, saved against the same record.

Do not assume the product sends the emails for you. Some do, some do not, and some send the link but nothing else. Ask.

The platform

UK hosting, for the obvious reasons.

Multi-factor authentication, and the ability to make it mandatory for chosen users.

Permissions that separate viewing from editing, per area. A crew member should be able to see a display without being able to change its price.

Tenant isolation enforced at the database. A bug in the application layer should not be able to leak one company's data to another.

An AI connector over your own data is worth asking about. The useful version is an MCP server: you plug an assistant into your live products, stock, displays and orders, and it answers as you, with your permissions and your tenant scope. "Which shows fire this month and what is low on stock for them?" becomes a question, not a report. The less useful version is a chatbot bolted to the marketing site.

Installable on a phone home screen, with a high-contrast interface.

Questions to ask any vendor

Ask these of every product, including ours.

Does it know what a confirmed display is? A pipeline full of enquiries and pencilled dates is not the same as a diary of booked shows. If the product cannot tell them apart, every report and every price plan built on "displays" will be wrong.

Does it count users? Per-seat pricing punishes exactly the thing fireworks companies do most: give a login to every operator, including the ones who fire twice a year. Ask what a crew login costs. The honest answer should be nothing.

Does it handle multiple stores with per-hazard-type limits? If the answer is "you can add a custom field for that", it does not.

Can it receive a supplier order from a pasted price list? A two-hundred-line order from an importer arrives as a spreadsheet with the columns in an order you did not choose. Retyping it is an afternoon. The product should work out the columns from a paste, match the lines to your catalogue by code, and let you fix the ones it could not match by picking the product. Then goods-in should write real stock movements, in units, from an order placed in cases.

Can a forwarded email become an enquiry? Most new business arrives as a message to your inbox. Forwarding it to the system and getting back a structured enquiry, with the enquirer's details taken from the original message rather than from you, saves the retype that loses leads.

What happens to your data if you leave? CSV export from every list, and an API you can pull from, is the floor. If the answer involves a support ticket and a fee, factor that into the price.

Show design and firing software are a different category

Finale 3D and FWsim are design and simulation tools. They are excellent at what they do, and what they do is not this. Firing-system software talks to modules and pins. Neither is business software, and no business software should pretend to replace them.

There is overlap at the edges. A design tool produces a product list; the business tool needs that list as a bill of materials so the magazine can pick it and the financials can cost it. Ask whether the business tool can take a pasted list from your design tool and turn it into lines against your catalogue. That is the join that matters. A full simulation engine inside your stock system is not.

Where PyroPortal stands today

PyroPortal is run on a working display company. That is where it came from, and it is why the screens are shaped the way they are.

What ships now: the ten-stage display workflow with enquiry conversion, lost reasons and show cloning; a drag-and-drop firing sequence builder with NEQ and hazard-type totals; paste-a-list bill of materials import; printable show pack and a mobile pick-and-prep flow with sign-off; a Financials tab that computes the margin on each show from the design and the stock actually issued; venues with site-plan drawing; site weather and the Fire Severity Index per display; a permanent client booking page per show with online date and price confirmation; per-show crew assignment with a crew portal, PPE sign-off and pre- and post-show checklists; multiple magazines with per-hazard-type limits and a typed movement log with cost snapshots; a mobile stock-check screen; catalogue import, smart-paste supplier orders with AI assist, and goods-in that writes movements; a health and safety issue tracker with scheduled reviews; a training matrix; two-factor authentication with an enforced-MFA group, view-and-edit-separated permission groups, database-level tenant isolation; email-to-enquiry with AI parsing; an MCP connector; and CSV export from the list pages.

What does not ship yet, so you are not surprised: quote, contract and invoice PDFs; direct Xero or other accounting integration; single sign-on; automated client emails (you share the booking link yourself today); a crew availability calendar or automatic call sheets; active NEQ threshold alerts (utilisation is shown, not pushed); risk-assessment document templates; and a public trade shop front.

Pricing is by confirmed displays, not by users. Spark is free and covers ten confirmed displays a year with three users, one magazine and twenty-five products. Starter is £39 a month or £390 a year for thirty displays. Pro is £85 a month for seventy. Operations is £215 a month for two hundred. All prices exclude VAT. Paid tiers have unlimited users and crew logins. The AI Assistant connector is an optional £5 per user per month on any tier. There is no trial: you start on Spark and upgrade if you outgrow it.

See it on your own data

The fastest way to judge any product in this category is to put a real show into it. Take a look at how PyroPortal handles displays, from enquiry to reviewed, then start on Spark, which is free, and load one of your own.

Questions operators ask

Do I need fireworks-specific software, or will a generic CRM do?

A generic CRM will hold clients and dates. It will not hold a magazine with hazard-type limits, a firing order with NEQ totals, or a crew portal that shows an operator only their own shows. Companies do make generic tools work, usually with a lot of custom fields and a separate spreadsheet for stock. If the magazine and the crew are where your problems are, a generic tool will not reach them.

How long does it take to move over?

The slow part is the catalogue and the stock count, not the software. A product with a paste-and-map import can take a supplier price list in an afternoon. Then do a proper stock-take into the new system and treat that as day one. Displays can be entered as they come in; you do not need to backfill last season.

Does the software make us compliant?

No, and be suspicious of any product that says it does. Software keeps records and produces paperwork. It can stop you putting stock into a store that is not licensed for it, and it can show you who signed what and when. The licence, the assessments and the responsibility stay with the operator.

What should it cost?

Judge it against what it replaces. A product priced by confirmed shows scales with your season and costs nothing for the quiet months of enquiries. Per-user pricing is the one to be careful of, because a fireworks company has far more logins than desks.

Will it replace our show design software?

No. Design and simulation tools like Finale 3D and FWsim do a different job. The business software should take the product list a design tool produces and turn it into a bill of materials, a pick sheet and a cost. That is the join to test.