What we delivered
We delivered an end-to-end MVP for a US company operating in heavy construction and mining equipment. The product supported the early stages of preparing grant applications and was built against requirements defined with the company. Its internal grant writers began using the MVP for initial grant work.
The engagement covered more than implementation. We researched how relevant grant programmes and application forms were structured, worked with the client’s grant-writing team to understand their review process, and translated those findings into the product workflow.
The application problem
Green-tech funding applications require teams to interpret programme documents, assemble company and project evidence, and place that information into different form structures. Requirements differ between programmes and application rounds, so the MVP used programme-specific structures rather than assuming that one generic prompt could reflect every funding call.
The task is broader than generating prose. It involves identifying requirements in grant documents, tracing supporting information back to company materials, organizing concepts consistently, and keeping a person responsible for the final application decision.
Programme rules, evidence requests, and form fields do not always use the same vocabulary. A useful workflow would therefore need to keep each extracted requirement connected to its source passage. It would also need to distinguish an eligibility rule from a scoring criterion, a required attachment, and a question that asks for narrative justification. Treating all four as generic text would make review harder rather than easier.
Structured information came before drafting. We modelled programmes, calls, requirements, company evidence, and application sections so generated text could use approved material. The workflow was designed to expose missing evidence instead of filling gaps with plausible but unsupported statements.
The MVP workflow
The MVP connected three kinds of information: programme documentation, company evidence, and application fields. Document processing identified relevant passages in grant documents and forms. A structured knowledge model then organised requirements and related them to information needed from the applicant.
The workflow supported interpretation of eligibility criteria, matching available evidence to form requirements, and preparing responses for review by the client’s grant writers. It was built as an agent workflow because different stages required different context, instructions, and checks.
The most difficult input was the company’s proprietary knowledge about advanced equipment technologies. General-purpose language models did not understand that material reliably. Without stronger grounding and workflow boundaries, they produced vague text and substantial hallucinations. We therefore organised the company knowledge for retrieval and constrained how agents used it while preparing application content.
Each proposed answer needed a traceable relationship to the programme requirement and the company material used to prepare it. Missing information remained a review task rather than being hidden behind completed-looking prose. Programme configuration also had to account for changes between calls, including eligibility rules, deadlines, attachments, and scoring criteria.
Domain input and evaluation
We worked with the client’s internal grant writers to define how programme requirements, company evidence, application fields, and review decisions should be represented. Their input shaped the workflow and the experience used to inspect and refine generated material.
The MVP then moved into the client’s initial grant work. This establishes operational use by the intended internal users, but it does not establish a grant-success rate, time saving, or quantitative improvement in application quality.
A credible evaluation would separate document extraction from application support. Extraction could be checked against a reviewed set of programme passages and fields. Draft responses would need expert review for factual grounding, completeness, and correct use of company evidence. Eligibility guidance would require a stricter boundary because an incorrect interpretation could cause a team to invest in an unsuitable call.
Human approval remained necessary where the workflow interpreted programme rules, selected evidence, or committed the applicant to a statement. The client’s grant writers retained responsibility for those decisions.
Supported outcome
The company received an MVP built around its grant-writing requirements and proprietary technical knowledge. The engagement moved from grant-structure research and internal-team discovery to an implemented workflow used for the client’s initial grant applications.
The supported outcome is the delivered and initially used MVP. This case study does not claim that the software improved grant acceptance rates, reduced preparation time, or produced successful funding decisions because those results were not provided.
For a similar product, the practical first step is to choose one programme and map its requirements, evidence sources, owners, and review decisions. That reveals whether the main constraint is document structure, missing company data, workflow ownership, or drafting. It also defines a test set before a larger implementation begins.
Explore the grant-technology context or the document-intelligence approach.