It has been a while between posts. That is usually a bad sign for a product blog and a good sign for a product.

Here is the short version: Demiton for Android is built, submitted, and sitting in Google's review queue right now. It goes live the moment they clear it - which is their clock, not ours, so we are not going to put a date on it. Follow along and we will say the day it lands.

The reason it took until now is the second half of this post.

The app

Demiton for Android - the home screen composer

The thing we kept hearing was some version of the same sentence. The answer exists, but I'm in a ute.

Site supervisors and project managers do not spend their day in front of a dashboard. They spend it moving between a job, a yard, a client meeting and a subcontractor who wants to know why an invoice hasn't been approved. The information that would settle any of those conversations is sitting in the accounting system, or the scheduling system, or a site diary that somebody filled in on a tablet nine days ago.

So the mobile app does exactly one thing, which is the same one thing the platform does: you ask a question in plain language, and it answers from the systems your business already runs on.

What's in v1.0.0:

Live answers, streaming. You watch it think - not a spinner for eleven seconds followed by a wall of text.
Attach a photo. Send a picture straight from the field into the conversation.
Chat history in a sidebar. Past conversations are organised and searchable, not a scroll of the last thing you asked.
Organisation switching. If you have access to more than one org, switch without signing out. That used to bounce you through a browser re-login; it is now a single request and you stay where you are.
Proper single sign-on. OAuth 2.1 with PKCE against the API, tokens held in the device keystore, never on disk in the clear.

Questions it is built for are the ones you'd otherwise ring somebody about:

Where is the 30-tonner, and what has it been doing this month?
How is Stage 2 tracking against budget?
Who was on site last Thursday?
What did the site diary record last week?

Coming to iPhone

The iOS build runs from the same codebase and the same shared services as the web app. It is behind Android in the queue, not in the code.

Getting set up stopped being a compliance form

The old first-run experience was a wizard that asked for your ABN, your work types, your standing profile and your obligations. All useful data. None of it what a new customer actually came for.

That is retired. The new flow asks a different question: what are you trying to achieve?

You multi-select up to four outcomes - win more tenders, understand margin, get your systems talking to each other - and the platform expands those into the specific set of connectors it needs. Not a catalogue of thirty-four systems to browse. A short list, derived from what you said you wanted.

Then it handles the part that historically killed onboarding stone dead: getting the credentials.

Systems that use browser-based authorisation (Xero, Dropbox, Microsoft 365 mail, SharePoint, Teams) get a consent link. Nobody types a secret anywhere.
Systems that need a key generate a single-use, expiring, token-gated form that goes to whoever actually administers that system - your IT provider, your bookkeeper, whoever. They fill it in once. It is encrypted at rest before it lands in the database, with a dedicated key separate from everything else.

The old pattern here - and we are not proud of it - was an email template asking someone to reply with the client secret. That is gone.

Behind the flow, a durable workflow waits for each of those human steps. Not a cron job checking a flag: an actual orchestration that can wait days for a credential to arrive, survive a deploy in the middle, and pick up exactly where it was.

And when you name a system we do not support yet, a research agent goes and reads that vendor's API documentation and drafts an adapter specification for review. It does not build anything on its own - a person approves the spec and a person builds it - but the research step that used to take an afternoon now happens while you are still on the call.

One queue for bid decisions

Tender intelligence had a structural problem: public tenders lived in one place, and the opportunities that arrive by email lived in another. Two screens, two mental models, and no way to say "these six are worth chasing" across both.

They are now one queue, and the queue has actions on it.

It learns. Every time you correct a call - this one's a bid, that one isn't, and here's why - that correction is captured. Not as a thumbs-up on a black box, but as a rule you can see, edit, and turn off. The learned rules sit in a panel; the overlay shows you which rule fired on which opportunity. Batch-select a dozen at once and give them all the same reason in one tap, with an undo.

It tells you when it isn't ready. The readiness checklist is three-state, not a green tick that lies. If the classifier is working from a partial picture, it says which piece is missing and who owns getting it.

It links out to where the work actually happens. An opportunity row carries its SharePoint folder and its opportunity record in your finance system. One click, not a hunt.

