CASE STUDIES · ANONYMIZED PROOF

Proof without revealing clients.

Most of our work happens under confidentiality — under NDA, in regulated industries or in investment contexts. So we show the problem, the approach and the effect, and leave names and metrics for the conversation.

Describe your caseSee services

ANONYMIZED EXAMPLES

Problem, approach, outcome — without the client's name.

  • Digital regulator · Gulf region
  • Enterprise
  • Scoped

A compliance-assessment workbench for a digital regulator

Problem
A weeks-long, manual review of large regulatory evidence bundles — classification, detection of gaps and contradictions, an assessor’s decision. AI recommendations must stay explainable, and every suggestion reproducible in the audit trail.
Approach
We designed an end-to-end evidence-assessment workbench: ingest and parsing, classification against regulatory frameworks, detection of gaps and contradictions, a document view with AI highlights, explanatory summaries and one-click override — all in a single auditable workspace.
Outcome
A complete design and implementation proposal: a weeks-long manual evidence review pulled down to a single auditable workspace, with AI in an accelerating role and the human at the center of the decision.
  • PE / Enterprise · insurance
  • PE
  • Thesis / research

A sovereign AI architecture for an insurer

Problem
The investor and the board need a clear answer on whether AI is a real lever in an insurance portfolio where the data forces on-prem deployment and regulator-audit-ready evaluation.
Approach
We designed a sovereign AI architecture for on-prem deployment — with a regulatory-corpus ingest pipeline, audit-ready evaluation mechanisms and a value-creation map for underwriting and claims handling.
Outcome
A shaped investment thesis for the executive sponsor and the portfolio board — where AI creates value, where it introduces risk and which architecture makes sense in a sovereign environment.
  • European operator · IT operations
  • Enterprise
  • Scope defined

An agent operating-model blueprint for a European operator

Problem
Demand for a first agentic pilot with no operating model: no permission boundaries, no audit trail, no scheme for carrying the solution over to other domains.
Approach
We designed an agent operating-model blueprint for a European operating company — a first helpdesk pilot with a human in the loop, permission boundaries and an audit trail, in a pattern reusable across IT, HR and operations.
Outcome
The CIO gets a narrowly scoped first pilot and, at the same time, a pattern to scale to further processes — without building a transformation program from scratch.
  • Mid-sized manufacturer · extensive catalog
  • SMB
  • Built

A tender-analysis workflow for a manufacturer with a large catalog

Problem
The sales team is drowning in tender specifications — manual reading, manual matching to products, no repeatable rhythm between a tender and lead generation.
Approach
We built an end-to-end tender-analysis workflow that the team uses today on real tenders — specification analysis from pasted text, uploaded files or a project folder, a reusable RAG index of product cards, a match ranking with manual correction, and an export of the report and a draft proposal. We are now deepening the product-data layer: a model card standard, a card generator for the sales department and expert rules — so the matching is even more accurate.
Outcome
Product cards and the knowledge base become a reusable asset instead of a one-off cost — the same team handles more tenders and shapes inquiries earlier instead of only reacting to them. The deeper the card and data layer, the more accurately the system matches products to specifications.
  • Manufacturer · B2B configurator
  • SMB
  • Built

A CRM pipeline in ERPNext for a manufacturer with a configurator

Problem
Every submission from the configurator should land in the CRM as a countable opportunity — with no manual re-keying, with an unambiguous owner and the right stage.
Approach
We built an end-to-end CRM pipeline in ERPNext for a manufacturer with a configurator — every submission lands in the CRM as a deduplicated lead, routed by role; Kanban, stage gates and the permission model are documented for handover to the client’s team.
Outcome
Sales sees the pipeline in real time, management gets predictability where there was previously administrative work and intuition — without raising headcount.
  • Furniture manufacturer · mid-sized
  • SMB
  • Scope defined

An operational workflow in ERPNext for a furniture manufacturer

Problem
The order lifecycle stretches across quote, design, production, installation and service — but the statuses and acceptance criteria live in people’s heads and in email, not in the system.
Approach
We designed an end-to-end operational workflow in ERPNext for a mid-market furniture manufacturer — ten lifecycle stages from lead to close, each with described acceptance criteria.
Outcome
The COO gets an implementation-ready process design — acceptance criteria are explicit, stages are countable, and administrative work stops being a bottleneck on growth.
  • Local service · appointment booking
  • SMB
  • Discovery

