Before the code, there is a more useful question. ASSAY INTELLIGENCE LTD helps founders examine the problem, test the assumptions and give a digital idea a shape worth building.
Software can make a process better. It can also make an uncertain process more expensive. The distinction is worth investigating.
ASSAY INTELLIGENCE LTD is a software investigation studio for founders considering an app, website or bespoke digital service. The name suggests a method: examine a sample, ask what is actually present, and make the finding clear enough to inform a decision. Here, the sample is an idea in its early, imperfect state.
We begin with the work people are trying to do—not with the assumption that a particular interface or platform is already the answer. Who has the problem? How does it appear in an ordinary day? What currently happens instead? Which parts are known from observation and which are still a sensible-sounding guess? These are not hurdles to clear before you may speak to us. They are the useful material of an investigation.
That approach is especially valuable when a founder has a strong concept but has not yet worked out its first useful scope. A conversation can separate the central user need from supporting features, reveal where evidence is thin, and identify the constraint that could alter the technical route. The result might be a clearer brief, a prototype, a technical exploration, or the conclusion that the next step should happen outside software.
Our offered work spans mobile application development, app UX and UI design, website design and development, bespoke coding and integrations, app-store submission preparation, and support. These services can fit together, but they are not a compulsory sequence or a set package. A focused design question may be the right beginning; a small build may be appropriate when the problem and scope are already well understood.
Investigation does not mean endless analysis. It means identifying the decisions that matter, finding a proportionate way to examine them, and recording what the evidence does—and does not—support. A clickable prototype can help explore a journey; a technical note can clarify a dependency; a conversation with intended users can test whether a problem is recognisable. Each activity should answer a question, not merely create the appearance of progress.
When implementation is appropriate, the same habit continues. Make boundaries visible. Agree what is included and what is not. Identify who can approve access, content and decisions. Review important interface states, including loading, empty, error and recovery. A plan becomes more useful when the client and developer can both point to what is ready, what remains open, and what would change the scope.
This website describes an offered service and a proposed way of working. It does not claim a client portfolio, completed projects, historical outcomes, awards, certifications, particular performance figures or guaranteed results. Scope, cost, timing, access, external dependencies and ongoing support must be discussed for each potential engagement. No automated system on this page examines your business or provides an audit.
ASSAY INTELLIGENCE LTD is directed by Craig Geoffrey Arnott. The published contact information below is the information supplied for reaching the company. No postal address has been supplied. If you are at the first-hunch stage, you do not need to make the idea sound finished: describe the situation, what you have already noticed, and what decision is difficult to make next.
An investigation earns its place when it changes what you know or what you choose to do. These principles keep the thinking connected to a practical next step.
Before selecting a method, say what you need to decide. “Should we build this?” is broad; “which task should the first release support, and what evidence would make that choice defensible?” gives the work a boundary. A good question prevents research becoming an activity without a destination.
Founders often know a great deal about their market and still hold assumptions about user behaviour, willingness to change, data access or operational ownership. We give each statement a status: observed, supplied, inferred or untested. That small distinction helps teams avoid treating confidence as proof.
A full product is rarely the only way to learn. A screen flow, content model, integration test or narrowly scoped prototype may answer the question with less commitment. The useful artefact depends on the uncertainty; it should be chosen to investigate, not because it is fashionable.
Decisions are easier to revisit when the reason is written down. A brief record can note the evidence considered, remaining unknowns, trade-offs, exclusions and the person responsible for a next decision. It is not ceremony: it lets a team understand why a scope looks the way it does.
Services are available as individual disciplines or as connected work, depending on the question and the scope we agree together.
Develop an application around a defined task, its users and the conditions in which it will be used. Early discussion can consider platform, essential journeys, account needs, data, connectivity and what should happen when a step fails. Build scope follows the agreed requirement; an app is not presumed to be the right answer.
Explore the structure and behaviour of an app before implementation settles those choices. Work can include user journeys, navigation, screen hierarchy, content, interaction states and accessible controls. Prototypes and design artefacts are for inspection and discussion; they are not automatically a finished or tested product.
Plan and develop a responsive website around its audience, information and purpose. A useful scope considers page structure, content responsibilities, small-screen behaviour, forms and how updates will be made. The technical approach should serve the site’s actual needs rather than add complexity for its own sake.
Build a specific software function or connect existing systems where access and behaviour permit. We would want to understand what data should move, which party controls credentials, what each service allows, and how errors or retries should be handled. Third-party access, terms and capabilities remain dependencies to verify.
Prepare agreed app information, supporting assets and practical checks for a submission to an app store. The platform owner sets its own rules, review process, decisions and timing. Preparation can help organise the work; it cannot guarantee approval, acceptance or a release date.
Discuss questions after an agreed delivery, handover responsibilities and whether further work is useful. Support is not an undefined promise: scope, access, response expectations, availability and any fees need to be described and agreed separately for the particular arrangement.
Each item describes a service that may be offered, not evidence of a previous project. A proposal should set out the work, assumptions, exclusions, responsibilities, review points, dependencies and commercial terms before work begins.
Use this small planning exercise to notice which parts of an early software idea are already described and which deserve a conversation. It responds to your selections with fixed guidance. Nothing is sent, stored or analysed beyond this page.
Your current selections suggest that more than one foundational question is open. Describe the task in a real situation before choosing app, website or custom software as the answer.
This is an illustrative planning tool, not a real diagnostic, audit, assessment of a business, AI system, hosted platform, quote or genuine company project. Its deterministic advice is based only on the four selections on this page. It cannot verify evidence or recommend a technical solution. Reset returns the controls to the displayed defaults.
There is no prescribed funnel. A useful route depends on what is unknown, how consequential the decision is, and what evidence can reasonably be gathered.
These proposed milestones show how a potential engagement might be made reviewable. They are adaptable quality criteria—not a claim about past deliveries, a guaranteed timetable or a fixed package.
Describe the intended audience, the job they need to do, what happens now and the decision the work should help with. Agree the boundary: what will be examined, what will not, and who needs to contribute.
Mark statements as observed, supplied or assumed. Identify the uncertainty most likely to change the proposed route. Select a proportionate way to explore it—perhaps a journey, an interface outline, a technical spike or a review of an existing process.
Present what was learned, its limits and the trade-offs still open. If a build is appropriate, define the first scope, dependencies, decision owners and review criteria. If not, describe what further evidence or non-software action may be useful.
These notes are starting points, not universal rules. Expand the topics most relevant to your situation; use them to make a first conversation more concrete.
Start with the recurring task and the conditions around it. A mobile app may make sense when people need frequent access, device capabilities or a deliberately installed experience. A responsive website may be easier to reach and maintain for other tasks. Sometimes an existing service or a clearer process is enough. Audience, frequency, access and operational context matter more than the label “app”.
Bring one example of the situation that prompted the idea, who was involved, what happened and what you wish had happened instead. Existing sketches, process notes or examples can help, but are not prerequisites. Mention what you do not know. We can then distinguish the central question from optional features and identify which other people should be heard.
No. A prototype can help people react to an interaction, understand a proposition or compare possible journeys. What it tells you depends on who reviews it, the questions asked and the limits of the artefact. It does not automatically prove demand, technical feasibility, willingness to pay or the performance of a finished product.
Identify the smallest coherent task that can be completed and reviewed. Separate essential behaviour from convenience, identify the states that need handling, and list dependencies and exclusions. A narrow scope is not simply fewer screens; it should still represent a useful outcome. Agree how changes will be assessed before treating them as included.
Record the systems involved, who owns each account, what data needs to move, the direction and frequency of that movement, and what should happen if it fails. API availability, permissions, service terms and data protection obligations need verification with the relevant owners. Do not send passwords or live credentials in an initial enquiry.
A meaningful estimate depends on an agreed scope, decision cadence, supplied materials, access, platform requirements, external dependencies and review responsibilities. A first conversation can clarify what information is missing. Any proposal should state assumptions and exclusions; an unqualified number before those are known would create false precision.
Share the parts you can disclose and explain which decisions are already settled. The useful exercise may be to review requirements, dependencies, user journeys or implementation questions rather than revisit everything. It is still worth making open questions and approval owners explicit so that the work does not quietly inherit incompatible assumptions.
Those responsibilities should be agreed for the project. A client may need to provide product wording, legal material, account access, domain details or timely decisions; a developer may prepare agreed implementation or handover artefacts. Write down owners and timing. Access should use suitable permissions and secure channels, not be casually pasted into an email or prototype.
Potential preparation may involve organising app descriptions, supporting assets, privacy information and submission checks agreed for the work. Exact requirements can change and are controlled by each store. The account holder may have actions to complete, and the store decides whether and when to approve a submission. No preparation service can guarantee acceptance.
Record the discovery and revisit the decision it affects. Depending on the agreement, the response might be to adjust the scope, gather further evidence, choose a different route or stop the work. Treating a changed assumption as a decision point is healthier than disguising it as a small change with no effect on effort or timing.
Agree the artefacts, access, environment, operating responsibilities and open issues that need to pass to the people who will use or maintain the result. The exact handover depends on the agreed work. Any ongoing support arrangement should separately clarify scope, access, availability and response expectations.
No. The workbench is a small, deterministic reflection exercise. It uses only your four local selections to display fixed contextual prompts. It does not send or retain those choices, inspect a business, verify evidence, produce an audit, use AI or create an actual project recommendation. Use it to notice a question—not to make a consequential decision.
Purpose, deliverables, exclusions, assumptions, dependencies, decision owners and commercial terms are written down in language both parties can review.
Review artefacts and feedback points are agreed. Questions, changes and unresolved decisions are visible rather than silently folded into the scope.
Agreed materials, access and open items are identified, with a clear understanding of what further support is and is not included.
Choose email or telephone using the published details below. If you write, include the problem you are considering, who it affects and the decision you would like to make. You do not need to send confidential material or account credentials.
Office hours describe the stated contact window. They are not a promise of immediate response or a service-level commitment.
Hours are UK local time. No postal address has been supplied; no physical office location is represented on this website.
A concise description is enough to begin: the situation, the people affected and the decision in front of you. The form prepares an email draft on your device; you review and send it yourself.
ASSAY INTELLIGENCE LTD
Craig Geoffrey Arnott
Contact by email or telephone. Postal address not supplied.
Monday–Friday, 09:00–18:00 UK time. Closed weekends.
Required fields are marked by the browser. No enquiry is sent or stored by this page.