Low-Code Platforms

What this covers

Low-code platforms let agencies build forms, workflows, and applications quickly on top of tools they already license. HQT configures and extends these platforms, establishes governance so they do not sprawl, and knows when a requirement has outgrown them.

Typical activities

• Platform selection based on existing licensing and use cases
• Environment and governance design, including who may build what
• Application development for internal workflows such as approvals, inspections, and requests
• Integration with data sources and identity
• Center of excellence support and training for agency builders
• Migration of spreadsheet and email processes into managed applications

What you receive

Configured environments and governance, delivered applications, documentation, and training for agency staff.

Considerations for public agencies

Low-code applications still hold records and personal data. Governance covers retention, access, and lifecycle so that quick wins do not become unmanaged liabilities.

Signals that this work is needed now

Low-code work is usually prompted by an operational symptom rather than a plan. The common ones:

• A program runs on a shared spreadsheet with email approvals, and nobody can reconstruct who approved what.
• An agreement you already hold includes low-code capability, so staff have started building in it with no environment strategy and no support model.
• An application a program depends on was built in one employee's account, and that employee has moved on.
• A records request or an audit arrives for data held in an application IT did not know existed.
• Charges for premium connectors, capacity, or fulfiller licenses appear on a renewal nobody forecast.
• A department has built something residents use, and it has never been tested for accessibility.

Several of these at once usually mean the platform is already in use and the governance is not.

What a sound build looks like, and what a weak one looks like

In a sound build, applications and flows run under service accounts or service principals rather than an individual's credentials. Development, test, and production are separate environments, and publishing to production is a controlled step rather than a save. Changes move as exportable solution packages or update sets that can be versioned and rebuilt, not as edits made directly in production. Connections to systems of record run through documented, permissioned integrations rather than a personal credential or a nightly spreadsheet export.

Weak builds look alike: everything sits in the default environment. There is no test copy, so testing happens in production. Logic sits in a flow nobody documented, with values hardcoded where only the original builder knew to look. Access is granted by sharing a link. A vendor demonstrates a working application but leaves no way to move it, and nobody can say what the agency would have to rebuild if the platform or the license changed.

Identity, systems of record, and licensing

Low-code sits on top of your identity provider, so single sign-on, group membership, and conditional access policies decide who may build and who may use. It reaches into ERP, permitting, asset management, and case systems, and those vendors' integration terms, API limits, and support boundaries set what is possible. It also overlaps with modules you may already own, so check whether a feature of an existing system answers the request.

Licensing belongs in the review before design starts, because design decisions set the bill. Pricing models differ in kind, not only in amount: per user, per application, per capacity unit, and separate rates for staff who fulfill work and staff who only request it. Where an agency needs a government cloud offering for authorization or data residency reasons, its features and connectors can differ from the commercial equivalent, so a design that assumes a commercial connector may not be buildable there.

What to require in a solicitation

State these specifically rather than asking for low-code experience in general.

• Deliverables as exportable, versioned solution packages in source control the agency controls, not only a working application in your tenant.
• All artifacts owned by agency accounts in the agency tenant, with no dependency on a vendor account, vendor tenant, or vendor-held connection after closeout.
• A written statement of which environments the work will use, who may publish to production, and which connectors and data sources the design relies on.
• Accessibility testing evidence for anything the public or field staff will use, against the standard that binds you. Americans with Disabilities Act Title II rules adopt WCAG as the technical standard for state and local web content and mobile applications, with compliance dates that depend on the size of the entity. Screens the platform generates still have to be tested.
• A licensing forecast tied to the proposed design, naming premium connectors, capacity, and license types, and the design changes that would raise it.
• A statement of where records actually land, whether the platform data store, a document library, or the system of record, so retention applies where the data sits.
• Documentation written for the next builder: environment variables, connection references, and the logic inside each flow.

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