A voice agent for taking bookings and call-backs for a local service

Problem
Customers call around the clock, while the front desk answers only during working hours. The morning starts with calling back missed calls just to find out what someone was even calling about — with no knowledge of who was urgent and who can wait.
Approach
We ran a discovery and scoped the core: a voice agent answers calls after hours, introduces itself as AI, classifies the matter, flags urgent cases per a client-approved script, and records structured data for the call-back. We leave the contact decision and the conversation itself to a human — the agent prepares the list, the front desk calls back.
Outcome
A discovery summary ready for confirmation, with the core scope described and the agent’s boundary of action — what it does after hours and what stays with the team. Full implementation and pricing await the client’s acceptance of the scope.
  • MŚP · inventory management of goods with an expiry date
  • SMB
  • Scoped

A warehouse app with batch and expiry-date control for a small operation

Problem
Stock is kept manually in a spreadsheet, and the goods have batch numbers and expiry dates. No one sees the full path of an item from delivery receipt, through internal use, to over-the-counter sale. Hence the risk of shortages, of dispensing expired items, and the inability to indicate which batches to reach when withdrawing goods from sale.
Approach
After an on-site discovery we designed a v1.0 requirements specification and handed it to the development team for estimation. The described scope: delivery receipt with GS1 DataMatrix code scanning, batch-level stock records with FIFO dispatch by expiry date, internal use and over-the-counter sale, batch tracking for withdrawal from sale, PIN access with operator and manager roles, and reports with export to CSV, XLSX and PDF. The app was designed to be portable, running locally on Windows. We leave the build to the development team — we deliver the design and the scope boundary.
Outcome
The client has a requirements specification ready for confirmation, with the first phase’s scope described and a clear boundary of what belongs to it and what was deliberately deferred. This is a scoped stage, not a deployed one: the app is not built yet, and pricing and the build await the client’s acceptance of the scope.
  • Enterprise consulting · marketing AI
  • Enterprise
  • Delivered

An AI enablement strategy for an advisory partner

Problem
An advisory partner needs a package of AI workflows for marketing that can be replicated across many clients — without the risk that every deployment starts from a blank page.
Approach
We delivered an AI enablement strategy for an advisory partner: an executive deck, a workflow assessment, a KPI structure and a set of pilotable workflows packaged for reuse across many client engagements.
Outcome
The CMO and the advisory partner have a replication-ready framework — a pilot at the next client starts from approved material, not a blank page.
  • Enterprise · programme management
  • Enterprise
  • Proposal prepared

A data-architecture bid for a mega-project

Problem
A multi-stakeholder, multi-year mega-project needs an answer: architecture, data governance, risk discipline, scope control — in one clear bid document.
Approach
We prepared a data-architecture bid for the realities of a multi-stakeholder, multi-year mega-project — architecture, data governance, risk discipline and scope control in one coherent response.
Outcome
The programme director gets a bid that can be defended before the risk committee and the programme board — without hype and without promises that fall apart under the other side’s due diligence.
  • Global advisory firm · operational resilience
  • Enterprise
  • Delivered

An operational-resilience playbook for a global advisory firm

Problem
An advisory partner needed a board-level narrative on operational resilience — not disaster recovery and not business continuity in the classic sense, but the question: does the company keep running when the internet goes down, when the data center goes down or when there is a breach. They lacked material that ties these scenarios to today’s threat profile, including AI-assisted offense.
Approach
We delivered an executive deck on operational resilience and bound it to a methodology playbook: three failure modes as the narrative axis, a layered resilience ladder, a deep dive into the deepest layer, and lessons from real incidents. Plus an outline of three services — a resilience audit, threat modeling that accounts for AI-assisted offense, and a backup-connectivity design — with a boundary: this is decision material for the board, not a deployed architecture.
Outcome
The advisory partner got ready material for the conversation with boards and a repeatable methodology for further engagements — resilience told through failure scenarios, not a service catalog, with room for AI-assisted offense in the threat model.
  • B2B distribution · extensive supply chain
  • Enterprise
  • In progress

ERP and a meeting agent as a single source of truth for a B2B distributor

