Client results
From software feature to fundable research: a client lesson
A GrantUp client result shows why interactive machine learning needed a research case, not a feature pitch. Learn how to apply that distinction to your proposal.
The distinction that mattered in the client case
An interactive machine learning project for creative workflows faced a specific application challenge: it needed to be evidenced as a research advance in human-in-the-loop training, not a user interface feature. That distinction is the central lesson from this GrantUp client result. A description of what users would see or do was not enough. The funding case needed to explain the research behind the interaction, rather than leave an assessor to infer technical substance from the proposed product experience.
The supplied result does not identify the client, award amount, experiments or assessor feedback, so those details cannot be reconstructed. What it does establish is the framing the proposal needed. For other applicants, the practical question is whether your description separates the intended user benefit from the work required to achieve it. Our guide to writing a grant application provides a starting point for organising that explanation, but the evidence must come from your own project.
Explain what must be learned, not just what will be built
A product description and a research case answer different questions. The product description explains the experience you want to offer. The research case explains what remains unresolved and what investigation is needed. In the creative workflows example, the useful distinction is between adding an interaction to a tool and advancing how a model learns through human involvement. Applicants should make that distinction explicit, without assuming that the words artificial intelligence or machine learning establish a research contribution on their own.
For a similar proposal, ask the technical team to describe the existing approach, its relevant limitation and the change they intend to investigate. Then ask what evidence would show whether that change works. Possible questions might concern how feedback affects training or whether an approach behaves consistently across different creative tasks. These are illustrative prompts, not reported details of the client project. Their purpose is to move the drafting conversation away from a feature list and towards a testable technical proposition.
Make the technology choice earn its place
Another supplied GrantUp client result makes the same lesson visible from a different angle. A blockchain proposal had to justify distributed ledger use on technical grounds rather than novelty because blockchain claims attract reviewer scepticism. The transferable point is not that a particular technology helps or harms every application. It is that naming the technology does not explain why it is needed. The proposal must connect the chosen approach to a specific problem that the project is trying to resolve.
Before drafting, challenge the team to explain why a simpler approach would not meet the same requirement. Record the answer in concrete terms, then identify which parts are established and which still need testing. For the interactive machine learning case, that means explaining why the proposed training approach matters, rather than relying on an appealing interface demonstration. If you need help testing this distinction, grant consultancy and writing support can help structure the argument, while your team supplies the technical basis.
Choose a project scope that answers the next question
A research argument also needs a bounded project. In another supplied result, a lean team needed early non-dilutive capital to prove AI-driven charging and routing optimisation before scaling. An early-stage digital therapeutic needed a smaller, faster award to prove clinical concept before pursuing larger funding. Both examples point to the value of separating the next proof point from the whole company ambition. Applicants can apply that lesson by identifying the uncertainty that needs resolving before committing to a broader programme.
For an interactive machine learning proposal, a practical scoping exercise would separate research tasks from routine product work and later expansion. Define the question each research task addresses, the evidence it should produce and the decision that evidence will inform. Do not add activities simply to make the application appear more substantial. Once that scope is clear, use the UK business grant directory to investigate live competitions, checking their actual requirements rather than assuming that a previous client's funding route remains available or suitable.
Where to go next
Start with a short evidence note before writing the full application. Describe the user problem, the current technical limitation, the proposed research advance and the evidence needed to evaluate it. Keep statements of fact separate from expectations and questions still to be tested. Then ask someone outside the development team to explain the distinction back to you. If they can describe only the intended feature, the research case probably needs further work before you expand it into a proposal.
The lesson from the creative workflows client is not to replace product language with technical jargon. It is to show why the work represents a research advance rather than only a user interface feature, then choose a scope that can produce relevant evidence. To discuss that distinction in your own project, book a 15-minute grant scope and eligibility assessment with GrantUp. Bring a description of the proposed work, the main unresolved technical questions and any evidence already available, so the discussion can focus on scope and fit.
Ready to turn this into a funded proposal?
Book a free 30-minute consultation with a senior grant consultant. We will check your eligibility, match you to the right program, and map out your submission timeline.
Learn more about our approach