Technology partner for local government IT directors

You are the IT department, or most of it. The same handful of people run the network in city hall, the switches in the corp yard and the fire stations, the phone system, the finance and payroll platform, the permitting system, the mobile data in patrol cars, the GIS layers the water crew uses in the field, and the laptops of every elected official. There is no separate security team, no separate network team, and no tier one desk that belongs to somebody else. When the treasurer cannot close the month or a dispatcher drops a connection, the call comes to you regardless of whose name is on the software.

Almost none of it is yours to change on your own. The systems that matter most were bought by departments, are hosted by vendors, and are governed by contracts signed before you arrived. Your real work is sequencing: which system gets replaced this cycle, which risk gets accepted for another year, which vendor gets pushed and which gets paid. Then you have to explain that sequence in a few minutes to a manager, a council, or a board weighing it against street repair and staffing, in language that does not require anyone to know what an API is.

What makes this hard

Systems that can neither be left alone nor easily replaced: the finance or utility billing platform predates most of your staff, the vendor has been acquired twice, and the upgrade path requires a project nobody has the hours to run.
Security work grows every year without headcount: multi-factor rollout, logging, endpoint response, vendor risk reviews, insurance questionnaires, and audits for whichever regimes your departments fall under, from criminal justice data to payment card handling.
Departments buy software without telling you, then bring it to you at go-live expecting an integration, a security review, and a place on the network.
Institutional knowledge lives in one person's head, and a single resignation can leave a critical system with nobody who knows how it was configured or who to call.
You compete for technical staff against larger agencies and private employers on a salary schedule you do not control, and recruitments can sit open for months.
Vendor management is a full job by itself: renewal dates, hosted platforms whose service levels you cannot practically enforce, and support queues that treat an agency of your size as low priority.
Explaining technical risk to leadership who reasonably compare it to potholes, overtime, and staffing, and who hear the same request each budget cycle until something breaks publicly.

How HQT helps

Security assessments against the NIST Cybersecurity Framework or the CIS Controls, scoped to the systems you actually run, written in two registers: findings your team can act on, and a short section your manager or council can read without translation.
Integration between the platforms you already own, so finance, permitting, work orders, dispatch, and GIS stop depending on staff re-keying the same data into three systems.
Identity and access work: consolidating accounts across departments, rolling out multi-factor authentication with phishing-resistant methods for finance and administrator accounts, and designing an access review that department heads can actually finish.
Backup isolation, tested restores, and a written recovery plan, followed by a tabletop exercise with finance, legal, the clerk, and the public information officer in the room rather than IT alone.
Custom applications and automations for the gaps commercial products do not cover: the spreadsheet that quietly runs a program, intake and routing forms, and the monthly report someone assembles by hand.
Technical requirements, evaluation criteria, and independent review for a procurement your team is running, with a clear statement upfront about whether writing those requirements would make us ineligible to bid on the result.
Documentation and handover treated as part of delivery, not an extra: diagrams, runbooks, credentials stored in your own vault, and working sessions so your staff can operate what we build after we leave.

How engagements usually start

Most work with an IT director starts narrow, and something usually has a date attached: a cyber insurance renewal whose questionnaire asks about controls you do not have yet, an audit finding, an upgrade the vendor has already scheduled, a grant with a spending window, or a system whose only administrator just gave notice. The first conversation is about that one thing, not a roadmap. That is the right way to begin, because a partner who cannot deliver one contained piece of work well is not worth a multi-year plan.

We prefer to start with a small, fixed-scope engagement that leaves you something useful whether or not anything follows: an assessment with a prioritized finding list, an inventory of applications and the integrations between them, a written and tested recovery plan, or one integration built and documented. Work sized that way often fits within an IT director's own signing authority, though purchasing thresholds vary by state law, charter, and local ordinance, so we confirm yours with your purchasing officer before scoping rather than assuming. It also gives you evidence for the larger budget request that usually comes next.

Before writing anything, we ask for a walkthrough: what you run, what is hosted elsewhere, who supports each system, what the last two outages were about, and which departments buy their own software. If the honest answer is that the problem is a contract term or a staffing gap rather than a project, we will say so.

What to ask any technology partner

The questions that separate a partner from a reseller are specific, and you should ask them of everyone, including us.

Who exactly will do the work, and will those same people still be assigned in month six? Ask for names and time commitments in writing.
What do we own at the end? Source code, infrastructure definitions, diagrams, data, and credentials should be yours, in your own repositories and vault, with no further license fee.
What happens if we stop working with you? A partner should be able to describe the handover concretely: where the code lives, who else could maintain it, what would break first.
How will my team support this? Ask what training, runbooks, and documentation are included, and who answers the phone at two in the morning after go-live.
How will you work with our existing vendors? Most of your environment belongs to someone else. Ask how they handle a platform vendor who will not open an API, or who blames your network for their outage.
What will you refuse to do? Anyone who agrees to every request has not read your environment carefully.
What is the five-year cost, including hosting, licensing, and the support hours you will need after delivery?

HQT builds, integrates, and secures systems for state and local agencies, and we would rather answer those questions before a contract than during one.

Frequently asked questions

We already have a managed services provider. Where would you fit?

A managed services contract usually covers the help desk, endpoints, and the network, and stops at the application layer. We work above that line: integrations between your platforms, custom applications, data and reporting, and security program work that most managed services agreements exclude. We are comfortable working alongside an incumbent provider, and we prefer to write down which of us owns which system before the work starts.

Our team is three people. Will we actually be able to maintain what you build?

That is a scoping constraint for us, not an afterthought. We will tell you before work begins what ongoing maintenance looks like in hours and in skills, and we will favor an approach your team can run over one that requires a specialist you cannot hire. Diagrams, runbooks, and working sessions with your staff are part of delivery, and we would rather build something smaller that survives than something elaborate that stalls when one person leaves.

Can you work with the software vendors we already have?

Yes, and most of this work requires it. We integrate with platforms we did not sell and hold no reseller relationship with, which means we can tell you plainly when the limitation is the product rather than your configuration. Where a vendor controls the API, the export, or the data model, we document what is genuinely possible before you commit to a plan or a budget.

We cannot run a formal solicitation for this. How does purchasing usually work?

We scope to the purchasing path you actually have, whether that is a direct purchase within your authority, a cooperative agreement your agency is permitted to use, or a subcontract under a firm already under contract with you. Thresholds and cooperative purchasing rules differ by state and by local ordinance, so we ask your purchasing officer early rather than guessing. If a solicitation is required and you want help writing technical requirements, we will say upfront whether that would disqualify us from bidding under your conflict of interest rules.

Can you help us pursue cybersecurity grant funding?

We can help you describe scope, cost, and milestones in the form a grant application asks for, and design the work so it can realistically be completed inside an award period. Federal and state programs supporting local government cybersecurity have existed in recent years, but availability, cost-share requirements, and deadlines shift with appropriations and with how each state administers its share, so confirm current terms with your state administering agency. We will not tell you an application is likely to be funded.