AI features in apps
Natural-language input, extraction, classification, summarisation and assistive workflows built into a product people can actually use.
AI products · Cornwall, UK
Direct answer
I’m Nathan Cole, an independent app and web developer based in Cornwall. I build controlled AI features inside real products—combining the model with permissions, structured data, validation, human review and a dependable non-AI path.
Tell me about the workflowWhat I build
A model call is not a product. The useful work is deciding what the feature may do, what evidence it needs, how a person checks it and what happens when it is uncertain or unavailable.
Natural-language input, extraction, classification, summarisation and assistive workflows built into a product people can actually use.
Strict output contracts, validation, permissions, confirmation steps and audit-friendly boundaries around model behaviour.
A focused AI addition to a native app or web product, including the surrounding interface, backend route, failure handling and measurement.
First-party evidence
SiteMate is a native iOS workspace I built for sole traders and small trade businesses. Its AI-assisted day entry can take a spoken or typed account of work and prepare structured jobs, hours, expenses, materials and invoice information.
The model does not write directly into the user’s business records. It prepares a bounded draft, reports confidence, asks for clarification when a job match is unsafe and waits for the person to review and confirm the result. If the network or model is unavailable, a local parser prepares a simpler draft instead; confirmed work can also queue safely for later sync.
This is live product behaviour, not a concept page. SiteMate is published on Apple’s App Store.
Read the SiteMate build note →View the live app on Apple’s App Store →The control layer
These are implementation decisions from the shipped SiteMate workflow. They are the parts that stop a clever demo becoming a risky business process.
SiteMate does not enable its AI day-entry flow until the user has reviewed and accepted the processing step.
Spoken notes and saved context are data, not instructions. The server explicitly resists prompt injection and caps the context sent to the model.
The model must return a defined structure for jobs, hours, rates, expenses, materials, confidence and clarification—not free-form text that can wander.
Known job identifiers are checked against the user’s allowed jobs, numeric values are bounded, lists are limited and malformed responses are rejected.
Unclear work is marked for clarification instead of being silently attached to the wrong customer or job.
The result is a reviewable draft. Nothing becomes a business record until the user confirms it, and a local parser keeps the workflow useful if AI is unavailable.
When AI is the wrong tool
If a normal form, rule or database query can do the job reliably, it is usually the better choice. AI becomes useful when the input is genuinely messy—speech, documents, images or natural language—and the result can be constrained, checked and corrected.
Local context
I work directly with founders, businesses and organisations in Cornwall and remotely across the UK. The first conversation does not need a technical AI specification. Bring the repetitive, error-prone or information-heavy part of the job; I’ll help decide whether AI belongs there at all.
I do not sell prompt packs or bolt a chatbot onto every website. The outcome should be a maintainable product or workflow with a clear owner, defined data boundaries and behaviour people can inspect.
Have a messy workflow, an app idea or an existing AI feature that needs proper boundaries?