Skip to content
Exana DigitalStart your project

Case studies

Case studies

What we have built, in one place: the systems we engineered, the brand and content we produced, and the growth and automation we ran. Each one says who came to us, what we built for them, and the decisions behind it. Client names and identifying details are left out; the work is not.

What we engineered, produced, and ran

Three kinds of work, written the same way each time: the systems we engineered, the brand and content we produced, and the growth and automation we ran. Each one says who came to us, what we built for them, and the decisions behind it. Client names and identifying details are left out; the work is not.

Systems we engineered

Unified Business Platform (ERP · CRM · HRM · SCM in one system)

The client: a company running its sales, stock, purchasing, and staff records across Excel sheets, WhatsApp threads, and a set of tools that did not talk to each other. It wanted one place for all of it, brought in module by module, without stopping the business to migrate.

Details

What we built: one platform the company actually lives in. The sales pipeline and customer records (CRM) feed orders and invoicing (ERP); inventory, purchasing, and supplier flows (SCM) update in real time; staff records, leave, and payroll inputs (HRM) sit in the same system with role-based access. One login, one database, one version of the truth — built so each module could go live on its own and the rest join later without migration pain.

The decisions we made: one system assembled from separable parts, so it stays cheap to run and can be split apart later if volumes demand it; an event log behind every business action, so audits and disputes end with a record instead of an argument; approval chains the client configures without coming back to us; full multi-language support; and dashboards management actually opens — numbers with drill-down, not charts for decoration.

What it included: custom admin panel · granular permissions · document generation (quotes, POs, payslips) · notification center (email/WhatsApp) · an API for whatever came next.

Multi-Vendor Marketplace with Logistics & Split Payments

The client: a business that needed to put many sellers in front of many buyers and take a commission on every order — with onboarding, payouts, and delivery tracking that did not depend on someone reconciling them by hand.

Details

What we built: the full three-sided machine. A buying experience built for conversion — web, phone, and the other channels that had to sell the same catalog. Vendor portals where sellers manage catalog, stock, pricing, and orders without calling anyone. And an operations dashboard with total command of listings, commissions, payouts, and disputes. Payments split at the source: the platform's commission and the vendor's share separate automatically, with settlement reports both sides can check. Logistics went in with the first release — shipping providers, delivery tracking, and cash-on-delivery reconciliation for the markets that live on it.

The decisions we made: vendor onboarding was treated as a product of its own, with approval flows and document checks, because that is where a marketplace stalls; search was built to stay fast as the catalog grew rather than tuned once against a small one; fraud and review controls went in before they were needed; and the architecture was designed to carry far more load than it opened with, so growth would not mean a rebuild.

Clinic & Healthcare Operations System

The client: a healthcare group running on paper files and phone-call scheduling, where a patient's record stopped at the branch that created it.

Details

What we built: appointment scheduling patients actually use — web booking with WhatsApp reminders before every appointment — plus electronic medical records under strict role-based access, e-prescriptions, lab-result delivery, insurance claim tracking, and billing, wrapped in an admin view showing utilization per doctor, per room, per hour. Confidentiality was a design constraint from the first line rather than a later pass: encryption at rest and in transit, a full audit trail on every record access, and compliance-grade data handling against the requirements of GDPR, KVKK, and PDPL. HIPAA-grade patterns were applied where the work called for them.

The decisions we made: the doctor's screen was designed around the few minutes a consultation actually lasts, not around a database form; patient identity was unified across branches, so the record follows the patient rather than the building; and nothing about a patient leaves the system without a logged reason.

Booking & Hospitality Platform with CMS

The client: a hospitality operator selling time and capacity — slots that are either sold or lost — taking bookings across several channels, with a marketing team that could not change a page without a developer.

Details

What we built: real-time availability and booking — on the web, on phones, and on the other channels the business sells through — with deposits and cancellation policies enforced automatically, channel-safe rate management, a CMS the marketing team runs without a developer (pages, offers, seasonal campaigns in every language it publishes in), and a back office covering capacity, pricing calendars, staff schedules, and daily revenue. The integrations went in with it: payment gateways, WhatsApp confirmations, accounting export, and review-platform monitoring.

The decisions we made: overbooking was made structurally impossible rather than procedurally discouraged — the rule lives in the data model, not in a staff instruction; every price change is logged; and the content side and the booking side were put on one design system, so the brand never breaks between "reading" and "buying".

Field Operations & Workforce Platform

