Customer story

Two years and two failed builds. Then production on ATAILA.

How a certification organization got a working, modern application in two months — and took it to production three months later, on 4 September 2026, with a field app on Google Play and private AI inside the workflow.

2 months
to a working, modern application — after two years of failed builds
4 Sept 2026
in production: web application, field app, private AI in the workflow
~20M HUF
written off on two earlier attempts before ATAILA (≈ €56k)
1,200+
commits in six months — every one through the same four-environment pipeline

The starting point

A certification organization needed a modern application at the core of its business. The owner did the diligence most teams skip — researching the right runtime, starting on colocation virtual servers and, later, public cloud. The hosting decisions were sound. The application built on top was the problem.

Attempt one — a traditional integrator

Two years and roughly 20 million HUF with a traditional system integrator produced a monolithic PHP application on an architecture that was already end-of-life: no separation of front-end and back-end, slow under real load, and a database that was never fully normalized. Every further improvement was slow and expensive. The whole thing was maintained by a single external developer: a bus factor of one.

Attempt two — the low-code promise

Next came a well-known low-code platform, another vendor, and the pitch that the organisation could simply build it itself. When the app slowed to a crawl, the vendor's answer was that the platform was the limit. It was not — the code was the limit. The project drifted: buggy, with a misaligned data model, two apps stitched together over an unnecessary API, a mobile app that was never finished, and no AI anywhere in it.

The move to ATAILA — two months to a working application

After two years of fighting, the team moved to ATAILA: the provisioning engine to stand up the landing zone, the AI sandbox to build in, and the Release Manager to promote safely to production — across four real environments (sandbox · dev · uat · prod) instead of a single fragile box. In about two months the team had built more than the previous two years delivered.

From working to live — three months

The legacy register was analysed and is being brought over in waves: more than 300 client organisations, over 20,000 pieces of equipment and more than 150,000 inspection records. The office workflow was cut back to what the operation actually needs — the menu went from around 36 items to 11 for launch, and every role was reviewed before go-live. The field app is rolled out to the inspectors through Google Play, built and published from the customer's own pipeline on ATAILA, with the app-store account and the signing key belonging to the customer. Cutover was on 4 September 2026: the dataset restored and every credential rotated the same evening. The first real inspection and its report went through the production system the next day.

Fast, because the platform is

The production database runs on enterprise NVMe with a hot standby on a second node and a disaster-recovery replica on a second site, alongside a four-node distributed object store and off-site backups at the organisation's own office. The platform sits in BIX-direct colocation in Budapest with dual 10 GbE uplinks. The previous application slowed under real load; this one does not make anyone wait — not on the phone, not in the office.

Private AI inside the workflow

AI has been part of the build from the first day: the team worked with it in dev and UAT throughout, and since go-live it runs in production too, with four capabilities: equipment identification from a photo of the nameplate, knowledge chat over the organisation's own documents, visual similarity search across equipment photos, and image generation for the app's category icons. All of it runs through ATAILA's AI gateway on ATAILA's own GPUs in Hungary — no external AI API, and no data leaves the platform. Every call is metered per feature and per environment, and the organisation can see it. The rule is fixed: AI proposes, the portal decides, a human confirms — never auto-confirm.

The public face, rebuilt

The organisation's main website was rebuilt on the platform in June 2026: bilingual HU/EN, 61 pages, seven service pages, three audience landing pages, a knowledge centre, a certificate-check page, structured data for search and AI answer engines, first-party cookieless analytics, and security headers hardened on the back of a pen-test. Its certification-laboratory brand came off a hosted website builder onto the same platform in days and went public on 1 August 2026 — around eighty pages, bilingual, with an llms.txt layer for AI answer engines. Three enquiry paths — a contact form, a quote request and a guided quote wizard — post to a same-origin, anti-bot-protected API and land in an admin inbox inside the organisation's own customer portal, published on 5 September 2026. The previous site had left several real manufacturer enquiries sitting unseen for months; that hole is closed.

The organisation now owns its core system — code, data, environments and AI — instead of renting a black box from one vendor. That is an asset on the balance sheet, not an IT line item.

Three promises, kept

Not a penny wasted.

We only start a trial we can take to production — and the fee counts 100% toward what follows.

The working application of June is the production application of September. Nothing was rebuilt: all 1,200+ commits rode the same pipeline to production.

In production from day one.

The trial is built on the production platform, on your process, integrated with your systems — what works stays, nothing is rebuilt.

Built on the production platform from the first day, in the organisation's own environments, with its own invoice history and equipment register loaded. What worked, stayed.

Transparent, and yours.

A fixed, published price; you see what runs where and what it costs — with named ownership and exit rights, in writing.

The code sits in the organisation's own GitLab group, the data in its own database, the app-store account and signing keys are its own, the backups are at its own office.

The owner's verdict after the first production week: it does what the previous two never did, and it is fast.

Skip the two years. We only start a trial we can take to production — and the fee counts fully toward what follows. Bring your workflow.

This reference is published anonymously at the customer's request; a named version will follow once their migration is complete. For a new project start, the customer has agreed to act as a reference for prospective customers — ask us for a reference call.