what “ai front end” actually means when your developer is gone

“We can put an AI front end on your existing SQL database” is the sentence we open with. It usually produces one of two reactions. The owner nods politely. The younger project manager leans in. Both are wondering the same thing: what, concretely, does that mean?

This is the plain-english version. No slides, no metaphors, no pretending it’s more magical than it is.

what already exists on your side

Your current setup is a database and an old application. The database is probably Microsoft SQL Server, MySQL, or PostgreSQL. It has, call it, 80 tables. Thirty of them are load-bearing — customers, jobs, invoices, employees, time cards, whatever your business tracks. The application on top of those tables is the thing that’s orphaned: the web or desktop UI your office team logs into every day. It still works. It’s just frozen — nobody’s changed it in two years.

The database is fine. That’s the key point. It’s the UI that’s the problem.

what we add

We sit a thin new layer between your team and the database. Three parts:

1. a modern web interface. Browser-based, works on a phone, updated-looking, faster than the old one. Your team logs into this instead of the legacy app (or alongside it, at first).
2. a description of your business rules. A document that says things like “when a job is marked complete, the project manager needs to approve it before it bills,” or “supply-house invoices get coded to the job via the PO number in the subject line.” This is the part that replaces what your old developer had in their head.
3. the AI. An LLM (large language model — the same kind of system behind modern chat assistants) that reads (1) the user’s request, (2) the business rules, and (3) the database, and generates the right screen, or the right answer, on demand.

The AI is not the whole system. It’s the thing that would otherwise require the old developer to be on-call. It handles “show me all open POs for customer X, sorted by age” — a query that used to take a ticket and a week — in about three seconds.

what stays the same

• Your data. Every row, every table, every column. We read from it. We don’t move it.
• Your existing integrations. If QuickBooks talks to your job-cost system today, it still does tomorrow. We don’t break the wiring.
• Your workflows. The office team still does the same work. They just do it through a better window.
• Your ownership. You own the database, the new front end, the business-rules document, and every line of code we generate. We put it in your git repository, not ours.

what changes

• The frozen parts of the old UI get replaced by a UI that can change. “Can you add a column showing job age?” becomes a conversation instead of a project.
• Search and reporting become conversational. You type what you want, in english; the system generates the query and shows you the answer. For the owner who never wanted to learn the old application, this is the moment the business becomes legible to them again.
• New integrations get easier, because the business rules are now written down instead of tacit. Connecting a new supply-house portal is a two-day project instead of a two-month one.

what it costs, honestly

A resurrection project at this size — one SQL database, one or two primary workflows, modest integrations — is typically $15,000 to $50,000 up front, plus a small monthly fee for the AI usage (usually under $300 a month). That’s the cost to get the new front end standing and your team using it.

The price varies based on how messy the database is (see our field guide to auditing it), how many integrations are in scope, and how much handholding your team needs on the switch. We quote fixed-price after a week of discovery. We don’t do hourly.

what it doesn’t do

A few things we want to be clear about, because the AI-hype cycle has muddied them:

• It doesn’t make decisions for your business. It doesn’t approve invoices, pay bills, or fire employees. It produces screens and answers; humans still act.
• It doesn’t hallucinate your data. We constrain it to only read what’s actually in your database. It can’t make up a customer or invent a row.
• It doesn’t replace your office team. It lets them stop doing the five hours a week of data re-entry and spend that time on exceptions and customer relationships.
• It’s not magic. It won’t fix bad data. If your customer table has 40% empty email fields, this system will have the same problem — just visible faster.

what the first week looks like

Concretely:

1. Day 1-2: we read your database. Row counts, schema, a sample row per table. Nothing changes on your side.
2. Day 3-4: we sit with your operations lead and document, in plain english, the business rules for the first workflow we’re tackling. Usually something narrow — job creation, or invoice approval, or time-card reporting.
3. Day 5: we demo a working version of that workflow’s new front end, reading from your real data, on a URL only you can see.
4. End of week one: you have a go/no-go decision with something real in front of you, not a slide deck. If it’s no-go, you keep the database audit and the business-rules document. They’re yours.

That’s the shape of it. If this is the kind of thing you’ve been circling for a while, the right next step is a phone call. Talk to a builder is the button for it.

---

Want to talk through this in the context of your shop? Talk to a builder. No pitch deck, no sales motion — just a conversation.