The client: a company whose work happens at customer sites rather than at a desk — jobs dispatched in the morning, and the only record of what happened arriving in reports typed at month-end.

Details

What we built: a dispatcher's control room — live map, job assignment, SLA timers — paired with a field app that works offline and syncs when coverage returns: job details, checklists, photo proof, customer signatures, parts used. Customers get their own tracking link and rating prompt. Management gets the truth: first-time-fix rates, technician utilization, response-time distributions — computed from the jobs themselves, not from what someone types at month-end.

The decisions we made: offline-first architecture, because the field is not a place with reliable internet and an app that stops at the edge of coverage is an app nobody opens twice; photos and signatures treated as evidence, with timestamps and geotags attached; and time tracking built to payroll grade, because that is the number people argue about.

Content & Commerce Engine (Headless CMS + Storefront)

The client: a brand whose site had to be a publication and a store at once — media that earns the visit, and a checkout that does not feel like a different company.

Details

What we built: a headless CMS feeding a fast storefront in both languages: articles, videos, and product pages sharing one design system; carts, subscriptions, and digital delivery; SEO built into the skeleton (structured data, hreflang, performance budgets); and an editorial workflow with drafts, approvals, and scheduling. The marketing team publishes daily without touching code, and the store sells without pulling the visitor out of the content.

The decisions we made: performance was treated as a feature rather than a finishing task, because a slow page is a lost sale; typography was held as a first-class design constraint, since the product here is reading; and analytics were wired to answer "what content sells" — not just "what got clicks".

Real-Time & Always-On Platform (shared live state · traffic spikes · observability)

The client: a business running a product where many people act on the same live data at the same moment — where a one-second-old answer is a wrong answer, and the load arrives in waves rather than in a straight line.

Details

What we built: a distributed system designed around one shared state that stays the same on every device, and around the fact that its traffic arrives in waves. Capacity grows and shrinks with load instead of being sized for a launch day that may never repeat. Delivery is automated end to end, so what is in the repository is what is in production and a rollback is one command rather than a whole evening. Observability shipped with the first release, not after the first outage: traces that follow a single user's action through every service, metrics on the numbers that actually predict trouble, and dashboards someone on call can read at three in the morning. The client side was treated as part of the system rather than an attachment to it — reconnection, late messages, and a phone that went into a tunnel were designed for, because that is where a live product looks broken first.

The decisions we made: the system was designed for how it would be operated, not only for how it would be written — the hard part of a live product starts the day real users arrive; state was partitioned so one stuck node degrades one room rather than the whole product; and alerting was wired before launch, so a problem reaches an engineer before it reaches a customer.

Data & Integration Engine (collection · normalization · monitored feeds)

The client: a business whose decisions depended on data living outside its own systems — supplier and competitor prices, catalogs and listings, public registers, and a partner whose system was never meant to be integrated with.

Details

What we built: a pipeline that turns scattered sources into one dataset the client's people and other systems can query. Collection, cleaning, and storage were kept as separate stages, so a source that changes its structure breaks one collector instead of the whole pipeline. Records arriving in different shapes are normalized onto one schema, so the same item is comparable wherever it came from, and history is kept rather than overwritten — how a number moved is visible, not only what it is now. Collection runs on a schedule the client sets, and the output goes where the decision is made: a dashboard, an export, an API, or straight into the system already running the business. Adding a source afterwards became a configuration job rather than an architectural one.

The decisions we made: the schema was built to tolerate messy sources, because a pipeline that only accepts clean data stops on its first bad day; monitoring reports a stale or broken feed loudly, since the expensive failure is not a pipeline that stops but one that quietly keeps serving yesterday's numbers; and only publicly available data was collected, within each source's terms — checked while the pipeline was being scoped, not after it ran.

Custom AI Agents (orchestration · unattended execution · human checkpoints)

The client: a business whose work was too varied for a fixed rule and too repetitive to keep a person on — in one case a long process that moved through stages, in another a live stream of events that had to be acted on the moment it arrived.

Details

What we built: an agent system that does the work rather than talks about it. Where the work was a staged process, each stage got an agent with a defined job, a defined input, and a defined output, and the handoffs between them were orchestrated rather than hoped for — with a human checkpoint at the stages where a wrong answer is expensive. Where the work was a live stream, the agent runs unattended, and its rules and thresholds live in configuration rather than in the code, so what it does can change without a rebuild. Both shapes shipped with the same three parts: a view that shows what the agent is doing and why, an audit trail of every action it took, and alerting that puts a person back in the loop the moment one is needed. It runs in containers, on the client's keys, in the client's accounts, so it behaves the same in testing as it does in production and it stays theirs.

