Skip to content
Solutions

AI-Enabled Applications

We build public-facing and staff-facing AI applications to your adopted policy, with a person reviewing every decision that touches a case.

What we usually find

The uses that would help most are the ones people already ask for: a self-help conversation that answers at 11 p.m., guided forms that reduce rejected filings, and document handling that returns hours to a clerk's week.

The first question we ask is whether something your agency already owns can be made to do this. Where the answer is yes, that is the recommendation, and it is a smaller and cheaper engagement than the one described below.

What follows is what the work looks like when the answer is no: the reference scope for a typical engagement, the variables that move what it costs, and what your agency holds at the end of it. Scoping is done by the engineers who will do the build, which is usually why the scope comes back smaller than an agency expects.

What a typical engagement includes

  • Use case selection against your adopted AI policy
  • Human review designed in at every decision that touches a case
  • Evaluation criteria agreed before the build, and measured after
  • Disclosure to the public where the tool is public-facing
  • Audit logging of what the system did and what a person decided
  • The model choice documented, and changeable without a rebuild

This is a reference scope, written in full before the work starts and adjusted to your agency during scoping. Anything included is written down, and anything left out is written down too.

What moves the price

Two agencies buying the same offering will pay differently, and these are the reasons why. We publish them because they are the questions we would ask in the first scoping session, and you can work out most of your own answers before that session happens.

  • Whether the content it answers from is already clean
  • Public-facing or staff-facing, which changes the review burden
  • How much evaluation you need before it goes live

What happens when scope changes

Scope changes on nearly every project. We manage changes through a documented approval process, so your agency sees the cost of a change before any work happens.

The change is documented
Anything outside the written scope is raised as a change request, in writing, as soon as we identify it.
The change is priced
You receive the cost and the schedule impact in writing before any work on the change starts.
Your agency decides
You can approve, defer, or decline the change. Declining does not affect the rest of the engagement.
No work proceeds without approval
No change is built or billed without your written approval.

What your agency owns at the end

The source code is yours, in your own repository from the first commit. Host it yourself, keep us on support, or move it later: all three options are priced in advance.

How Custom Digital Solutions runs, phase by phase

What it costs, and how it is bought

This offering is bought through the Build engagement, against a scope written and agreed before any work starts. We publish a price only once it is a commitment, so the band for this engagement is not on the page yet. Everything else about it is.

Builds usually depend on services such as hosting, email, messaging, identity, or payments. Your existing services are the starting point.

See engagements and pricing

AI-Enabled Applications

Price
From $60,000
Timeline
10 to 16 weeks
Bought through
Build

What we need from your team

  • A decision maker who can approve scope in one meeting
  • Access to the systems it must integrate with
  • Staff time for research and review, about 3 hours every two weeks

The safe first step

The readiness assessment is free, takes about 20 minutes, and returns a scored report you keep. It creates no obligation, no call, and no follow-up.