Problem
Decisions and agreements from meetings get lost in emails and files, while operational data lives separately across several systems — with no single place where the supply-chain director sees a coherent state of orders, logistics, product data and invoice flow. Each process has its own rhythm and its own truth, so reconciling anything across departments takes days.
Approach
We are running an ERP deployment across several key operational processes in parallel with a meeting agent that has a dual write: recordings, decisions and tasks go simultaneously to the team’s company workspace and to the ERP as the system of record. This makes the ERP a single source of truth rather than another silo. We work in stages and milestones — with a pilot before the full roll-out; the human stays at the decision, the agent prepares and tidies the record.
Outcome
The meeting agent is already delivered and works in production mode — it closes the meeting record both on the team side and on the ERP side. The full ERP deployment is in progress: configuration and process mapping run on parallel tracks to the roll-out, so further operational processes enter one system in stages rather than all at once.
  • Company with an extensive product catalog
  • SMB
  • Scoped

An OCR/AI endpoint for auto-filling product cards

Problem
The team manually fills in product cards and forms in a catalog-management app — re-keying data from images and documents field by field. With a large catalog this work grows linearly with every new item, is error-prone and eats time that could go into sales and service.
Approach
We developed a technical specification for an OCR/AI endpoint that reads product data from images and documents and automatically fills the app’s forms with it. We also have a working prototype of the extraction engine, which we are developing in parallel for the schemas of different product types. The surrounding API is being built by the client’s external technical partner; we integrate our endpoint with that API once it exists.
Outcome
The client has a ready solution design — the endpoint specification and the extraction prototype — that turns manual card re-keying into reading and automatic filling with human verification. This is a scoped stage, not a deployed one: the integration awaits the API being built by the client’s partner, and we close the commercial scope before implementation starts.
  • Field service · low-voltage systems
  • SMB
  • Scope defined

A field-service dispatcher for a low-voltage systems company

Problem
The company sends small teams on the road — installation, maintenance and repair of low-voltage systems — and keeps all job planning on a Kanban board and in email. With rotating crews and a mix of short service calls and multi-day projects, this setup falls apart with every change: there is no view of team workload a week ahead, and old jobs are hard to find by site.
Approach
We ran a discovery with a tool demo and mapped the service process from request to settlement. On that basis we defined the architecture and the MVP scope: in the first phase, a dispatcher in a week view — rows are teams, an hourly split, drag-and-drop, savable filters and job-type colors. We described the client’s target vision — a quoting module, a plan-vs-actual profitability report, billing integration and inventory — as later phases, deliberately outside the first phase.
Outcome
The client has a mapped process, an approved direction toward a dedicated service system as the source of truth on jobs and materials, and a defined MVP scope with a clear boundary: the dispatcher first, the quoting-and-settlement integrations later. Nothing is built yet — the next step is range-based pricing that separates the first phase from the further vision.
  • E-commerce / online retail
  • SMB
  • In progress

An online store with a content layer ready for Google and AI answer engines

Problem
The client wanted a separate store for a new brand — built from scratch, not a copy or a migration of the existing site, which still runs in parallel. The catalog is large, and the content describing the products has to build trust, because it concerns a sensitive area (E-E-A-T/YMYL). On top of that comes a question most stores do not yet have an answer to: how to write this content so that it is read and correctly cited not only by Google but also by AI answer engines — AI Overviews, ChatGPT, Gemini, Claude, Perplexity.
Approach
We are building the storefront together with a content layer prepared for the search engine and for AI answer engines: automatically generated headings, meta, FAQ sections, Schema.org structured data and an llms.txt file, with care for content credibility in the YMYL area. Plus an admin panel for managing the catalog and orders, and a full analytics stack. The work is in progress — the first live build is already on the server, and in parallel a brand-book and a clickable store prototype are being created. We work iteratively, in milestones; we confirm the content scope and its credibility with the client in stages, and the human stays at the final acceptance.
Outcome
At this stage the client has a working prototype on the server, a brand-book and a clickable store skeleton — with a content layer designed to be understandable to both Google and AI answer engines. This is still a prototype, not a launched production store: the build continues, and further subpages and modules enter in stages. The move to a full MVP awaits the client’s acceptance of the prototype.
  • E-commerce · large-format printing
  • SMB
  • Proposal prepared

