Where we try things first.
The research arm of AppX. We test emerging technology on our own time, publish what we find, and take into client work only what has earned its place.
Research that reaches the product.
AppX Labs is the applied research unit of AppX, and the method is constant: define a representative problem, build a proof of concept, measure the results under reproducible conditions, and publish the report with the data that supports it, including the cases where the conclusion is unfavourable.
The practice is long-standing here. The team includes researchers, and part of AppX's work has been recognised as research and development under the Portuguese SIFIDE scheme. That is the basis for the recommendations we make to clients: when we assess a technology, we assess it on evidence of our own.
Every write-up is presented to the whole team.
A Labs write-up does not end when it is written. It is presented to the whole team, with the problem, what was tried and the numbers, so that what one person learned ends up in everyone's hands.
Our articles.
We put vibecoding to the test on a real client project at AppX.
Tiago Pinto, Manuel OliveiraAI-assisted code editors promise to turn natural-language instructions into working software, yet how far they can carry a complete product under real conditions, and where they stop being useful, is rarely measured. This article reports a hands-on evaluation of vibe coding, the prompt-driven method popularised by Cursor, applied to the reconstruction of an existing mobile application at AppX. The exercise was deliberately visual and iterative: screenshots of the reference application were used as prompt material, the generated components were executed and observed, and the prompts were refined until interface and behaviour matched the intent. Development proceeded in phases, from a mock-data dashboard to authentication, secondary screens, backend integration and, finally, packaging with CapacitorJS for on-device testing. The results show genuine acceleration in prototyping, navigation, user-interface construction and basic API integration, provided the prompts are precise: vague instructions cost several iterations, layout consistency and code organisation degrade without supervision, and an experienced developer will find tasks that would be faster written by hand. The article closes with the conditions under which a software house can adopt the method without loss of quality: architectural decisions, security and compliance, code review, performance and production readiness remain human responsibilities, generated code is treated as the work of a junior pair, and prompts are versioned as first-class artefacts.
Read article →Building a generic knowledge base chatbot with open-source LLMs and Node.js.
João Lopes, Manuel OliveiraLarge language models can answer questions about material they were never trained on when combined with retrieval augmented generation, but building such a system entirely from open-source components, and knowing what it costs in latency and accuracy, calls for measurement rather than assumption. This article documents the design and evaluation of a server-side knowledge base chatbot built at AppX on Node.js, using Ollama to run the models locally, LangChain to orchestrate retrieval and prompting, and a MySQL message store that gives each user a persistent conversation. Text and PDF files are split, embedded and retrieved as the context for each answer; generating the embeddings once at server startup and caching them to a file reduced the answer time from 32.41 s to 4.92 s with Llama 3.1 and from 37.54 s to 5.99 s with Gemma 2, roughly a sixfold gain. The two models were then compared against three embedding models, mxbai-embed-large, snowflake-arctic-embed and nomic-embed-text, over a fixed set of seventeen questions with the retrieved context held constant. Gemma 2 reached the highest success rate, 91.18 % with both mxbai-embed-large and snowflake-arctic-embed, while Llama 3.1 answered consistently faster, and streaming was introduced to mask the remaining latency. The article closes with the trade-off this configuration imposes between answer quality and response time, and with the lines of work it leaves open.
Read article →Let's build something amazing together.
Have a project in mind? Tell us about it. We look forward to hearing from you.
Let's talk 👋