Work & case studies
Case studies from design to deployment
A portfolio is only useful if it shows how decisions were made. Here is the kind of work BBI Digital Studio takes on, and what to look for when you judge any studio's delivery — including ours.
Reading the work
What belongs in a case study
Screenshots alone do not show whether a team can handle a migration, a legacy integration, or a launch deadline. When you review our work or anyone else's, start with the constraint. That is where the real engineering shows.
What the business actually needed
A sales goal, a service bottleneck, a manual process that had outgrown the spreadsheet. We write it in plain language before any screen exists, because a brief that stays vague is the first thing that sinks a build.
The limit the work had to respect
An existing database that could not be swapped, a fixed launch window, a team of two maintaining the result. Constraints shape architecture more than preferences do, so they belong at the top of the page, not buried in an appendix.
What was actually delivered
The storefront, the admin panel, the API layer, the design system — named one by one, with who wrote what. If a studio only handled one screen of a project, that should be visible here.
What moved after launch
We measure against criteria agreed before the build started, using your own analytics rather than numbers we chose ourselves. The point is not a headline figure; it is whether the thing we promised to change actually changed.
Web platforms and e-commerce
The interesting problems are rarely visual
Web projects in this market usually combine a public storefront with an internal system: order management, stock, or a seller dashboard. Keeping product data consistent across channels, handling peak traffic during a campaign, and giving a non-technical team real control over content — that is the layer we design and test carefully.
A storefront that looks right but falls over on a busy Friday is not a finished project. So the checklist we publish with each web case study covers the parts you cannot see in a screenshot.
Front of store
Catalog and checkout flows built for a fast first load on mobile networks, product pages that stay consistent when a seller edits stock, and search that copes with local spelling and mixed languages.
Behind the counter
Order and stock tools the operations team can run without us, roles and permissions that match how the business actually works, and a data model that survives a second sales channel being added later.
Mobile and cross-platform products
Built for the phones people actually carry
App projects split roughly into customer-facing products and internal tools. Customer apps need clean onboarding, reliable accounts, and performance on the mid-range Android devices many users in the region carry. Internal tools need speed of use and tolerance for a weak connection.
Both need a backend that will not fall over when the user count grows, which is why we scope the server side alongside the app rather than after it.
Customer-facing apps
Onboarding, accounts, notifications, and a first screen that loads before the user loses patience. We test on real mid-range hardware, not only on the newest phone in the office.
Internal tools
Fewer taps per task, a layout that survives gloves and daylight, and local caching so a shift does not stop when the connection does. Success is measured in minutes saved per shift.
UX/UI and design systems
Design work shows up as decisions, not decoration
How was the checkout flow simplified? What happened to the navigation when the catalog grew from forty products to four hundred? Those are the questions a design case study should answer, and they are easier to judge than a polished mockup.
A design system that holds up under new content is worth more than a beautiful prototype. It is also the part clients keep using long after handover — which is why we hand over the tokens, components, and usage notes as part of the delivery, not as an optional extra.
What we hand over
Component library with real states, spacing and type tokens, content rules for the editors, and a short written guide to adding a new page without breaking the layout.
How we test it
We add a page the system was not designed for, with longer text and a new content type. If the layout bends instead of breaking, the system is ready to leave our hands.
AI and automation
Judged by whether a day got easier
The useful examples are narrow. A tool that reads incoming documents and fills a form. A search that understands product queries in the way customers actually phrase them. An assistant that drafts replies for support staff to review before they go out.
We describe the limits of each system as clearly as the gains — where it still needs a person, what it does not know, and how its output is checked. A demo that only works on a clean example is not a delivery.
Consulting and integration engagements
Some of our most useful work is a plan rather than a product. These projects are successful when your team can run them without us afterward, so the deliverable is written to be handed over.
The plan
A system map
Every tool, database, and spreadsheet currently in play, drawn in one place with the data flowing between them. Most teams have never seen their own stack on a single page.
The path
A migration route
The order in which systems can move, what has to stay running throughout, and where a rollback is still possible. Sequencing matters more than the destination.
The work
A prioritized backlog
Integration work then links websites and apps to your CRM and support tools, so the plan meets reality. Items are ordered by what unblocks the most people first.
How we measure whether a project worked
Agreed before the build starts
We write the success criteria down together in the first weeks of a project, then report against them. Numbers come from your analytics, not ours, so there is nothing to negotiate at the end.
For a store
Checkout completion and page speed on the devices customers use, measured across a full campaign cycle rather than a quiet week.
For an internal tool
How long a task takes compared to the old process, timed with the people who do the work, not with us watching over them.
For an app
Retention and crash-free sessions, read alongside support tickets so a falling number is explained rather than just reported.
For a consulting engagement
Whether your team can operate the system alone — the clearest signal that the engagement did what it was hired to do.
Reading a portfolio critically
Ask what part of each project the team actually did
Studios sometimes present work where they handled a single screen. Ask who wrote the backend, who ran QA, and who still maintains the code today. The answers separate a full-cycle studio from a subcontractor with a nice website.
The same questions apply here. We work as a full-cycle team across web development, mobile apps, design, and AI work, and where a project used an outside specialist we say so rather than folding it into our own name.
Not every project is public. Some clients prefer that their systems stay out of view, and we describe that work only in the abstract — the problem, the approach, and the technology — without naming anyone or exposing data.
Before you write to us
Questions we get about the work
If your question is not here, write to us and we will answer it directly rather than pointing you at a brochure.
Can you show work under NDA?
We can describe the problem, the approach, and the technology without naming the client or exposing data. For most readers that is more useful than a logo wall anyway, because it shows how a decision was reached.
Do you maintain projects after launch?
Yes, through ongoing support arrangements or per-task work. Some clients keep a monthly retainer for changes and monitoring; others come back only when they need a new feature, and both arrangements are fine with us.
What technologies do you use?
We choose from the standard web and mobile stacks based on the project, including cross-platform frameworks and cloud infrastructure. If a client already runs a platform their team knows, that usually wins over our preference.
How does a project usually start?
With a short call about the problem and the constraint, then a written scope with success criteria attached. Nothing gets built before those criteria are agreed, because they are what we report against later.
Next step
Tell us the constraint, and we will tell you how we would approach it
Bring the messy version: the deadline, the system that cannot be replaced, the process nobody wants to touch. That is where a useful conversation starts.