What a build-grade specification contains
| Part | What it gives the next team |
|---|---|
| Written requirements, in a machine-readable form | What to build, item by item, with nothing implied |
| An API contract | How the parts talk to each other, in a standard format any team can read |
| Editable wireframes | Every screen, in files a designer can change — not screenshots |
| Data mappings | Where each piece of data comes from and where it goes |
| Acceptance tests in given / when / then form | How everyone will know a feature is done |
| Architecture decisions | Why key choices were made, so they are not relitigated |
Two of these use widely adopted public formats. The OpenAPI Specification is “a specification language for HTTP APIs that defines structure and syntax in a way that is not wedded to the programming language the API is created in” (OpenAPI Initiative). Given / when / then comes from Gherkin, where “Given steps are used to describe the initial context of the system”, “When steps are used to describe an event, or an action” and “Then steps are used to describe an expected outcome, or result” (Cucumber, Gherkin reference). Both checked 5 October 2026.
Why portability protects you
- You compare like with like. Five vendors quoting the same written specification are quoting the same project. Five vendors quoting a conversation are not.
- You are not locked in. If the relationship ends, the scope does not leave with the vendor.
- You can split the work. One team builds, another reviews, your own team takes over later.
- Scope becomes checkable. Acceptance tests turn “is it done?” into a question with an answer.
What changes when someone else builds from it
A specification travels; a delivery standard does not. A new vendor should review the specification, then price its own testing, security, hosting and support — because those depend on who builds it. Ask each vendor what it adds and what it assumes, in writing, exactly as you would for any quote.
Questions to ask about any specification you are given
- May I use it with any vendor, including my own team? In writing.
- Is it in editable, standard formats — or only a PDF?
- Does it include acceptance tests, so done means something?
- Does it say what is not included in the first release?
- Are the reasons for key decisions recorded, or only the decisions?
How Pricient handles this
Sometimes the right answer is to build with someone else, or in-house. The free specification comes first either way, before you pay anything. The Portable Spec Pack is the build-grade version of your documents — specification, API contract, editable wireframes, data mappings, acceptance suites and architecture decisions — licensed to travel to any vendor or your own team. Your idea and your business data remain yours, and confidential.
If you build with IOanyT, the full cost of the pack is credited against the engagement. It is a fixed-scope item, priced with your quote. Estimates assume IOanyT delivery standards; a third party’s execution would not include the QA, security and compliance layer our quote does.