Heading to SmallSat 2026? Questions to Ask Every Ops Software Vendor
The 40th Annual Small Satellite Conference returns August 23 to 26, 2026, and this year it convenes at the Salt Palace Convention Center in Salt Lake City. Four decades in, SmallSat has become the place where the small satellite community reviews what worked, argues about what comes next, and walks an exhibit hall packed with the people building the tools the industry runs on. For program and project managers, the technical sessions are the draw, but the show floor is where a different kind of work happens: evaluating the operations software that will, or won't, carry your next program.
That floor is a target-rich environment, and it is also a noisy one. Every booth promises traceability, speed, and a single source of truth. The difference between a platform that delivers those and one that merely demos them is in the questions you ask before you're impressed by the screen. This is a buyer's checklist for SmallSat 2026: the questions to put to every ops software vendor you talk to, organized so you can work the floor deliberately instead of collecting brochures.
Before the floor: frame what you're actually buying
Walk in with your own program's pain written down. A demo is designed to show a tool at its best on the vendor's chosen example; your job is to redirect it onto your reality. Bring the messy parts: the procedure that changes mid-campaign, the audit that took three weeks to prepare for, the recall scope you couldn't bound, the report that takes an engineer two days to assemble. Every question below is sharper when you anchor it to a specific scar your program already carries.
One framing question is worth asking yourself at every booth: is this a system of record, or a nicer-looking document? The whole value of operations software is that it maintains state, enforces rules, and remembers everything. A tool that only displays information more attractively has not solved the problem you came to solve.
Procedure execution and change control
Ask how procedures are authored, controlled, and executed, and listen for whether the answers are one system or three.
Ask: Does the platform enforce step sequence and required data, or does it just display instructions and trust the operator? Can it gate a step until its prerequisites and verifications are actually satisfied?
Ask: How does version control work? Can I see exactly what changed between two revisions, and can the system guarantee the version being executed is the one that was released?
Ask: Are approvals bound to a specific version of a procedure? If someone edits a procedure after approval, what happens to that approval? An answer that involves a separate email thread or signature sheet is a red flag.
Traceability and the as-built record
This is where program risk concentrates, so press hard.
Ask: Can the platform trace from a requirement to the test or operation that verifies it, to the as-run result, to its disposition, all without manual cross-referencing? Show me the chain on a real example.
Ask: How is serialized genealogy captured? If a supplier reports a bad lot, how quickly can I identify every affected unit, and is that a query or a fire drill?
Ask: When a deviation or nonconformance occurs, does the record capture the disposition and the approving authority, not just the discrepancy? Can I produce that record on demand for an auditor?
Data, telemetry, and test integration
For programs with real hardware on real stands, ask how the software meets the data.
Ask: Can telemetry and test-stand data feed directly into the procedure, so pass/fail criteria are evaluated against live channels rather than transcribed by an operator? What data sources and interfaces does it support?
Ask: How does the platform handle sensor validity, sample rate, and latency? Does it distinguish a measurement that is in limits from one that is simply missing?
Ask: Is the supporting data captured into the as-run record automatically, at full fidelity and tied to the step, or do I still correlate timestamps across separate systems after the fact?
Production and manufacturing operations
If your program spans manufacturing, probe beyond the digital traveler.
Ask: Does the platform enforce the current work instruction revision at the point of use, or is it a screen showing a packet that could still be stale?
Ask: Is kitting tied to the operation, with part identifiers validated at the point of consumption, so a wrong or out-of-lot part is caught at the bench rather than at recall?
Ask: Is inventory decremented from actual consumption in real time, and can the system enforce lot control and shelf-life limits where the part is used?
The platform itself: integration, deployment, and security
The capabilities matter only if the platform fits your environment.
Ask: How does this integrate with the systems I already run, such as PLM, ERP, and my existing data systems? Are there real APIs, or is integration a professional-services project every time?
Ask: What are the deployment options, and how is security and access control handled? For programs with controlled or export-restricted data, ask directly how the platform supports your compliance obligations rather than assuming it does.
Ask: Who owns my data, and can I get all of it out in a usable form if I leave? Lock-in is a program risk, not just a procurement footnote.
Scaling, cadence, and the things vendors gloss over
End on the questions that separate a tool that demos well from one that survives contact with a growing program.
Ask: What happens to performance and usability when I go from one program to ten, or from a handful of users to hundreds? Ask for a customer operating at the scale you are heading toward.
Ask: What does implementation actually look like, in time and effort, and what does it require from my team? A platform that takes a year to stand up may not help the program you are staffing now.
Ask: What is the total cost over a realistic program lifecycle, including implementation, integration, training, and support, not just the per-seat license on the slide?
Working the floor
Treat the checklist as a scorecard, not a script. Ask the same core questions at every booth so you can compare answers directly afterward, and note not just what each vendor claims but how they answer: whether they redirect a demo onto your real workflow comfortably, whether they distinguish what ships today from what is on a roadmap, and whether they can point to customers solving problems like yours. The vendors worth a follow-up conversation after SmallSat 2026 are the ones whose answers got more specific the harder you pushed, not less.
Frequently Asked Questions (FAQ)
-
The 40th Annual Small Satellite Conference takes place August 23 to 26, 2026, at the Salt Palace Convention Center in Salt Lake City, Utah. It is worth noting for returning attendees that the conference is held in downtown Salt Lake City rather than on the Utah State University campus in Logan where earlier editions were based, so plan travel and lodging accordingly.
-
The conference draws government, commercial, and academic participants from across the small satellite community, including engineers, mission and program leaders, and the vendors that supply the industry's tools and components. For program and project managers specifically, the value is twofold: technical sessions that surface where the industry is heading, and an exhibit floor where you can evaluate operations platforms and suppliers face to face in a few concentrated days.
-
Come in with your program's specific pain points written down, and use them to redirect every demo onto your own workflow rather than the vendor's chosen example. Bring a consistent set of questions covering procedure execution and change control, traceability and the as-built record, data and telemetry integration, production operations, platform integration and security, and the realities of scaling, implementation, and total cost. Asking the same core questions at every booth lets you compare answers directly once the noise of the floor fades.
-
Ask whether the product is a true system of record or a more attractive way to display documents. The entire point of operations software is that it maintains state, enforces rules, preserves history, and answers questions on demand. If a platform mainly makes existing documents look better without enforcing process, controlling versions, or making your data queryable, it has not addressed the problems that bring most program managers to the floor in the first place.
-
Ask each vendor directly to distinguish what is generally available now from what is planned, and ask to see the capability you care about demonstrated on something close to your real workflow rather than a polished sample. Request a reference customer operating at the scale and complexity you are growing into. Vendors with shipping, proven capability tend to get more specific as you press for detail, while roadmap-heavy answers tend to get vaguer.
-
Yes. The questions apply to any evaluation of operations software, whether on a show floor, a video demo, or an RFP. The only difference is pacing: away from the floor you have more time to require written answers, run a structured proof of concept against your own procedures and data, and involve the engineers and quality staff who will live with the choice. The core discipline is the same, which is to anchor every question to your program's real pain and to insist that answers get more specific under scrutiny, not less.
