Government, civic, and public-sector software
Digital Public Service Software Cost and Budget Guide
A lifecycle budgeting framework for agencies, municipalities, nonprofits, and delivery partners planning a transactional public digital service without false fixed-price certainty.
Published by Kennedy Gichobi · Fact-checked by OpenAI Codex research review · Published · 1516 words
Cost begins with the complete public journey
A public-service website that explains eligibility is different from a transactional service that accepts an application, verifies identity, evaluates information, collects payment, routes professional review, issues a decision, supports appeal, and preserves a public record. Both may have a small number of screens, but their policy, evidence, accessibility, security, integration, and operating costs are not comparable. A responsible budget starts with the service journey and consequence, not a generic price per page.
Map the journey from finding the service through understanding it, preparing, applying, saving, submitting, paying where relevant, receiving status, correcting information, responding to a request, obtaining a decision, seeking review, and retaining or disposing of the record. Include people using mobile devices, assistive technology, limited connectivity, shared devices, different languages, delegated helpers, paper or in-person channels, and no digital identity. Name every handoff and the authoritative system for each decision.
Do not assume one jurisdiction's requirements apply everywhere. Public-sector policy, procurement, records, accessibility, identity, privacy, security, language, payment, and appeal obligations vary. Qualified agency counsel, program owners, records officers, accessibility specialists, privacy and security staff, finance, procurement, and frontline teams must define the applicable boundaries. Engineering should convert those decisions into explicit states, permissions, evidence, tests, and recoverable operations.
Fund discovery as a deliverable with decision value
Discovery should produce a service map, user groups and access needs, policy-to-decision model, authoritative-system matrix, data inventory, identity and delegation model, integration assessment, security and privacy boundary, accessibility plan, representative scenarios, content model, migration profile, staged scope, acceptance plan, operating model, and estimate range with assumptions. It should identify questions that require policy or legal resolution instead of hiding them in development tickets.
Research must include people who experience barriers and staff who handle exceptions. Observe current forms, phone calls, office visits, spreadsheets, letters, approvals, and informal workarounds. Quantify demand and failure with available evidence without turning vulnerable users into analytics targets. A statistically impressive funnel is not enough if abandonment represents an inaccessible step or a policy requirement that no one can understand.
USWDS sample contract language proposes evaluating an MVP on accessibility, consistency, authority, searchability, security, user-centered design, customization, and mobile use. Use scenario-based outcomes in procurement rather than only a fixed feature inventory. An early working slice should expose policy and integration risk before the project commits to a large implementation.
Estimate policy and case workflow explicitly
Model applicant or participant, organization, representative, service, program, application, household or business context, evidence, task, review, decision, notice, payment reference, appeal, record, and event separately. Preserve effective dates and the policy version used. A rule change should not silently recalculate a historical decision or make an earlier reviewer appear to have used today's criteria.
For each decision, record inputs, sources, missing information, responsible role, approval, reason, notice, correction, and review path. Software may assist with routing or calculations, but qualified officials must determine where human judgment, legal authority, or independent review is required. Avoid inscrutable automation. A person should receive an understandable status and next step without exposing protected internal information.
Price the difficult paths: incomplete application, duplicate person, conflicting evidence, delegated representative, changed household, missed deadline, exceptional policy, inaccessible document, suspected fraud, staff reassignment, withdrawn request, appeal, and corrected decision. Simple happy-path forms are inexpensive; accountable exception handling and defensible history are the real product.
Include identity, privacy, records, and security from the start
Decide the lowest level of identity assurance needed for each action. Do not require a high-friction account merely to read information or check non-sensitive eligibility. Where identity is needed, budget account recovery, name changes, shared contact details, representatives, organizational users, device loss, fraud response, and a non-digital alternative. Identity-provider integration still needs a local authorization and delegation model.
Inventory collected data, purpose, authority, access, sharing, retention, legal hold, archive, export, and disposal. Separate public records from protected information and operational logs. Avoid copying sensitive evidence into analytics, support tickets, or notification text. Security work includes threat modeling, least privilege, managed secrets, separate environments, dependency controls, upload scanning, audit evidence, monitoring, incident response, backups, and restoration tests.
NIST's Secure Software Development Framework provides practices for preparing the organization, protecting software and artifacts, producing well-secured releases, and responding to vulnerabilities. Budget those practices as delivery work, not as a final certification exercise. Require suppliers to explain repository and account ownership, build integrity, vulnerability handling, sub-processors, support access, incident cooperation, and exit.
Budget accessibility, content, language, and assisted service
Digital.gov notes that U.S. federal digital services are affected by extensive policy across accessibility, privacy, security, design, and user experience. Other governments have their own frameworks. Use WCAG 2.2 as a modern web baseline, then identify binding local requirements and test the actual service with disabled people and assistive technologies. Automated scans do not establish accessibility.
Budget content design, plain-language review, error messages, status communication, document accessibility, translation and localization where required, reading-level needs, and consistent help. Test keyboard and screen-reader use, zoom, contrast, reflow, timeouts, authentication, uploads, signatures, calendars, tables, generated PDFs, and recovery from errors. A technically conforming form can still fail if people cannot understand what evidence is being requested.
Preserve assisted channels. Staff need a governed way to help, save, explain, correct, and escalate without impersonating a person or bypassing evidence. Paper, phone, and office interactions may feed the same case workflow through different capture paths. Budget training, scripts, quality review, workload changes, and channel reconciliation; software does not eliminate service operations.
Price integrations and migration by failure behavior
For each identity, payment, notification, records, document, finance, GIS, eligibility, registry, or legacy case system, assess authorization, commercial or interagency access, documentation, stable identifiers, schema, event behavior, latency, rate, history, test environment, privacy, retries, idempotency, reconciliation, monitoring, support, and change control. One inaccessible legacy database can dominate the project.
Define what happens when a payment succeeds but the case update fails, a notification provider accepts only some messages, a registry is unavailable, an address changes, or two systems disagree about status. Budget durable queues, safe retry, visible stale state, exception ownership, replay, and reconciliation. A green API response is not proof that the intended public-service transaction completed.
Migration requires inventory, profiling, mapping ownership, cleansing, rehearsal, validation, cutoff, rollback, and post-cutover support. Preserve record identifiers, relationships, documents, permissions, decisions, notices, holds, and history. Do not migrate every low-quality field automatically or discard old evidence because the new schema lacks a place for it. Records and program owners should approve disposition.
Stage delivery around one complete service slice
A useful first release serves a real, bounded group through one meaningful outcome: understand, apply, save, submit, receive status, support staff review, issue an accessible communication, correct an error, and operate the service. It includes authentication only where justified, production monitoring, security, recovery, support, content ownership, accessibility evidence, and data export. It is not a disposable prototype masquerading as a launch.
Estimate discovery, design, content, policy resolution, architecture, integration proofs, implementation, migration, security, accessibility, scenario testing, training, deployment, observability, support, and stabilization. Keep contingency explicit for policy, procurement, legacy interface, and data uncertainty. Use gates based on evidence: task success, accessibility findings, integration reconciliation, staff handling time, unresolved exception backlog, recovery result, support load, and equitable service outcome.
Scale only after learning. More programs, languages, regions, user roles, integrations, and automation multiply operating complexity. Create reusable components and a governed service pattern, but do not force different policies into one inflexible workflow merely to claim platform reuse.
Require a transparent lifecycle proposal
A proposal should state users, volumes, channels, policy assumptions, authoritative systems, identity and delegation, integrations, migration, accessibility, content and language work, security, privacy, records, environments, acceptance, deployment, operations, support, ownership, export, and change process. It should identify excluded agency responsibilities and evidence that will refine the estimate. Fixed precision before discovery hides uncertainty rather than removing it.
Continuing cost includes hosting, shared services, monitoring, backups, certificates, security response, accessibility regression testing, content and translation updates, policy changes, browser and device change, integration change, support, incident handling, staff training, analytics governance, and roadmap work. Define service hours, severity, escalation, public status communication, release windows, rollback, and supplier transition.
Use the public-service application requirements checklist for detailed workflow design and the permit and licensing checklist for regulatory applications. Share the jurisdiction, service, users, channels, policy boundary, systems, data volume, accessibility and language needs, procurement constraints, and target outcome through the project questionnaire, or use quick contact to identify the largest budget uncertainty first.
Authoritative references
Related software planning guides
- Digital Public Service Requirements Checklist
- Emergency Response Coordination Platform Requirements
- Permit and Licensing System Requirements Checklist