IQEX: a platform that generates with AI, and knows exactly what each generation cost

The simple version of an AI platform charges a subscription and hopes usage averages out. It works until one customer generates ten thousand images, and then it works badly for everybody, because the response is either a surprise invoice or a quiet degradation of the service.

The metered version is honest and much harder to build. It requires the platform to know, for every model of every provider, what a call actually costs, and providers do not price the same way. Some charge a flat rate per call. Some charge by the character. Some by the image. Some by the request. A single credit price applied across that produces margin that varies by an order of magnitude depending on which feature a customer happens to like.

And the cost is a moving target. Providers change prices. A margin report built by applying today's rates to last quarter's activity describes a business nobody ran.

What we did

Supplier price and credit price are separate fields, set per provider and per model, with the cost model recorded alongside so a per-character service is not treated like a flat-rate one. The effective rate falls out of the two, and it is visible before anybody is charged.

The real cost is stamped onto each activity as it happens. An image generated in March carries March's provider cost forever. Nothing is recalculated from a price list that has since moved.

Provider health is monitored rather than discovered. Keys have a status and a verification date, because an expired key does not degrade the platform, it stops AI working for every customer at once. Prepaid allowances are watched with a warning before they run out.

Two wallets, one order. A person has their own balance and their organisation has a shared pool, personal is spent first, and the visible total is what is actually available. Card payment is handed to a payment provider on their own hosted page, so card details never reach the platform.

These are the actions that move money or change what customers are charged, performed by the smallest number of people and reviewed by nobody in the ordinary course of a day. They are exactly the ones a metered platform cannot afford to leave untraced, and an unlogged manual credit grant is the same category of gap as an unlogged refund would be anywhere else.

The record is written where the application cannot revise it, so it shows what happened rather than what the current configuration implies happened.

The platform lets a customer build a pack of their own material, documents, web pages, recordings and pasted text, and then ask questions of it.

Retrieval systems fail quietly, and that is the whole problem. If a source did not load, the question still gets an answer. The answer is fluent, confident and missing whatever was in the document that was not there. Nothing errors, nothing is flagged, and the person asking has no way to know the difference between an answer drawn from twelve sources and one drawn from nine.

Web pages make it worse. A great many sites refuse automated readers, or require a sign-in, or return a page that technically loads and contains almost no text. All three look identical to a person pasting a link.

What we did

A verdict before the pack is saved. Testing a link returns one of four answers: it will read, it is blocked or needs a sign-in, it loads with almost no text, or it is dead. That happens while somebody has the source in front of them and can do something about it, rather than months later when nobody remembers where it came from.

A blocked source has an answer rather than a failure. If a site refuses robots, the text can be pasted in directly and the pack is complete anyway. The system tells the person what to do instead of what went wrong.

Indexing reports per source, not per pack. Progress, which step failed, when and why. And the extracted text is visible, so somebody can check what was actually read out of a file rather than assuming.

The same packs sit behind form questions, so a form can ask something answered from the organisation's own material.

Thirty-five modules is a great deal of product, and no customer needs all of it. A museum building location-triggered experiences has no use for billing reports. A training provider collecting form data does not need a media timeline editor.

Shipping everything to everybody is not neutral. Every module a customer does not need is a thing they have to learn to ignore, and a support conversation waiting to happen.

The usual answer is a build per segment, or a set of feature flags that accumulate until nobody can say what a given customer actually has. Both end the same way: several products with one name, and a fix that reaches most of them.

What we did

Two things decide what a person sees. Their role, which governs what they may do and which figures they are shown, and their organisation's settings, which govern which module groups exist for that customer at all.

Roles are three, not a matrix. Somebody who runs the platform, somebody who runs one customer account, and somebody who works inside one. Each sees a different scope of the same screens rather than different screens.

One module is always present, so no configuration can produce an empty application.

The same principle runs everywhere else. Categories, defaults, credit packs, prompt templates and automation recipes are all data. An automation is defined once, given a form to collect its inputs, a credit cost and a category, and it appears for the people entitled to run it.

Form answers flow outward into the spreadsheet, database or document system a customer already works in. Setting that up takes a few minutes. It then runs for months with nobody watching it, which is where the real design problem lives.

Access granted to another service expires. That is not a fault, it is how those services are built. But an expired credential produces exactly the same visible result as a working one: nothing. No error reaches the customer, rows simply stop arriving, and the discovery is made weeks later by somebody looking for data that was never written.

What we did

Connecting hands authentication to the other service. The customer signs in there, and the platform never receives a password.

Field mapping is suggested and then corrected. Columns are proposed automatically and adjusted by a person, because a suggested mapping accepted without review is a data quality problem with a delay on it.

Every send is a job with a state. Synced, pending or failed, with the number of attempts and when the last one was, and a failed job can be pushed through again rather than re-entered by hand.

Every connection has a health. Active, paused, disabled or expired, with the last refresh shown and a reconnect action. Expiry is treated as an expected state rather than an incident.

Failures are counted in one place. How many connections exist, of what kind, and how many jobs have failed, so somebody can look at a number rather than wait to be told.