Software Development
Web Portals & Online Services
Resident-facing services that are accessible, mobile-friendly, and easy to maintain.
What this covers
Residents expect to apply, pay, report, and check status online. HQT builds public-facing portals and online services, integrates them with back-office systems, and designs them to be usable on a phone by someone in a hurry.
Typical activities
- Service design based on how residents actually complete a task
- Forms, payments, document upload, and status tracking
- Integration with permitting, licensing, billing, and case management systems
- Identity and account options including guest access where appropriate
- Content management system implementation and governance
- Accessibility, plain language, and multilingual support
What you receive
A launched service with integrations, a content and maintenance plan, analytics, and accessibility conformance documentation.
Considerations for public agencies
Public services must meet accessibility law, protect personal data, and remain available during peak periods such as deadlines. We plan for all three from the first design session.
Signals that this work is due now
Agencies rarely set out to buy a portal. What happens is that the counter and the phone line absorb work a form should be handling. Before writing a scope, check whether these are true of a specific transaction:
- Staff retype submissions from email or PDF into the system of record.
- The most frequent call on the main line is a status check the applicant could look up.
- The online form is a fillable PDF that still has to be printed, signed, scanned, and mailed.
- Most people reach the form on a phone, and it works properly only in a desktop browser.
- Each department bought its own portal, so a resident holds several logins for one jurisdiction.
- There has been an accessibility complaint, a demand letter, or an audit finding.
If several hold, the problem is service design and integration rather than appearance. Re-skinning the same transaction changes none of them.
What finished looks like, and the common failure modes
The test is narrow: someone on a phone, doing this once every few years, starts and finishes without calling. That implies plain language questions in an order a person can answer, logic that skips what does not apply, saving and returning after a timeout, required documents and fees stated before the first question, and errors that name the field and the fix. It also implies a program administrator can change a fee or a deadline without a developer ticket.
Failure modes show up early:
- The portal is a document library, and the real transaction is still print, sign, scan.
- An overlay script is offered in place of correcting markup, labels, and focus order.
- A login is required before anyone can see requirements, fees, or status.
- The mobile view is the desktop layout scaled down, and upload from a phone camera fails.
- Notices with legal effect are machine translated with no human review.
Deciding how the portal meets the system of record
A portal is usually a thin front end over systems the agency keeps: permitting and land management, licensing, utility billing, tax and revenue, case management, and a payment processor. Settle these per transaction before design starts.
- Does the portal write to the system of record as the resident submits, queue submissions for staff review, or hand over a batch? Real-time writes need a supported interface, which is where incumbent licensing and change orders surface.
- Is that interface in the current contract, priced separately, or not offered at all? Get the answer in writing. It shapes scope more than any design decision.
- Where are card details captured? Hosted payment fields or a redirect to the processor keep card data off agency systems and narrow PCI DSS scope without removing the obligation. Confirm who holds the merchant account, whether a service fee is allowed under state law and card network rules, and how deposits reconcile.
- Which credential do residents use? Reusing a statewide or enterprise identity service avoids issuing another one, and stronger identity proofing belongs only where the risk of impersonation justifies the friction.
What to write into the solicitation, and what to measure after launch
Accessibility belongs in acceptance criteria rather than in a promise: name the conformance target, require manual testing with a keyboard and a screen reader alongside automated scans, require an accessibility conformance report for the platform being proposed, and make defects found during warranty the vendor's cost to fix.
Ask as well for source code, content, and configuration in a repository the agency controls; a documented export of submissions and attachments; retention and electronic signature handling consistent with state statute; a page weight and load time budget measured on a mid-range Android phone over cellular; and load testing at deadline volume before go-live.
After launch, watch completion rate by transaction, drop-off by step, the share of submissions staff have to correct, call volume for that same transaction, elapsed time from submission to decision, and payment failure rate. Take a baseline for each before the old process goes away.
Working with HQT on this
HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.
Frequently asked questions
How long does it take to put a permit or license application online?
The schedule is usually set by integration and policy review rather than by building the form. If the system of record already has a supported interface and the program office can approve simplified questions, a single transaction can move from discovery to launch inside one budget cycle. If the interface has to be bought from the incumbent vendor, or the statute behind the form has to be read again first, treat that as separate lead time. Ask any vendor to take one transaction end to end before you commit to a catalog of them.
Do we have to replace our permitting or licensing system to offer online services?
Usually not. Most resident-facing portals sit in front of the system already in place, either writing to it through an interface or queuing submissions for staff to review. Replacement becomes the real question only when the existing system cannot accept outside submissions at all, or the vendor will not expose a way to send them. Confirm which of those situations you are in before scoping a modernization.
What accessibility standard does a government portal have to meet?
Level AA of the Web Content Accessibility Guidelines is the conformance level most often referenced in state and federal requirements. Under Title II of the Americans with Disabilities Act, the Department of Justice has adopted a technical standard for web content and mobile applications provided by state and local government, with compliance dates that depend on the size of the entity. Many states also maintain their own standard and required procurement language. Ask counsel which version and date apply to your agency, then write that target into the contract with manual assistive technology testing as part of acceptance.
Can we take online payments without bringing our systems into PCI scope?
You can narrow the scope considerably by keeping card data off agency infrastructure, using hosted payment fields or a redirect so your systems never store or transmit the card number. That reduces the assessment burden but does not remove the obligation. You still need clarity on who holds the merchant account, whether a service or convenience fee is permitted under state law and card network rules, and how the daily deposit reconciles to the financial system. Bring finance or the treasurer into that discussion early.
Should residents have to create an account to use an online service?
Not for every transaction. Requiring registration before someone can pay a bill or report a problem adds a step that people abandon, so guest access with a confirmation number is often the better default. Accounts earn their place when a person needs to save a draft, track status, or see history across filings. Identity proofing beyond a verified email belongs where the risk of impersonation justifies the friction.