AI software development company: private LLMs and AI inside your product

For PSONI, the Polish Association for Persons with Intellectual Disability, we are building Generator ETR (ETR is the Polish abbreviation for easy-to-read). It is a web and mobile app that turns complex text, such as an official letter, into easy-to-read language, built in a two-year programme that started in 2026. The texts people paste in can be personal, so a public AI API was ruled out. The model is self-hosted on rented GPU servers and served with vLLM, so no text goes to an AI provider's API. Stored texts are encrypted and deleted under GDPR retention rules.

Before choosing the model we tested PLLuM 12B, a Polish-language model, on the same simplification task, and went with Gemma 4 in its 26B mixture-of-experts version. Around the model the stack is ordinary software your team can maintain: Django and Celery on the backend, React and React Native for the apps. If your rules require an on-premise LLM, the same setup can run on servers you control, provided they have suitable GPUs. Our glossary explains how self-hosted LLMs differ from API models.

• Where the data goes. With a public API, every prompt and document leaves your infrastructure for the provider's servers. With a private LLM, texts stay on servers that you or your hosting provider control.
• Which model you run. With a public API you can pin a model version, but the provider retires old versions on its own schedule. A private deployment keeps the open model version you tested for as long as you need it.
• How you pay. An API is billed per token. A private model is billed for GPU time, whether it is busy or idle.
• What quality to expect. The largest API models are still stronger at general tasks, so a private model works best on a narrow task with its own evaluation, which is how we set up PSONI.
• Who keeps it running. Someone has to run the GPU servers, update the model and watch the output. We can take this on as part of support and maintenance.

On the PSONI project a script scores each simplified text with the Gunning Fog index, a readability measure, and writes a report over a set of test samples. That lets us compare one prompt or model version with the next, which is the core of LLM evaluation. A reviewer who works with the easy-to-read standard then rates real outputs against their source texts. The problem cases go into the next round of fixes to the prompt and the model, and we have been through several of those rounds.

Guardrails get the same treatment. Our QA tries to pull the model away from its job, for example by asking for an apple pie recipe instead of a simplified letter, and repeats those jailbreak tests on new iterations. When a text is legal or medical, the app shows a short notice: the simplified version is not a legal document, and a lawyer or doctor can explain the details. We are also testing a classifier that flags sensitive content such as hate speech or self-harm.

In Generator ETR the simplification model is one part of the app. Users can take a photo of a letter and the phone reads the text on the device (Google ML Kit and Apple Vision), while PDF documents go through a separate pipeline on the server. A glossary explains difficult words in context. Text-to-speech reads the result aloud and highlights the fragment being read. We are now adding a normaliser that expands abbreviations and reads numbers and dates correctly in Polish before speech synthesis. The requirement for the whole app is WCAG 2.2 at level AAA.

Centrum Komunikacji runs a Polish Sign Language (PJM) interpreting platform that we build as part of a government accessibility programme. On it we added live speech-to-text for hard-of-hearing and late-deafened users. Automatic speech recognition writes a first draft in real time, a transcription specialist corrects it, and only the corrected text reaches the user as a chat message. The feature runs in production and handles personal data under GDPR.

On the energy procurement advisory platform we built for Enerace, AI writes market news from current market data. The feature has been live since 2025.

For a product platform in the home renovation market we run an in-app AI chat and a product-search agent that works over product descriptions, metadata and prices from many suppliers. Both sit in a separate AI service that the main application calls. We usually keep that separation in AI integration services, because the AI part can then be measured, changed or switched off without touching the rest of the product.

Every project starts with a free discovery workshop. We look at your product, your data and the rules you work under, then agree what the AI should do and which test will show that it works. We have our own AI toolkit that we use in discovery. You leave with a scope and an estimate. Sometimes our advice is to skip the language model altogether.

Next comes a proof of concept on your real task, with the test samples and quality measures agreed before the first prompt. For AI MVP development we then add what real users need: the backend, accounts, the web and mobile apps. After launch we stay on for support and maintenance, because models, prompts and the data they read keep changing. Our article on AI proof of concept development covers the first stage in more detail.

On PSONI the same team writes the prompts, evaluates the output and builds the interface to WCAG 2.2 at level AAA, so there is no hand-off between an AI vendor and a separate app agency. PSONI also owns the code of Generator ETR that we write.