Selling data is a business with a gravity problem. Content that took a decade to assemble becomes a commodity in a procurement conversation, buyers consolidate vendors, and every renewal is a conversation about price per record. Selling decisions is a different business. When a customer runs a workflow on your system, keeps their evidence in it, entitles their own users through it and builds their own applications on your API, the renewal conversation is about the work that would stop rather than the price of a feed. The distance between those two businesses is not strategy. It is a specific and bounded set of engineering, and most data companies have built about a third of it.
This is written for the product or division leader who has already made the decision and is now facing the part nobody presents well: what has to exist, in what order, without rewriting the business that pays for it.
What actually separates the two businesses
A data business ships records. Its quality attributes are coverage, freshness, accuracy and delivery reliability. Its interface is a file or a query endpoint. Its unit of value is a record, and its unit of price usually follows.
A decision platform ships an outcome inside a process. Its quality attributes include everything above plus latency, availability, entitlement correctness, auditability, model governance and interface quality. Its unit of value is a decision made or a case closed, and its price can follow that instead of the record count.
Six capabilities carry the difference, and they are separable pieces of engineering rather than a single platform program.
An analytics layer. The derived answers: scores, classifications, comparisons, forecasts, rankings, anomaly flags. What the customer previously computed themselves from your data, computed once by you, consistently, with a documented method.
Workflow. Queues, assignment, status, notes, review, approval, escalation and closure. The unglamorous machinery that lets someone finish a task in your product rather than exporting to a spreadsheet.
Entitlements. Which users at which customer may see which data, at what granularity, for what purpose, and what the system does at the boundary. This is where content licensing and software meet, and it is the piece most often built too simply and then rebuilt.
Audit trails. An immutable record of who saw what, what the system said at the time, what the user decided, and why. This is what makes the product usable for consequential decisions.
Model governance. Versioned methods, recorded inputs, reproducible outputs, monitoring, documented limitations and an override path with reason codes. Regulated customers require it; every other customer benefits when a number moves and someone asks why.
APIs a customer can build on. Not an export endpoint. A stable, versioned, documented interface with predictable latency and a deprecation policy, so a customer's own engineers can make your platform part of their system.
What raises renewal value most when a feed becomes a platform
Editorial weighting, illustrative rather than measured. The last row is deliberately low: more content is the reflex answer and the weakest lever on renewal.
The architecture that avoids the rewrite
The instinct is to build a new platform beside the old one and migrate. That instinct is expensive and usually fatal to the schedule, because the existing delivery paths carry the revenue and cannot be paused.
The design that works separates the system into layers with explicit contracts, then rebuilds one layer at a time behind those contracts. Concretely, five layers.
Ingestion and the fact store. Immutable observations, each with a source, an as-of date, an ingestion date and a method. Almost every existing data business has something here, usually with the as-of and ingestion dates collapsed into one, which quietly forecloses point-in-time reconstruction. Fixing that is the first structural change and it pays for itself repeatedly.
A curated semantic layer. One definition per concept, computed over the fact store, named and versioned. Not a warehouse schema per product. When two products disagree about what revenue means, the customer notices before you do.
Analytics services. Each derived answer as an independently deployable service with a versioned method, recorded inputs, and outputs written back as facts with their own provenance. A score is an observation like any other and should be stored the same way.
The application and API layer. Both surfaces served by the same services. If the interface calls something the API does not expose, the interface will drift ahead and the API will become a second-class product.
A control plane. Identity, entitlements, usage metering, audit and configuration, shared by every product rather than reimplemented per product. This is the layer most often built last and the one whose absence causes the most rework, because entitlements and metering touch every surface.
Rebuilding behind contracts means the legacy file delivery becomes just another consumer of the fact store. Customers on it see nothing change, which is the point. You are not migrating them; you are giving new products a floor to stand on.
There is a second reason to treat the API as a first-class product rather than a delivery convenience. A platform that customers build on acquires a partner channel almost for free. Systems integrators, consultancies and software vendors who serve your customers will embed a well-documented API into their own offerings, and each of those embeddings puts your answers inside a process you did not have to sell into. That only happens if the contract is stable enough to depend on, which means versioning, a deprecation policy with a stated notice period, a sandbox with representative data, and a changelog someone actually maintains.
Where the rework cost lands when a layer is built late
Editorial weighting, illustrative rather than measured. The last row is deliberately low: the interface is the cheapest thing on the list to change.
Workflow deserves more design attention than it usually receives, because it is where a product stops being a reference tool and starts being where someone's job happens. The parts are ordinary and the details are not. A queue needs a work-assignment model that survives someone leaving. A case needs a state machine with transitions that are recorded rather than inferred. Notes need to be attributable and immutable once saved, because a note that can be edited silently is worthless as evidence. Evidence capture needs to preserve what the user actually saw, including the values at that moment, not a live link that will show something different next year. And closure needs a reason taxonomy the customer can configure, because their reporting depends on it and yours will too.
Entitlements are the part that is always underestimated
In a feed business, entitlement is a contract term and a delivery configuration. In a platform, it is runtime code on every request, and the requirements are more intricate than they first appear.
A customer is not one thing. It is a legal entity with subsidiaries, business units with separate licences, users with roles, and sometimes clients of that customer with their own permissions. Rights differ by data element, not only by dataset: a customer may see a score but not the inputs, or the current value but not the history, or aggregates but not the underlying records. Rights differ by purpose: internal analysis, redistribution to clients, inclusion in a published report, or training a model, and each carries different licence terms. Rights change mid-term as contracts are amended.
The engineering consequence is that entitlement has to be a policy evaluated per request against attributes of the user, the customer, the data element and the purpose, not a set of feature flags. It must be enforced at the service boundary rather than in the interface, because the API is the surface a determined customer will use. It must be auditable, so you can show what a customer was permitted to see on a given date. And it needs a self-service path for the customer's own administrators, because the alternative is a support ticket for every staffing change at every account.
Build it as a distinct control-plane service early. The version built into the first product, with a table of customer identifiers and dataset names, will be rewritten during the second product's build, and the rewrite will touch every endpoint.
Model governance as a product surface, not a compliance chore
Any derived number invites the question of why it says what it says. Banks and insurers have formal expectations here, and supervisory guidance on model risk management sets out validation, documentation and ongoing monitoring as standing obligations. If financial institutions are among your customers, your governance is part of their compliance posture, which means it is part of your product.
What that looks like in the system, concretely. Every model has a version, and every output records the model version that produced it. Inputs are recorded, or reconstructible from the fact store as of the scoring date, so any output can be reproduced. The method has documentation the customer can read, covering data sources, features, known limitations and populations where performance is weaker. Performance is monitored on a schedule with thresholds that trigger review. Changes are announced before they take effect, with a window where old and new values are both visible. And there is an override path that records who overrode, what they changed it to, and why, with the override carried forward rather than silently lost on the next refresh.
The last two are what customers actually notice. A score that changes without warning breaks their downstream process. An override that vanishes on the next run destroys the analyst's confidence permanently, and nothing you say afterwards restores it.
Staging the move without stopping the business
The sequence below is a shape rather than a schedule, and the durations are illustrative. The principle is that each stage ships something a customer pays for, so the program is funded by its own results rather than by a strategic budget that can be cut.
| Stage | What gets built | What ships to customers | What it de-risks |
|---|---|---|---|
| One: foundation | Fact store with as-of and ingestion dates separated; semantic layer for one domain | Point-in-time queries and a documented definition set | Reproducibility, which every later stage assumes |
| Two: first analytic | One scoring or classification service, versioned, with provenance on every output | A derived answer sold as its own line | Whether customers will pay for answers rather than records |
| Three: control plane | Identity, attribute-based entitlements, usage metering, audit | Self-service administration and usage visibility | The rework that otherwise hits every product |
| Four: first workflow | Queues, assignment, notes, review, evidence capture, closure | A product where work finishes rather than exports | Whether the product changes how a team works |
| Five: the public API | Versioned contracts, deprecation policy, keys, quotas, docs, sandbox | An interface customers build on | Switching cost and the partner channel |
Two ordering rules matter more than the rest. The control plane comes before the second product, not after it, because entitlements and metering are cross-cutting and retrofitting them is the largest avoidable cost in the whole program. And the first analytic should be chosen for how visible it is in a customer's existing process, not for how technically interesting it is. The purpose of stage two is to prove the pricing thesis with real money.
How to price a platform when the business priced records
Pricing is where these moves usually stall internally, because the existing model is understood and the new one is not. Three shapes work, and they are not exclusive.
Keep the content subscription and add a platform fee. The simplest transition. The customer keeps their data licence and pays separately for the application and workflow, priced per seat or per business unit. It is easy to sell against an existing contract and easy for procurement to compare. Its weakness is that it invites the customer to buy only the content.
Price the decision. Per screening, per case, per assessment, per API call in an approval flow. This aligns your revenue with the customer's activity and is often the honest measure of value delivered. It requires metering you can defend, which is another reason the control plane is stage three and not stage six.
Tier by capability. A base tier with data access, a middle tier adding derived analytics and workflow, a top tier adding the API, custom entitlement structures and deployment inside the customer's environment. This is the most legible model for an enterprise buyer and the easiest to expand within an account.
Whichever shape, decide early what happens to the data licence when a customer uses the API to feed their own systems. Redistribution and derived-works terms written for a file delivery rarely say the right thing about an API in a customer's production application, and discovering that during a large renewal is an expensive way to learn it.
How we work inside a data company
Precision Federal is an engineering firm. We build data platforms, AI systems, APIs and full-stack applications, and we deliver them into production, including inside federal agencies where auditability, entitlement and accessibility requirements are strictest. That is directly relevant here, because the platform capabilities a regulated commercial buyer wants and the ones a government buyer requires are largely the same list.
What the first weeks look like. We read the existing delivery paths, the data model and the products already in market, and we produce two things. First, an architecture for the five layers above, with the contracts written down: what the fact store holds, what the semantic layer defines, how analytics services record provenance, what the control plane owns, and where the API boundary sits. Second, a staged plan tied to the specific first analytic and first workflow that fit your accounts, with what each stage ships and what it proves. Four to six weeks, and it ends with a document your engineering, product and commercial leaders can act on together.
Then we build. In practice that usually means we take the first two products end to end: the fact store change with point-in-time reconstruction, one analytics service with versioned methods and reproducible outputs, the control plane with attribute-based entitlements and metering, and the first workflow with evidence capture and audit. We work inside your repositories, your standards and your review gates, and we write the tests, the deployment automation and the runbooks alongside the code.
What you keep. All of it. The code is yours, assigned in writing, committed to your repositories from the first day. Your data stays in your environment and never trains anything of ours. Your customer relationships are yours; we work behind your brand unless you want us named. Our existing tooling is named, carved out, and licensed to you perpetually inside what we deliver, so nothing we bring can block a future maintainer.
Pricing takes one of two shapes. Fixed-price milestones with measurable acceptance criteria, which suits an architecture, a control plane or a first analytics service. Or a committed team at a monthly rate when the build is sustained and priorities will move. We will tell you which one fits before you ask.
The first step is one email with a one-page brief: what you sell today, how it is delivered, which customer process you want the product to own, what your customers already build with your data, and the date that matters. We return a scoped, priced statement of work.
Six ways this program goes wrong
Building the platform before the first product. A platform with no product on it cannot be evaluated and cannot be funded past the first budget cycle. Build the first product on thin versions of the layers and thicken them under it.
Leaving entitlements to the application. Enforcement in the interface is not enforcement. Put it at the service boundary, as policy, in the control plane, before the second product exists.
Shipping a score without governance. A number with no version, no recorded inputs, no documented method and no override path cannot be used for anything that matters, which caps its price at what a spreadsheet costs.
Treating the API as an export. An undocumented endpoint with no versioning, no deprecation policy and no sandbox will not be built on. The switching cost you are trying to create comes from customers depending on it, and they will not depend on something that changes without notice.
Collapsing as-of and ingestion dates. One column instead of two makes point-in-time reconstruction impossible, and every governance and audit requirement downstream assumes it. This is the cheapest thing on this list to fix early and among the most expensive to fix late.
Selling the platform to the same buyer as the feed. The data buyer optimizes cost per record. The platform buyer owns a process and a headcount budget. They are usually different people, and the second one has never heard of you.
Bottom line
The move from data vendor to decision platform is six capabilities: an analytics layer, workflow, entitlements, audit trails, model governance and an API worth building on. It does not require a rewrite. It requires separating the system into layers with written contracts, fixing the fact store so any answer can be reconstructed as of any date, then rebuilding one layer at a time behind those contracts while the existing delivery keeps paying the bills. Stage it so every step ships something a customer buys, put the control plane before the second product, and choose the first analytic for how visible it is inside a customer's process. The content is what you own. The platform is what makes the content hard to replace.
Frequently asked questions
A data vendor ships records and is judged on coverage, freshness, accuracy and delivery reliability. A decision platform delivers an outcome inside a customer's process and is additionally judged on latency, availability, entitlement correctness, auditability, model governance and interface quality. The commercial difference follows: a feed renewal is a conversation about price per record, while a platform renewal is a conversation about work that would stop, because the customer's process, evidence and integrations live inside the product.
Yes, by separating the system into layers with explicit contracts and rebuilding one layer at a time behind them. Ingestion and a fact store, a curated semantic layer, analytics services, an application and API layer sharing the same services, and a control plane for identity, entitlements, metering and audit. Existing file delivery becomes another consumer of the fact store, so customers on it see no change. The one structural fix worth doing first is separating as-of dates from ingestion dates.
Because a customer is not one thing. It has subsidiaries, business units with separate licences, users with roles, and sometimes its own clients. Rights differ by data element, by purpose, such as internal analysis versus redistribution versus model training, and they change mid-term as contracts are amended. That requires policy evaluated per request against attributes of user, customer, data element and purpose, enforced at the service boundary rather than in the interface, auditable after the fact, and administrable by the customer.
Versioned models with the version recorded on every output, inputs recorded or reconstructible as of the scoring date so outputs are reproducible, documentation the customer can read covering sources, features and known limitations, monitoring with thresholds that trigger review, changes announced before they take effect with a window where old and new values are both visible, and an override path that records who overrode what and why and carries the override forward rather than losing it on the next refresh.
Three shapes work and can be combined. Keep the content subscription and add a platform fee per seat or business unit, which is easiest to sell against an existing contract but invites the customer to buy only the content. Price the decision, per screening, case, assessment or API call, which aligns revenue with activity and requires defensible metering. Or tier by capability, with data access at the base and analytics, workflow, the API and in-environment deployment above it.