The decisions we made: the agent's authority was written down before it was built — where it acts alone, where it proposes and waits, and what it may never do unsupervised; behaviour lives in configuration, so changing a rule is an edit rather than a release; and the dashboard was part of the first version, because an agent nobody can watch is an agent nobody will trust with anything that matters.

Brand and content we produced

Brand & Design System (identity · templates · print-ready files)

The client: a business whose materials looked like they came from different companies — a logo nobody had the source file for, a profile document, a catalog, and a feed that shared nothing.

Details

What we built: one identity, and the system that keeps it consistent everywhere it is used. Direction first — a few concepts, then one taken forward: a logo in the versions that survive at billboard size and at icon size, a palette in screen and print values, a type set with fallbacks, and the rules that say how they go together. From there the system became the things actually published: social profile kits, post and ad templates in the sizes each platform takes, a company profile and a product catalog laid out on one grid so a long document still reads as one document, and export files a print house could take without a phone call. Both language versions were laid out properly — mirrored, never squeezed into a grid built for the other.

The decisions we made: one person approved the direction, because identity work stalls when three people vote; every file was delivered in a form another designer or printer can open and use without coming back to us, so the system outlives the engagement; and the boundary on photography was set before the quote rather than after it — we do not shoot, so images came from the client or from a partner shooter arranged for the job.

What it included: logo set (vector and raster, screen and print) · palette in screen and print values · type set with fallbacks · a usage sheet (correct use, spacing, minimum sizes) · social profile and post templates · ad and banner templates · company profile and catalog layout · print-ready export files.

Video & Motion Production (reels · explainers · 3D)

The client: a brand that needed a steady supply of video — short pieces for the feed, and a longer explainer for the thing that had to be understood before it could be sold.

Details

What we built: a pipeline that turns a brief into a file ready to publish. Script and storyboard first, approved before a frame was cut; then voiceover, edit, motion graphics, and color; then 3D where the story needed it — a product taken apart, a process shown from the inside, a space a viewer can move through. Delivery was per platform, in the aspect ratios and lengths each one takes, with on-screen text for a feed that plays silent. Live footage came from the client, from a partner shooter arranged for the job, or from licensed libraries: the camera was not ours, and everything after it was.

The decisions we made: approval happened at the script, because re-cutting a finished video costs far more than changing a line; each piece was cut for the platform it would live on rather than exported once and resized for the rest; and a large production — a brand film, a 3D campaign, a series — was scoped on its own and never folded quietly into a monthly volume.

Always-On Content Engine

The client: a brand that knew it should publish consistently and was producing content in guilty bursts followed by silence.

Details

What we built: a monthly production line: content pillars mapped to what buyers actually ask at each stage of deciding; a calendar mixing authority pieces, product education, and proof; graphics, carousels, and short video produced in both languages against the brand system; scheduling, publishing, and community replies handled on a defined cadence; and a monthly report reading performance against the funnel — which content pulled leads, not just which got likes.

The decisions we made: volume was set to what could be sustained and committed to in writing, because the failure here is a strong first month and a silent third; every post had a job in the funnel or it did not run; and the engine fed the sales system — content CTAs landed in the same intake the website used, so marketing and pipeline were one machine.

Messaging & Copywriting (positioning · page copy · one voice in both languages)

The client: a business whose words changed with whoever wrote them — the website said one thing, the profile document another, and the sales call a third.

Details

What we built: the message before the words. A message architecture setting out who the buyer is, what they are really choosing between, and the language that moves them; then the copy itself, written for the job each page had to do rather than poured in to fill a layout; both languages composed by someone thinking in that language rather than carried over from the other; and a short voice guide — the words we use, the words we do not, and how a claim gets made — so the next person to write for the brand sounded like the same company.

The decisions we made: positioning was settled before a line of copy was written, because copy cannot rescue a message nobody agreed on; claims that could not be supported were cut rather than softened, since a soft claim is still a claim; and neither language was written as a translation of the other, because translated marketing copy reads translated and buyers hear it.

Growth and automation we ran

Brand & Product Launch System

The client: a business taking something to market — a new offering that had to land — and wanting the launch to work as a system rather than as a burst of posts.

Details

What we built: a launch built as a system. Positioning and message architecture came first — what to say, to whom, in which words, each language version written for meaning rather than translated. Then the asset kit: launch content calendar, carousels, reels scripts, landing page. Then a phased rollout — authority content before demand content — across LinkedIn, Instagram, and X, each platform getting its native format. Every piece pointed at one measurable action, and the first month closed with a written read of what the market actually responded to.

