Decision guide
Build vs Buy an SDS Parser
A worksheet for the decision: what you would have to build, which numbers to estimate, and what to ask any vendor.
Last updated: 2026-10-24
What "build" actually includes
| Component | What it involves | Question to answer |
|---|---|---|
| Reading the document | PDF parsing, OCR for scans, layout and table handling. | How will you handle scans, rotated pages and multi-column layouts? |
| Locating the 16 sections | Finding section boundaries across supplier layouts and languages. | What happens with a layout you have never seen? |
| Normalizing fields | Mapping text to a stable schema: hazard classes, H and P statements, CAS numbers, UN data. | Who owns the schema, and how do you version it? |
| Quality signals | Confidence, warnings, validation rules. | How do you decide a result is safe to accept automatically? |
| Review tooling | A queue and a screen for people to check flagged documents. | Who reviews, and how fast must they be? |
| Operations | Retries, rate limits, batching, monitoring, secrets, access control. | Who is on call when it breaks? |
| Evaluation | A labelled test set and a repeatable way to measure changes. | How will you know an update made things better, not worse? |
A cost worksheet
Estimate each term for your own situation. We deliberately give no numbers: they depend on your team, your volume and your documents.
Build, year one =
initial engineering months x loaded monthly cost
+ evaluation set creation (hours x rate)
+ infrastructure and model/API usage
+ review labour for flagged documents
+ maintenance share (monthly) x loaded monthly cost x 12
Buy, year one =
documents per year x price per document
+ integration effort (one-off)
+ review labour for flagged documents
+ any plan or deployment fees- Review labour appears on both sides: neither approach removes the need for a person to check low-confidence results.
- Maintenance is the term most often underestimated when building. Suppliers change layouts and models change behaviour, so the work continues after launch.
- Our self-serve price per document is on the pricing section; enterprise is priced to scope.
A decision checklist
| If this is true | It points toward |
|---|---|
| SDS extraction is a core product capability you want to own and differentiate on. | Build |
| You have, or will fund, engineers and a labelled evaluation set for it. | Build |
| SDS data is an input to something else, and you want it working in weeks. | Buy |
| Volume is steady or batch-based and you prefer an OpenAPI contract to maintaining parsers. | Buy |
| You need a very different output schema, or the documents are unusual. | Build, or buy and map |
Questions to put to any vendor
- How do you measure accuracy, on what documents and languages, and can I run my own sample?
- Which parts of the output are a stable contract, and how are changes announced?
- What happens to my documents: retention, deletion, residency, who can see them?
- What are the rate limits, and what happens when I reach them?
- How are errors reported, and can I retry safely?
- What can I do if I want to leave: can I export everything I have stored?
How we answer them
The output contract is the OpenAPI document, with a changelog and a deprecation policy. Errors share one envelope with a stable error.code, rate limits return Retry-After, and bulk submissions take an Idempotency-Key. We do not publish per-language accuracy figures, so run your own sample, and see data residency and security for retention and deployment.
FAQ
Should we build if we already have ML engineers?
Possibly, if SDS extraction is something you want to own. Price the evaluation set, review tooling and ongoing maintenance, not just the first working version.
Can we start by buying and build later?
Yes. The output is a documented JSON contract, so you can keep your downstream mapping and swap the extraction step later.
How do we compare fairly?
Run the same 50 representative documents through each option and compare against values you have verified.
Related pages
- SDS extraction API vs prompting an LLM yourself
- SDS extraction API vs cloud document AI
- Generic OCR vs SDS normalization
- SDS extraction API vs SDS management platforms