How We Price¶
The default is a fixed price, recurring over an agreed term. That is the model to expect unless there is a specific reason to depart from it, and the reasons are discussed openly rather than priced in silently.
The model¶
A fixed, recurring price over a committed period. You know the figure for the term at the point you sign it. It does not move because the work proved harder than expected, and it is not metered against usage you cannot forecast.
If the thing you need does not exist yet, we build it within that same commitment. This is the part that surprises people. Bespoke development is often quoted as a large one-off engineering charge first, with a support contract behind it. We fold the build into the committed term instead: the same fixed recurring price covers creating the capability and running it afterwards.
Two consequences worth stating plainly:
- The term matters to us, because the build is amortized across it. A commitment period is not a lock-in tactic; it is what makes it possible to develop something specific to you without a separate up-front development fee.
- We carry the delivery risk. If the build takes longer than we judged, that is our problem, not a variation order. That is the trade we are making in exchange for the term.
Some vendors call the up-front build NRE — non-recurring engineering. If you have seen that term on a quote elsewhere, the short version is: we do not bill it separately.
A worked example — connectors¶
Connectors are our most established commercial model, so they show the shape most clearly. The default:
| Element | How it works |
|---|---|
| Price | Fixed, annual |
| What the base covers | A first increment of up to five datasources |
| Growing beyond that | A further fixed amount per additional increment of five datasources |
| Term | Three years |
| Development of the connector itself | Included — within that term, not before it |
The unit is a datasource, except for the Metadata Connector, where it is a metadatasource. That connector combines metadata across several upstream systems, so a connection there is not the same unit of value as a single datasource.
What the price actually buys is not connectivity. This is worth being direct about, because your platform may well ship a connector of its own. What you are paying for is everything around the connection — incremental indexing, scheduling, maintained and coordinated releases, operational visibility, structured logging, configuration protection. We call that Connectors ++, and it is standard in every connector rather than a tier.
When the default does not fit¶
The model above is a default, not a rule. Where something about your situation genuinely changes the economics, we would rather identify it and agree how to account for it than quietly load it into a number.
Things that commonly do change it:
- Collaboration. Where you bring something to the work — domain IP, a proving site, engineering effort, a reference commitment — that is a real contribution and it should show up in the commercial terms. This is the most common driver by some distance, and it has its own page: How We Engage.
- Scale or shape that the increment model does not describe well.
- Hosting and data-residency constraints that dictate where something has to run.
- Complexity we judge to be extreme. Occasionally the honest answer is that a fixed price is not responsible, and we will say so rather than quote one and hope.
The hourly model still exists if you want it. It is no longer our default, because billing by the hour rewards effort rather than outcome and makes every budget conversation adversarial.
Getting a number¶
Rates are not published here — the structure generalizes, the figure does not. Talk to us, or to your Seeq contact, and we will be specific.