Why search in a disconnected network is a different build
Meilisearch, Typesense and OpenSearch can all run fully self-hosted, so a classified, industrial or offline site can keep search entirely inside its own boundary. What changes is the surrounding build. The engine is the easy part. The hard parts are getting every container image, package and model file across the isolation boundary in a controlled way, refreshing indexes when the only route in is removal media, and wiring search to the identity provider that already governs access on the network. Meilisearch Community Edition is MIT licensed and self-hostable without usage limits, but its Enterprise Edition is governed by a commercial license or the Business Source License 1.1, so confirm the edition and license terms in writing before anything is carried inside the boundary. Typesense is GPL-3.0 on the server, and OpenSearch licensing should be confirmed against the version you select. Each choice carries different obligations for internal modification and redistribution.
Start with a transfer register rather than an installer. For each release, list the engine binary or image, its dependencies, the SDK and adapter packages, sample data, and any embedding model files for semantic search. Record the source, the hash, the signing check and who approved the import. This is the same discipline NERC CIP-013-2 expects for verifying software integrity and authenticity in utility environments, and it is a sound pattern for any high-assurance network. Ask your engine vendor to confirm which artifacts they publish for offline installation and whether their release notes flag security patches separately, because you will be carrying those patches in by media on your own schedule. Typesense's system requirements also matter here: keyword indexes need 2 to 3 times the size of the searchable fields in RAM, each vector needs 7 bytes per dimension, and built-in ML models add roughly 2 to 6 GB of RAM, so size the hardware before the media run, not after.
Identity is where disconnected builds most often stall. Search admin consoles, API keys and any role-based result filtering must connect to the internal identity provider without calling a public SaaS login. Confirm with each vendor which single sign-on methods the self-hosted edition supports, whether SAML or OIDC is included in the edition you license, and whether permission-aware results can be enforced with tenant or scoped keys rather than a separate user store. Where the network is subject to rules such as NERC CIP-005-7, which governs interactive remote access and requires an Intermediate System with multi-factor authentication, plan the same controls for any vendor who needs to support the search cluster. Finally, agree with your partner how index updates will be signed off, how an offline reindex is rehearsed on a staging enclave, and how rollback works when a media-delivered update fails.
Which requirements shape the offline search build
This table maps each requirement that typically applies to offline search to the build change it forces and the evidence an assessor will ask for. Read it as a checklist to confirm with your assessor and security team before choosing an engine, since the controls that apply depend on your asset classification and boundary.
| Requirement | What it asks for | Impact on the search build |
|---|---|---|
| NERC CIP-005-7 (electronic security perimeter) | Interactive remote access to high and medium impact BES Cyber Systems passes through an Intermediate System with encryption and multi-factor authentication | If search sits near BES Cyber Systems, admin consoles and index APIs need access only through the intermediate system, with no direct remote sessions into the search nodes |
| NERC CIP-005-7 (remote session control) | Methods to detect and disable active vendor remote access sessions | Vendor support for search clusters must be time-bounded and logged, and the team must be able to terminate sessions on the search hosts |
| NERC CIP-013-2 (software integrity) | Supply chain procurement addresses verification of integrity and authenticity of vendor software and patches | Every engine binary, container image, model file and rule set carried across the boundary needs a recorded checksum or signature check before install |
| Offline installation and updates | Software can be installed and updated without internet access, using media brought in under change control | Build a private registry or local package mirror, pin versions, and plan index and rule updates as media transfers rather than pulls |
| Runtime isolation | Systems should not depend on outbound calls for function | Disable telemetry, analytics and model download endpoints in the engine configuration, and confirm no runtime call goes to an external host |
| Semantic search model files | Model weights must be verified and imported like other software | Embedding models are checked by hash, stored in an internal artifact store, and loaded from local paths only |
| CMMC and FedRAMP scope | Applicability depends on the contract, the system and the boundary, not on the engine chosen | Confirm with the assessor or contracting office whether either applies before assuming evidence requirements or hosting constraints |
Which search engines fit an offline network and why
Three engines cover most offline site search requirements, but each carries a different license, memory profile and edition boundary. The choice depends on what the network allows you to run, how much RAM the index needs and whether your team already operates a search cluster.
Meilisearch Community Edition
The Community Edition is MIT-licensed and self-hosted, which keeps the license review simple for a sealed network. It covers typo tolerance, filtering, faceted search, hybrid search and multi-tenancy for many application tenants. The README states that the Enterprise Edition is governed by a commercial or Business Source License 1.1 terms and is not permitted in production without a commercial agreement, so confirm the edition and each feature you need is production-permitted before design. Ask the vendor to confirm in writing.
Typesense server under GPL-3.0
The Typesense server is GPL-3.0 while its client libraries are Apache licensed. The project explains that the GPL lets organizations run modified server code internally without publishing changes, as long as they do not distribute it, which suits sites that never ship the binary outside their boundary. Its in-memory design and vector search suit fast offline lookups. Plan memory against the searchable fields, vector dimensions and any built-in ML models, and confirm the license position with your counsel.
Typesense memory sizing
Typesense keeps data in RAM, so memory sizing is the main infrastructure decision for a disconnected site. The system requirements guide describes keyword search needing roughly 2 to 3 times the size of searchable fields in RAM, 7 bytes per vector dimension, and an extra 2 to 6 GB for built-in ML models. Size the hardware on the full index and vector set with headroom, because you cannot add memory from a cloud console during an outage. Ask for these figures against your own corpus.
Typesense Raft clusters
For a site that cannot tolerate search downtime, Typesense offers Raft-based clustering. The system requirements guide recommends a highly available 3-node or 5-node cluster for production, tolerating one or two node failures respectively. Each node needs the full memory budget, so a 5-node cluster multiplies the hardware footprint. Confirm rack, power and network separation for each node, and confirm the offline update path for each member before you commit to a topology.
OpenSearch where the team already runs it
OpenSearch is the sensible choice when your operations team already runs an OpenSearch cluster with approved images, monitoring and hardening in the isolated network. Reusing that footprint reduces the number of engines your staff must patch and secure. Verify the license, node roles and offline snapshot process against your own standards, and confirm that the team can rebuild indexes from source data without an internet connection. Introducing a second search stack for one site rarely pays off on a disconnected network.
Confirm the edition before design
Air-gapped support is often a paid-edition feature. Mattermost lists air-gapped deployment in Enterprise Advanced, Rocket.Chat excludes it from the free Starter plan, and Metabase offers it on its Enterprise plan. Search vendors can follow the same pattern, so confirm in writing that offline installation, offline updates and the features you need are included in the edition you will run. Get that answer before you draft the architecture, because a licensing gap found during accreditation is expensive to fix.
How an offline search rollout runs, phase by phase
The sequence turns a disconnected network into a working search service by fixing the boundary and data rules first, then carrying verified software and models across by media, and finally keeping the index current through repeatable update cycles that can be rolled back.
Define the boundary and classify the data
Your security team and DeployOpen map which networks, hosts and users sit inside the isolated zone, which content will be indexed, and what classification each source carries. The output is a written boundary diagram and a data inventory that states which fields may be indexed, who may query them and where query logs are kept. The step is done when the security owner signs off on that inventory, because every later choice depends on it.
Build the bill of materials
DeployOpen lists every artifact the search service needs: the engine image or package, container base images, operating system packages, dependencies, ranking or synonym files, and any embedding model files for semantic search. Each item gets a version, a source, a checksum and a named owner. The output is a bill of materials that your team can review before anything is downloaded. Ask the vendor which items it publishes as offline bundles, since that determines how much of the list you assemble yourself.
Transfer and verify media
Artifacts are staged on an connected build host, scanned, hashed and written to approved media under your transfer procedure. On the isolated side, the checksums and signatures are verified against the bill of materials before anything is loaded. The output is a signed transfer record that shows what crossed the boundary, when, and which checks passed. Any mismatch stops the transfer, and the record is retained as supply chain evidence for your assessors.
Install from offline images into a private registry
The verified images and packages are loaded into an internal registry, and the search engine is installed from that registry rather than a public one. Deployment manifests or configuration files point only at internal addresses, and outbound name resolution and package mirrors are confirmed to be closed. The output is a running cluster or node set that starts with no outbound connections. Confirm with the vendor whether any feature, such as a built-in model download, expects internet access at startup.
Load and validate the index
Source data is exported from inside the boundary, loaded into the engine, and checked against the data inventory. Relevance tests run on a fixed set of known queries, and the team confirms that restricted fields are not returned to unauthorized users and that filtering and faceting behave as specified. The output is a validation report with the test queries, results and any accepted gaps. Semantic features are tested only after the model files have been verified in the previous steps.
Integrate with the internal identity provider
Query and admin access is connected to your internal identity provider through the protocols the engine supports, with roles mapped to indexes, filters or API keys. DeployOpen confirms that sessions, administrative access and any service accounts are scoped and logged inside the boundary. The output is a documented access matrix and test results showing that users see only results their role permits. Confirm the supported federation methods with the vendor before the design is fixed.
Run media-based update cycles
Engine patches, rule sets, reindexed content and model updates follow the same path as the first install: staged outside, verified, carried across, and applied in a change window. Each cycle produces a change record that ties the artifact hashes to the approved change. The output is a repeatable update routine that operations staff can run without internet access. Your change board sets the cadence and approval steps.
Test rollback before it is needed
Before the first production update, the team restores the previous engine version, configuration and index snapshot in a non-production copy of the isolated environment, then confirms that search returns the expected results. The output is a rollback runbook with the tested steps, the snapshot location and a recorded test result. Repeat the test after significant changes so the runbook still matches the running system.
Integration points that must work without the internet
A disconnected search deployment is only as offline as its weakest dependency. The cards below cover the integration points that have to resolve inside the enclave, from the container registry and package mirrors to model files, the content source, identity and logging. Each one needs a named owner and a test that proves it works with the outbound path closed.
Private container registry
Search engines ship as container images, and the cluster must pull them from a registry inside the enclave. Kubernetes documents pulling control plane images ahead of time with kubeadm config images pull and pointing kubeadm init at a private registry through the --image-repository flag. Mirror every image tag and digest you plan to run, including sidecars and any exporter, then verify the pull with no route to public registries. Ask the vendor which images are published and whether signatures are available for verification at import.
Offline package and update repositories
Operating system packages, language libraries and search engine packages must come from an internal mirror or from media that has been verified before import. Keep a versioned bundle of each package set, record its checksums, and retain the previous bundle so a failed update can be rolled back. Confirm with the vendor how upgrades are delivered offline and whether the tooling checks for newer media on its own. Treat any package that cannot be traced to a signed source as a risk to be reviewed before it crosses the boundary.
Model files carried by media
Semantic and hybrid search need embedding model files, and these must be brought in on approved media and loaded from local storage. Confirm which model format the engine expects, where it reads the file from, and whether it contacts a model hub at startup. Each model file should be hashed on the way in, stored with its source and approval record, and tested against a known query set. Ask the vendor to confirm in writing that no model download or telemetry call occurs at runtime.
Content and product source inside the enclave
The search index is built from a content or product database that also sits inside the boundary, so the indexing job needs a stable, local path to that source. Decide whether indexing runs as a push from the application, a scheduled pull, or a batch import from exported files. Each path must work when the rest of the network is isolated, and each needs a rebuild procedure when the index is lost. Document the data classification of every indexed field, since the index often holds more detail than the public page.
Internal identity provider for access control
Access to the search API and admin console should be decided by the internal identity provider, not by a shared key stored in a configuration file. Map each application or tenant to a scoped API key or tenant token that the application issues after it authenticates the user. Confirm how keys are rotated when the identity provider is unreachable and who can revoke a key. Test the case where a user loses a role and their previously issued key still exists.
Logging to the internal SIEM
Search query logs, administrative actions and index changes should reach the internal SIEM through a local forwarder, with no dependency on a hosted log service. Decide which fields are captured, since a raw query can reveal personal or classified terms, and set a retention period that the records policy allows. Confirm that the engine can write logs to a file or syslog target and that the forwarder can run without outbound access. Test that a failed SIEM connection does not stop searches from being served.
Features that phone home
Any feature that sends data or requests resources outside the enclave must be disabled or confirmed in writing by the vendor. This covers update checks, usage telemetry, hosted analytics, remote model downloads, license validation and hosted dashboards. Air-gapped support is often a paid-edition feature among related tools, so confirm the edition that includes it before you select a platform. Keep a written list of each outbound call, its owner and the setting that disables it, and check it during every upgrade.
How index updates work when no network path exists
A full reindex is the simplest pattern to reason about. The source system exports every searchable record on the inside network, the export is written to approved media, and the target search engine builds a new index from scratch on the disconnected side. Because the new index is built alongside the live one, users keep searching the old data until the new index is verified and swapped in. This pattern suits first deployments and periods of heavy schema change, but it grows more expensive as the catalog grows, since every record crosses the boundary each time. Plan the export so that record identifiers, field names and locale tags are stable between runs, and record which source snapshot each export came from. Ask your implementation partner how the swap is performed and how a failed build is rolled back. The following points cover what to check:
- Snapshot identity: Tag each export with a timestamp, source database version and record count so the import can prove it loaded the intended snapshot.
- Build beside, swap later: Create a new index under a versioned name, load it fully, then point the search alias at it only after validation passes.
- Settings travel with data: Export ranking rules, filterable and sortable attribute lists, synonyms and stop words as files, not only documents, so the rebuilt index behaves the same way.
- Batch sizing: Confirm the batch size the chosen engine recommends for bulk imports and test it on a copy of real data before the first production load.
- Retention of old versions: Keep the previous index and its export until the new one has run in production for an agreed period.
Confirm with the engine's documentation how index aliases or equivalent swap mechanisms work in the version you deploy.
Incremental loads carry only records created, changed or deleted since the last approved export. They keep media volumes small and shorten the window between a source change and its appearance in search, but they put more pressure on the import logic. Every record in an increment must be applied in the correct order, deletions must be propagated, and the import must be able to detect a missing or damaged package before anything is written to the index. Checksums are the control that makes this possible: the export side computes a digest for each file and for the manifest that lists them, and the import side verifies both before loading. A manifest should also carry sequence numbers so that a skipped increment is visible rather than silently absorbed. The following points cover what the import needs:
- Change capture on the source: Use a change log, updated-at column or outbox table that the export reads, and record the last sequence number included in each package.
- Checksum verification: Compare SHA-256 digests of each file and the manifest against values recorded at export, and refuse the package on any mismatch.
- Ordered, idempotent upserts: Apply records by identifier with upsert semantics, so replaying an increment after a failure does not create duplicates.
- Explicit deletes: Carry tombstones for removed records and confirm that deleted items no longer appear in results for permission-restricted content.
- Gap detection: Reject any package whose sequence number does not follow the last applied increment, and alert the operator.
Confirm with your security team which hash algorithm and signing approach the organization requires for media crossing the boundary.
Many isolated networks run updates on a fixed cycle: a transfer window opens, approved media is physically or through a controlled data diode moved across, and the import runs during a defined maintenance period. This model makes the operating rhythm predictable for security, change management and the people who review data before it enters the enclave. The cost is latency. Content published just after a window closes will not appear until the next one, so the business needs to agree which content types must be current and which can wait. Batch windows also suit combining full and incremental loads, for example a monthly full rebuild with weekly increments in between. Make the window itself a controlled change with a named owner, a rollback plan and a defined acceptance step. The following points cover how to run it:
- Calendar and cutoff: Publish the window schedule and the export cutoff time so source teams know which changes will ship in each cycle.
- Transfer approval: Record who approved each package for release from the source side and who accepted it on the isolated side.
- Import outside peak use: Schedule imports for periods of low search traffic and measure how long previous loads took on comparable data volumes.
- Freeze and resume: Pause query-side index changes during the load and resume only after the validation step passes.
- Exception path: Define how an urgent correction, such as removing a document that should not be public, is carried outside the normal window under emergency change control.
Ask the partner to show how a window is run from start to finish, including the evidence record produced for each cycle.
Loading data without a check is not enough. After every load, whether full or incremental, the team needs evidence that the index contains the records it should, that deletions took effect, and that the most important queries still return sensible results. Count validation compares the number of documents in the source export with the number indexed, grouped by content type or tenant where that matters. Relevance validation runs a fixed set of reference queries and compares the top results against expected answers agreed with the content owners. Both checks should run automatically as part of the import job, and the results should be stored with the package identifier so that an auditor can trace a search result back to the load that produced it. Keep the reference query set under change control, because changing it between loads hides regressions. The following points cover what to validate:
- Count reconciliation: Compare source and indexed counts per content type and fail the load if the difference exceeds a threshold the business has signed off.
- Deletion checks: Query for identifiers listed as removed in the increment and confirm they return no results.
- Reference query set: Maintain a versioned list of key queries, such as product names, policy titles and common misspellings, with expected top results.
- Permission checks: For restricted content, run queries as test users with different entitlements and confirm results match access rules.
- Load record: Store counts, query outcomes, package checksums and operator identity together so the evidence can be reviewed later.
Confirm with the content owners who signs off a load and how a failed validation is escalated before the previous index is retired.
What do buyers ask before building offline search?
How much effort does the offline bill of materials take, and what drives it?
The effort depends on how many components the search stack pulls in and how many of them have to be verified before they cross the boundary. A typical stack includes the search engine image, its operating system packages, container base images, any embedding or model files, client libraries, and the orchestration layer if it runs on Kubernetes. Kubernetes documents how to list and pull control plane images in advance and point kubeadm at a private registry, which shows the kind of preparation involved. The main drivers are the number of packages, whether the team already runs a private registry and artifact repository, and how many dependency versions must be pinned. Ask the implementation partner to deliver a written inventory with versions, checksums and the source each item came from, and confirm how the inventory will be updated for each later media transfer.
What does the work need from our security and operations staff?
It needs named people in security, operations and the data owning team, because most of the work sits at approval points rather than in installation. Security staff must agree how media is scanned, who signs off each transfer, and which evidence is kept for each import. Operations staff must own the private registry, the host baseline, backups, and the restore test. The engineering team needs access to the isolated network during setup and during each update window. NERC CIP-013-2 requires supply chain procurement processes that address verification of software integrity and authenticity, which is the control behind checking every package carried across an isolated boundary. Confirm early which of your existing change and supply chain procedures apply, so the engagement does not invent a parallel process.
Can our internal team build and run offline search without a partner?
Yes, many teams with strong platform and security skills can do it alone, but the difficulty lies in repeatable operations rather than the first install. An internal team needs experience with the chosen engine, container or host hardening, offline package management, identity integration with internal providers, and index rebuilds without internet access. Ask whether the team can run a full install from offline media in a test environment, perform an update from newer media, and restore from backup without vendor help. Some vendors restrict air-gapped deployment to paid editions, so confirm the license tier before planning the build. An implementation partner can deliver a fixed scope with written deliverables, and ongoing support can be covered by a separate retainer if the internal team wants help after go-live.
How long does the rollout take, and what changes the timeline?
The timeline is set mainly by approvals and media transfer, not by the install itself. Each transfer may pass through security review, malware scanning, change control and sometimes physical handling, and each step adds a waiting period that the engineering work does not control. Other drivers include how many environments must be built (development, test and production), whether the site has a staging network, how many identity and data sources must be connected, and whether a semantic model file must be validated. Ask the partner for a written schedule that shows which dependencies belong to your organization and which belong to the engagement, and confirm the approval path before the scope is signed.
How much memory do semantic models need in an offline search cluster?
Semantic search adds memory on top of keyword search, and the cost can be estimated from the engine's published rules. Typesense's system requirements guide says keyword search typically needs 2 to 3 times the size of the searchable fields in RAM, each vector needs 7 bytes of memory per dimension, and built-in ML models need roughly 2 to 6 GB of extra RAM. For an illustrative example, a catalog with 1 million vectors at 384 dimensions would need about 2.7 GB for vectors under this rule, before keyword indexes and model overhead are added. Ask the team to measure document count, field size, vector dimensions and model choice in a test environment, and confirm which model file must be carried across the boundary and how it is verified.
How do we update the search engine and indexes without internet access?
Updates arrive as new offline media, which is verified, transferred and applied in a controlled window. For the engine, the update path depends on the product: Security Onion, for example, documents an airgap mode in which its soup tool updates from newer ISO media, and Wazuh documents an offline installation path and an offline vulnerability repository. For the search index, the usual approach is to rebuild or refresh data from a source inside the network, not from an external service. Ask the engine vendor which artifacts an update contains, whether rule or model files are separate, and how the team can test a new version in a staging environment before production. Confirm also how rollback works if an update fails.
Which identity and compliance evidence should the offline design produce?
The design should produce evidence that the search service authenticates users through the internal identity provider, that media transfers are logged, and that each software artifact has a recorded source and integrity check. NERC CIP-005-7 is an example of a standard that focuses on controlled remote access into an electronic security perimeter, so teams in energy should confirm with their compliance lead which of its requirements touch search administration. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit report or certification. Ask the partner which evidence items are delivered and in what format, and confirm which assessor will review them.
Which evidence an assessor will ask for from the search layer
This table maps each piece of evidence an assessor may ask about to the search component that produces it, and what that evidence should show. Use it to plan which logs, records and baselines the search layer must generate from day one. The evidence supports an assessment result but does not establish one, and independent assessors make the final determination.
| Evidence | Produced by | What it should show | Where it usually fails |
|---|---|---|---|
| Image and package hash records | Offline transfer process and the registry holding search engine images | Hash values for each container image, binary and package carried across the boundary, matched to the vendor release it came from | Hashes recorded only for the outer archive, not for the images or packages inside it |
| Signed transfer logs | Media handling process, cross-domain or data diode transfer tooling | Who moved each media item, when, from which source to which destination, and the signature check result | Logs kept on a workstation that is not under the same record retention as the enclave |
| Configuration baselines | Search engine server configuration, container manifests, orchestration config | Approved settings for bind addresses, API key scopes, TLS, telemetry and outbound connections, with the version they apply to | Baseline captured at install and not updated after tuning, so live settings drift from the approved record |
| Access logs from the identity integration | Search engine API gateway or proxy, and the identity provider connection | Which user or service account queried or administered the index, with timestamps and the authentication method used | Admin API keys shared across teams, so logs show a key rather than a person |
| Index change records | Indexing pipeline and the search engine settings API | Each reindex, schema change, synonym or ranking rule update, with the source data version and the operator who approved it | Index settings changed through the API during troubleshooting with no ticket or change record |
| Patch records from offline update cycles | Offline update procedure and the images or packages applied after each cycle | Which release was applied, which advisories it addressed, the validation run, and the rollback point | Patches applied from new media without a record of which earlier media they replaced |
| Model file records for semantic search | Embedding model import process and the search engine vector configuration | Model name, version, source, hash and the approved use, so the model can be traced to the transfer record | Model files copied in by hand with no hash, so the deployed model cannot be matched to what was approved |
What to ask an implementation partner about offline search
Start by asking for evidence of offline delivery work, not just general engineering experience. Ask the partner to describe how they build an offline bill of materials for a search stack: the engine image or package, its dependencies, the container base layers if containers are used, the rule or model files, and the operating system packages. Ask who maintains that list after go-live and how a change to any item is recorded. For a Typesense or Meilisearch deployment, the list should name the server binary, the client libraries used by the front end, and any ingestion scripts. Ask how they verify media on the way in: checksums or signatures for each artifact, a hash manifest that travels with the media, and a written procedure for what happens when a hash does not match. The control behind this is the verification of software integrity and authenticity that NERC CIP-013-2 asks utilities to address in their supply chain processes, and most regulated buyers will expect similar evidence even outside the energy sector.
Next, ask how they handle model files for semantic search. Ask which embedding models they would bring across the boundary, who holds the license for each model and whether that license permits internal, offline use, and how the model version is pinned so that index vectors stay compatible with the query-time model. Typesense's built-in models need extra RAM, and vector size drives memory, so ask the partner to size these before the media is ordered. On edition fit, ask which edition of the engine they recommend and why. Meilisearch's Community Edition is MIT licensed, while its Enterprise Edition is governed by a commercial or Business Source License 1.1 arrangement. Ask the partner to confirm in writing which features they need, such as clustering, backups or support terms, are available in that edition, and who signs the license. Ask how the fixed scope is written. A good statement names the offline bundle, the verification steps, the number of environments, the index update procedure, the identity integration and the handover documents, with acceptance criteria for each.
Finally, ask about support after go-live, because an offline search system will need security updates and index refreshes that arrive by media. Ask who receives vendor advisories, how the partner tests a new release on a staging copy before it is carried into production, and how long they commit to support for each engine line. Ask whether they will document the update procedure for your own staff. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside the client's own networks, whether cloud, data center or air-gapped. It prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent assessors make those determinations. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Ask any partner, DeployOpen included, to confirm these terms in a signed statement of work before you compare quotes.
