Skip to content

Procurement and assurance

Start your evaluation with the evidence.

Use the published company details, workflow sample and capability states to prepare the questions that matter to your proposed deployment.

Spectra guide · Source review: 18 September 2026

At a glance

The public site supplies verified company identity, a fictional workflow demonstration and dated website-release evidence. Product security, availability, integrations, migration, support, pricing and contractual terms must be evidenced for the proposed deployment and agreed in writing.

01 / Supplier identity

Start with the accountable legal entity.

Spectra is operated by Tech Geek UK Ltd, company 09834597, registered in England and Wales. The company-information page links directly to Companies House and the ICO register and records the registered office and privacy contact.

Those registrations establish identity and a public data-protection entry. They are not product certification, financial assurance, a customer reference or a statement that a proposed SaaS environment is ready.

02 / Available now

Separate the public-site dossier from proposal evidence.

The current public dossier lets a buyer inspect the fictional workflow, capability states, website data boundary, company identity, resource catalogue and dated release evidence.

EvidenceAvailable nowWhat it does not prove
Sample workflowPublic workspace and seven-stage explanationA live customer tenant or production suitability
Website operationsDated build, crawl, accessibility, header and enquiry-receipt evidenceSaaS availability, support or resilience
Company identityCompanies House and ICO linksCertification, endorsement or financial standing
Product roadmapPlanned and access-dependent registerDelivery dates or contractual commitment

03 / Proposal required

Commercial commitments belong in writing.

Pricing, product availability, implementation scope, acceptance criteria, support hours, service levels, data-processing terms, named subprocessors, migration responsibilities and exit arrangements are not offered by this website. They require a proposal for the actual workload and, where agreed, a contract.

  • No tender response should infer live integrations, tenancy controls or mobile applications
  • No penetration-test report, security certification or vulnerability-free guarantee is claimed
  • No customer reference, outcome or reviewer is supplied without evidence and permission
  • No target date becomes a commitment because it appears in a conversation or roadmap

04 / Due diligence request

Give the review a concrete workload.

To request a relevant evidence pack, describe the proposed users and roles, types of data, expected locations, required integrations, migration source, assurance obligations and decision stage. Do not send production data, credentials, customer artwork or security-sensitive configuration through the public form.

  • Architecture and data-flow review
  • Identity, role and cross-tenant denial evidence
  • Backup, restore, retention, export and deletion evidence
  • Subprocessor, residency and international-transfer terms
  • Incident, support, change, business-continuity and exit responsibilities

05 / Decision trail

Keep unknowns visible.

Each material question should be marked as demonstrated, documented, contractually committed, planned, provider-dependent or not available. Retain the artefact, environment, version and review date used for the decision rather than relying on a sales-page summary.

A stored enquiry receipt confirms only that the website accepted the request. Evidence assembly and a human response are separate manual steps, with no published response-time SLA.

Bring the job. Explore the next step.

Request workload-specific evidence