The decisions we made: the launch narrative was settled before any design was produced, so the assets argued one story instead of ten; content in both languages was written twice, never translated once; and the calendar was paced to what the team could sustain after we stepped back — because a launch that goes quiet in week three reads as a company that went quiet.

Lead Generation Funnel (Ads → Landing → Nurture)

The client: a business that wanted a predictable stream of qualified inquiries rather than applause, and wanted every unit of spend accounted for against inquiries rather than impressions.

Details

What we built: the full path a stranger travels to become a lead. Paid campaigns on Google, Meta, and TikTok, targeted from the actual buyer rather than a demographic guess; dedicated landing pages designed for one action each, in both languages and fast; conversion tracking wired end to end, so every unit of ad spend maps to inquiries rather than impressions; and a nurture layer — email sequences and retargeting — working the majority who do not convert on day one. The budget stayed the client's, in the client's accounts; we managed, measured, and reported against cost per qualified lead.

The decisions we made: tracking went in before the first ad ran, because unmeasured spend is a donation; landing pages were kept separate from the main site so testing could move without waiting on a release; and campaigns got a written kill-or-scale review on a fixed cadence — losers died quickly, winners took the budget.

AI & Automation Ops (workflows · assistants · human review)

The client: a team whose week kept filling with the same manual steps — copying data between systems, answering the same questions, processing the same documents by hand.

Details

What we built: the manual work, mapped before any of it was automated. It started with an audit of how the job was actually being done — what triggered it, what the steps were, which systems it touched, and where a person still had to decide — and the automations were built on that map, inside the client's own accounts and tools. Where the work needed judgement rather than rules, an assistant was trained on the client's own material: their documents, their support history, their product answers, kept current as those changed. Internal copilots sat where the team already worked, so nobody logged into a second place to get an answer. Every workflow carries failure alerts, so a broken automation is caught by monitoring rather than by a customer, and a monthly report says what ran, what broke, and what came off someone's desk.

The decisions we made: nothing was automated before the workflow was written down — automation laid over a process nobody mapped is how these projects fail; the boundary was set up front, so the automation acts alone where a mistake is cheap and a person approves where it is not, with a logged trail behind both; and everything ran in the client's accounts, on the client's keys, so the workflows stayed theirs whatever happened to the arrangement.

SEO & Organic Search (technical foundation · buyer-intent pages · local presence)

The client: a business paying for every visit it received, with nothing compounding — absent from the searches its own buyers were already making.

Details

What we built: search as a system rather than a keyword list. The technical base came first — a structure engines could crawl, pages that loaded fast, structured data, and language targeting set so the two versions of a page stopped competing with each other. Then the pages themselves, written against the questions buyers actually type while they are deciding rather than the terms with the largest volume, in both languages and written for meaning in each. Then internal linking, so authority moved toward the pages that sell instead of pooling on the home page; a local search presence, where the intent is highest and the competition thinnest; and reporting that followed a query through to an inquiry rather than stopping at a ranking.

The decisions we made: the technical base was repaired before a word was written, because content on a site engines struggle to read is a slower donation; we wrote for buying questions rather than for traffic, since a page that ranks in front of the wrong reader is a cost; and each language was treated as its own market with its own queries, because a translated keyword list describes how one audience searches and no other.

Influencer & Reputation (creator campaigns · reviews · monitoring)

The client: a brand being judged on what other people said about it — reviews it did not control, and creators it had never worked with.

Details

What we built: the two halves of what a stranger finds before ever reaching the website. On the creator side: selection on audience fit rather than follower count, briefs that handed over the problem instead of a script, and usage rights and disclosure agreed in writing before anything was shot. On the reputation side: asking for a review at the moment a customer was actually satisfied rather than the moment it was convenient to ask, replying to every review in the language it was written in, and monitoring the places buyers check — so a complaint was handled while it was still one complaint.

The decisions we made: rights and disclosure were signed before production, because a piece you cannot lawfully reuse was rented rather than owned; negative reviews were answered in public and their causes fixed in private, since a defensive reply is read by everyone who arrives afterwards; and creators were briefed on the problem rather than handed a script, because an audience can hear a script.

Start your project

Still deciding?

Every question has a "not sure" answer. You will get a written reply within one business day telling you which scope fits — including when none of them does.

Start your briefSee all services