Machine-learning readiness is now visible. Win/loss prediction and margin watch both need a certain shape of historical data before they mean anything. Rather than shipping a model that quietly guesses on thin data, there is a panel that tells you what the pipeline has, what it needs, and what is still missing. When it goes green, the number is worth reading. Until then, we are not going to pretend.

Alongside it, the email intake pipeline got a durable per-email ledger and a daily digest, so an opportunity that arrives at 4:55pm on a Friday cannot fall through a gap between two systems - and if the pipeline finds a probable duplicate, it raises it for a human decision instead of silently dropping one.

Answers that tell you what they read

This is the least glamorous work of the last month and probably the most important.

An AI answering from your operational data has a specific failure mode that is much worse than being wrong: being confidently partial. It reads eight hundred of the four thousand rows that matched, answers from the eight hundred, and says nothing about the other three thousand two hundred. You get a number. The number looks fine. It is not fine.

We went after that directly.

Capped reads now report the true total. If a read hit its ceiling, the answer says how many rows actually matched - derived from the same query that did the reading, not an estimate.
Every source reports its own coverage. Full, partial, or none - per system, per dataset. You can see that the answer had complete visibility of your plant register and only partial visibility of last quarter's site diaries.
A read that never ran no longer describes a scope it executed. If a lookup failed, that is what it says.
Permission denials name the fix. Instead of "you can't see that", the response names which role grants that access, so an administrator can act on it without a support ticket.
Ambiguity is asked about, not guessed. Where a project or asset name resolves to more than one thing, the platform asks - and records that it asked, what you answered, or that the question could not be put to you.

None of that makes a demo shinier. All of it is the difference between an answer you can put in front of a client and an answer you have to go and check.

The principle

Where Demiton cannot answer, it says so. A refusal you can trust is worth more than a number you have to verify.

Identity: the same crew member, the same machine, across every system

If your scheduling system calls a machine EX-14, your finance system calls it Excavator 14 (30t), and the maintenance log calls it by its serial number, then any question that crosses those three systems is guesswork.

We have been building the linkage layer that resolves that, and this month it grew a human side:

Typed identity bridges for workers and plant - registration numbers, serial numbers, exact-label matches - with a guard that stops a single source writing conflicting links.
A Merges tab where proposed links are reviewed in the same place you look at the entities themselves.
Steward controls: approve, retract, and explain. Every link says why it was made and who made it, and it can be pulled back.
A per-tenant measurement report, so linkage quality is a number that moves rather than a vibe.

Proposals are proposals. Nothing links itself into your data without a person saying yes.

New connector: Employment Hero

Employment Hero HR joins the supported systems this month - OAuth2 with PKCE, adapter, and configuration UI. Read paths are live; writes are next.

The floor under all of it

None of this is user-facing. All of it is why the user-facing part can be trusted.

Durable execution. Long-running work has been moving onto Temporal - a workflow that waits three days for a person to do something, then continues, and survives every deploy in between. It runs alongside the existing engine rather than replacing it in one jump.

Structural tenant isolation. Enforcement of the tenant boundary moved from convention to structure, with statement timeouts and a capacity model behind it. One customer's query cannot become another customer's outage.

Observability, end to end. Errors and performance traces now carry a release, a deployment, a request ID and a tenant. Job queues and caches are instrumented. There is a heartbeat monitor on the every-minute job, and an alarm that fires if the error pipeline itself goes quiet - because "no errors reported" and "error reporting is broken" look identical until you check. We retired the second observability stack that never delivered a single trace.

Infrastructure as code. Sentry and Netlify are Terraform-managed with drift detection in CI, and the first slice of the cloud estate has been imported.

Memory substrate. The data layer that everything reads from got re-grained so that each dataset declares its own freshness policy and scope in one place, enforced by database constraints rather than by hoping every code path remembers. Deeply unglamorous. It is what makes the coverage reporting above possible at all.

What's next

The public roadmap is now published in the docs - Now, Next, Later, Someday - rather than living in my head and a spreadsheet. Short version of Next: iOS, the tender response agent, and turning the win/loss readiness panel green.

But the one we are watching this week is a review queue in Mountain View.

Try it

New to Demiton? Create a free account at demiton.io now - the web app works today, and the same login signs you into Android the day it lands. The free tier gets you the public procurement data - awarded contracts, market share, recompete timing - without connecting anything.

Demiton for Android is with Google