Preflight of large-format print files with corrections in Polish

Problem
The store accepts files that customers upload to large-format ad orders, and only then does the DTP department check them manually for print errors — overprint, unoutlined fonts, color space, registration marks, mismatched dimensions. Every week is a steady stream of files for manual correction, and the off-the-shelf preflight engines on the market speak English, Spanish and French, so they do not explain to a Polish customer what is wrong with their file and why.
Approach
We designed and approved with the client a "black box" architecture: a faulty file comes in through the API, a print-ready one comes out, and the existing e-commerce frontend keeps all the user handling. On this the architecture rests two layers that are the value added here. The first is corrections and explanations in Polish — a description of the error and the fixes in the customer’s language, which off-the-shelf engines do not support. The second is triage in three thresholds: green is errors fixed automatically with a change log (overprint, font outlining, safe color conversion, removal of registration marks); yellow requires a quick confirmation from the user; red, too complex, routes the file to a designer or to human verification. The original file is always kept for an XY comparison, so that beyond the detected error nothing in it changes, and the print guidelines assigned to each product serve as the rule set.
Outcome
The client has an approved solution architecture and a prepared final offer: from a file with an error, through automatic repair with a change log and thresholds with human involvement, to Polish explanations and safe preservation of the original. This is a stage with a ready offer, not a deployment — the build has not started yet, and the start of implementation awaits the client’s decision on the scope.
  • Educational institution · information portal
  • SMB
  • Built

Editable portal clone with a visual content-management layer for an educational institution

Problem
The institution had a working portal, but every content change required a developer’s intervention. Section layout, copy and block visibility were hard-coded — with no layer through which an editor could make a correction on their own.
Approach
We built a faithful copy of the portal as a React application and then added a visual editor launched directly in the browser: clicking on text opens an edit field, drag handles let you reorder sections, and any section can be hidden or moved without touching the code. The changes are saved to an overrides file and take effect immediately after a refresh. We verified the entire editing flow with end-to-end tests before handover.
Outcome
The client has a fully editable copy of the portal: an editor can rewrite any text, reorder sections and hide blocks directly in the browser — without involving a developer for every correction.
  • Aurora internal · professional services
  • Enterprise
  • Deployed (internal system)

A knowledge-capture system and RAG assistant (internal IP)

Problem
The company’s knowledge lives in people’s heads, emails and old files. Classic RAG without metadata and confidence gives inconsistent results, and the model hallucinates the organization’s history.
Approach
We built an internal knowledge-capture system and RAG assistant — an interviewing agent → chunks with structured YAML metadata and a confidence score → multi-dimensional search feeding RFPs, internal assistants and a reusable sales knowledge base.
Outcome
Institutional memory becomes usable in RFPs, onboarding and client work — every AI answer has a trail to the original chunk and a confidence label.
  • SMB / Enterprise · Microsoft 365
  • Enterprise
  • Deployed (internal system)

A project email-intelligence agent in M365 (internal IP)

Problem
The project inbox is the company’s actual operating system — triage, classification by project and daily summaries consume hours that must not be handed to an autonomous agent without control.
Approach
We built a project email-intelligence agent in M365 — triage, project classification, a daily digest. Every outgoing action passes through a human approval gate; the agent is an observer and an assistant, not a decision-making actor.
Outcome
Email stops being a project-management bottleneck — without handing control over communication to an autonomous agent.
  • MŚP · e-commerce
  • SMB
  • Deployed (internal system)

A product-image metadata enrichment tool (internal IP)

Problem
Raw product images land in the catalog with unreadable names and no alt text — listings are unsearchable from day one, and manual work on metadata does not scale.
Approach
We built a product-image metadata enrichment tool — from raw photos it generates SEO-grade file names and alt texts so that e-commerce listings are searchable from day one.
Outcome
The product card goes to the catalog with metadata the search engine can handle, not with a placeholder — without manual work on each image separately.

A NOTE ON ANONYMIZATION

Most examples are anonymized for client confidentiality — we work in regulated industries, investment contexts and under NDA. We share details, metrics and names in a reference conversation, once the client consents.

LET'S START

Tell us which process you want to improve.

Bring us a workflow, an investment decision or a bottleneck — we start the conversation from something concrete, not from slides.

Describe your case