Conceptual artwork representing five application areas without depicting product screens.
The Built with NEO AI page presents five application proofs of concept: FINORA, FITORA, VITORA, LINGORA and INTELORA. Each explores a different user need. The apps are in testing and are not yet available to the public; the illustrated features may change before release.
Their value for a business reader is also methodological. They offer different settings in which to ask whether an AI product understands its inputs, helps a person complete a task and preserves the limits appropriate to that task. The following review questions are practical evaluation criteria, not reported test results.
FINORA and a clearer financial view
FINORA explores bringing accounts, investments and crypto wallets into one view. A useful evaluation question is whether a user can understand what each figure represents, where it came from and how recent it is.
For a prototype review, use a controlled example with more than one account and deliberately different update times. Ask whether the interface makes those differences visible. A combined total should not hide missing inputs or uncertainty about an asset value. The test should focus on explanation and source clarity without assuming any banking or investment service is being provided by the app.
FITORA and the context of a fitness plan
FITORA explores training, nutrition and recovery. These areas make context important: a plan is useful only if it reflects the information and goals a user has supplied.
A review could examine what happens when a person changes the equipment available or corrects a recorded session. Does the product retain the correction and explain the revised plan? Test whether missing information remains visible. Demonstrating that interaction is different from establishing a health outcome or showing that a particular recommendation is suitable for every user.
Testing should establish what a prototype can demonstrate and what remains unresolved.
VITORA and health information organisation
VITORA explores organising health records and preparing information for consultations. It is described as an information tool that does not replace medical advice.
A useful prototype test might follow a document from upload to a shareable summary. Check that the date, origin and important qualifications survive the process. The user should be able to correct a transcription error and choose what is shared. Organisation and explanation can be evaluated without treating the app as a clinician or claiming diagnostic performance.
LINGORA and an interactive learning experience
LINGORA explores language learning through voice and written exchanges. The design challenge is to make feedback understandable while keeping the learner engaged in a real conversation.
A reviewer can test a short travel scenario at two levels of fluency. Look at whether the feedback identifies a specific issue, explains a correction and gives the learner a chance to try again. If audio is unclear, the product should request repetition instead of making a confident assessment of something it did not hear. Progress should reflect demonstrated work.
INTELORA and the quality of public research
INTELORA explores structured research from public sources for lawful due diligence. Its subject matter makes traceability and the handling of conflicting information central review questions.
Test it with sources that contain different dates or similarly named organisations. The report should preserve the distinction and link the reader to the underlying material. A signal requiring further investigation should remain a signal. The reviewer needs enough context to understand why a finding matters and what remains unresolved.
What testing should establish
A proof of concept should have a defined task and a documented test boundary. For each app, reviewers can ask which functions have been demonstrated, what data was used and which integrations still depend on further work. Public illustrations do not answer those questions on their own.
The applications also show why a shared platform needs different permissions and review criteria for different uses. A language exercise and a health record summary have different consequences. Product testing should reflect those differences before a release decision is made.
Visit Built with NEO AI to see the five concepts and explore NEO Labs for the engineering context behind them.
