Pricing as infrastructure

One-time deployment, delivered with boundaries.

Our pricing is structured around infrastructure deployments: defined scope, measurable acceptance, disciplined handover, and optional support with clear limits. No forced retainers. No vague “ongoing work.”

If the scope cannot be defined, accepted, and handed over, the engagement does not start.

Foundation Management

Structured oversight for scoped systems

Foundation Management is governance-based oversight after deployment. It exists to keep a scoped system stable: monitoring awareness, escalation pathways, reporting intent, and disciplined change control.

Included (within defined scope)

  • Baseline monitoring awareness and incident triage for agreed components.
  • Escalation coordination when third-party dependencies are involved (hosting, DNS, platform services).
  • Change control: requested modifications are reviewed, scoped, and executed only when approved.
  • Periodic governance notes and operational reporting where agreed.

Foundation Management does not convert a deployment into open-ended operations coverage.

Not included (unless explicitly scoped)

  • Unlimited support or undefined enhancement cycles.
  • Management of client-owned or client-administered systems not in scope.
  • Guaranteed resolution timelines; timing depends on complexity and external dependencies.
  • Coverage for unauthorized changes or unapproved tooling expansions.

Where operational management is required, it is defined as a separate, limited engagement — not implied.

Boundary statement: Digitalith Systems does not provide unlimited support or undefined change requests. All modifications follow documented change control.

Deployment packages

Packages are scope templates — not a promise of “everything.”

Each package includes: scope definition, deployment, acceptance testing, and a documented handover. Exact pricing is confirmed after the infrastructure assessment.

Foundation Deployment
Assessment-led fixed scope

Stabilize one operational domain

For teams that need a single system deployed properly, with clear ownership and handover.

Included
  • Infrastructure assessment + scope definition
  • One domain deployment (single workflow family)
  • Basic roles & access model (limited role set)
  • Acceptance checklist + handover runbook
  • Time-bound stabilization support (as defined)
Not included
  • Multi-site complexity
  • Advanced integrations
  • Custom reporting pipelines
  • Ongoing “unlimited” changes
Best when scope is narrow and urgent. Request
Core Operations Deployment
Assessment-led fixed scope

Deploy a controlled operating backbone

For teams ready to formalize workflows, governance boundaries, and change control.

Included
  • Infrastructure assessment + scope definition
  • Two operational domains (or one complex domain)
  • Role-based access model (defined admin ownership)
  • Governance notes (approvals, traceability assumptions)
  • Acceptance checklist + deeper runbook
  • Time-bound support window (as defined)
Not included
  • Enterprise-wide integrations across many tools
  • High-volume data engineering pipelines
  • Unlimited enhancement cycles
  • 24/7 operations center coverage
Most common starting point for serious buyers. Request
Multi-Site Deployment
Assessment-led governed rollout

Deploy with rollout discipline

For teams with multiple locations, clearer governance needs, and rollout coordination requirements.

Included
  • Infrastructure assessment + rollout plan
  • Multi-site structure (as scoped)
  • Stronger governance model (role tiers, approvals)
  • Training handover session(s) (as scoped)
  • Acceptance checklist + operational playbook
  • Time-bound support window (as defined)
Not included
  • Open-ended “product development” roadmaps
  • Unscoped custom modules without acceptance criteria
  • Unlimited integrations
  • Support without boundaries
For controlled expansion, not chaos scaling. Request

Pricing clarity

We do not publish “from $X” numbers that attract the wrong buyers. The assessment exists to define scope, constraints, and acceptance — then pricing is fixed against that scope.

Support

Support is a boundary, not a dependency trap.

Support is time-bound when included. Extended support is paid and scoped. This protects stability and prevents infrastructure from becoming an unowned stream of requests.

What “support” means here

  • Stabilization: bug fixes and correctness against acceptance criteria.
  • Guidance: admin questions and operational clarification within scope.
  • Minor adjustments: only if they do not change scope boundaries.

Support is not “new features.” New work becomes an add-on with its own scope and acceptance.

What support does not include

  • Unscoped enhancements or redesign cycles.
  • Integrations not defined in the deployment scope.
  • Operational ownership: we do not run your business for you.
  • Unlimited “quick changes” that create drift.

If it changes requirements, it changes scope — and is treated accordingly.

Add-ons

Defined extensions (only when justified)

Add-ons are not upsells. They’re scoped extensions when your operational reality requires more.

Integrations & automation

Approval-gated automation, integrations, exception handling, and documented integration maps.

Governance hardening

Deeper role tiers, traceability layers, audit intent support, and change approval processes.

Rollout expansion

Multi-site rollout plans, training sessions, and staged adoption support with governance intact.

Extended support

Time-bound, scoped support extensions with defined response expectations and boundaries.

Add-on principle

If it changes the operating model, it’s scoped. If it introduces risk, it’s governed. If it creates dependency, it’s redesigned.

FAQ

Common procurement questions

Clear answers prevent scope drift and misaligned expectations.

Why don’t you publish fixed prices publicly?

Because “infrastructure” is not a commodity line item. We fix price against defined scope and acceptance criteria. Public “from $X” numbers attract the wrong buyers and force vague engagements.

Can we start small and expand later?

Yes. Expansion is handled through defined add-ons with their own acceptance criteria and change control. That keeps the system stable while it grows.

Do you offer ongoing retainers?

We do not force retainers. Support is time-bound when included, and extendable through scoped support agreements. The goal is continuity without dependency traps.

What happens if requirements change mid-deployment?

We assess impact, adjust scope, and update acceptance criteria. If the change is material, it becomes a defined add-on. This prevents drifting into unowned, unstable work.

Controlled intake

Request an infrastructure assessment — only if you want ownership.

If you want “someone to just do tasks,” this won’t fit. If you want a stable system with handover discipline and controlled change, proceed.

Start your request with: (1) the operational problem you want to stabilize, (2) who will own the system internally after handover, and (3) the constraints (sites, timeline, compliance/security expectations).

Engagement rule

We only accept work that can be:

  • Scoped Deliverables and exclusions are explicit.
  • Accepted “Done” is measurable, not emotional.
  • Handed over Your team can operate without dependency.