Relevant work for UAE buyers

Judge the engineering by the operational problem it solved, not by a country label.

Our case studies are not presented as UAE projects unless they actually were. Instead, we show the system, constraints and operating responsibility so UAE buyers can evaluate whether the same engineering depth fits their own business.

  • Remote engineering relationship with Nördia AB in Sweden
  • Market-aware English and Arabic product delivery
  • Clear ownership of accounts, data, releases and operation
Case Studies

Systems built around real operational constraints.

Selected case studies across software products, business systems, commerce, automation and digital services. Each one focuses on the problem, the system behind the interface and the engineering decisions that mattered once the product had to work in practice.

01AI Career Intelligence · Sweden

IDEALISK

Current Product · Active Development

A career product designed to make the Swedish labour market easier to understand and navigate.

Idealisk is being developed as a multilingual career-intelligence product that brings job discovery, interpretation, matching and application support into one product. It starts with the person rather than the vacancy feed, then uses that context to make opportunities easier to understand and evaluate.

The system retains more professional context than a conventional job search: role direction, experience, constraints, language, preferences and application readiness. That context can then shape how opportunities are explained, compared and prioritised instead of asking the user to reinterpret every listing from scratch.

The architecture goes well beyond prompting a model. User data, opportunity structure, matching logic, explanations, application support and provider-specific AI behaviour are kept separate so the product can evolve without becoming dependent on one opaque prompt or one model vendor.

The intended product is closer to a guided career system than a job board. Market information is collected and normalised, relevance is explained in the context of the individual, and the user is supported from discovery through to a credible application.

The product separates facts collected from the labour market from interpretation generated by AI. Job requirements, employer information and user-provided career context can be stored as structured data, while model-generated interpretation remains a separate layer that can be explained and evaluated. That matters because matching should improve without allowing a probabilistic model to overwrite the underlying facts.

The platform is being built for repeated use rather than one-off generation. Saved searches, opportunities, application progress, language preference and an evolving profile need to survive across sessions. That means preserving user context and keeping provider-specific AI behaviour contained as models change. It also means preserving provenance: users should be able to tell what came from a vacancy or their profile and what was generated as interpretation. That distinction makes explanations easier to inspect and gives the product a firmer basis for evaluating whether recommendations are actually improving rather than simply sounding more fluent.

AICareer IntelligenceMultilingualMatchingApplication Support
Visit project
App Screenshot
Person-first career model

The system retains professional context so opportunity evaluation begins with the individual instead of the vacancy feed.

Multilingual interpretation

Language shapes the guidance itself; it is more than an interface translation.

Opportunity normalisation

Listings and requirements are structured into information that can be compared, explained and acted upon.

Application continuity

Discovery, matching, explanation and application support remain within the same product journey.

AI kept separate from source data

Structured user and opportunity data remains separate from model-generated interpretation so the platform can explain how guidance was produced and improve it over time.

Explanations linked to their source information

The product preserves the link between source information and generated interpretation so guidance can be inspected and evaluated more easily.

02Print Operations · Self-Service · Production Routing

PIXE

A print system that carries the customer's specification all the way into production.

PIXE is being built as a system for running print work, not simply as an online storefront. File intake, specification, pricing, payment, production routing and local self-service all use the same job model.

A customer can supply a file and define the characteristics that affect production: page count, colour mode, stock, thickness, finishing, quantity and fulfilment. The same choices feed both pricing and the production specification, so staff do not have to reconstruct the order manually after checkout.

Once accepted, the job keeps the file, customer, payment status, fulfilment method and print requirements together in one record. Jobs that need intervention can enter a manual review route, while suitable work can be directed automatically according to print mode, paper, thickness and the capabilities of the available equipment.

The same model extends to in-store self-service. A customer can start a print job on site, configure it and select or be directed to compatible equipment without creating a separate process. The website is therefore one interface into the print system, not the system itself.

The difficult part of print commerce is the gap between what a customer can configure and what production can actually deliver. A technically valid file can still be unsuitable for a chosen stock, colour mode, finishing method or machine. Treating equipment capability as structured data allows the system to validate and route work instead of leaving compatibility knowledge only in an operator's head.

That structure also creates a basis for scaling the operation. Once jobs have consistent specifications, status and routing history, the business can see where manual intervention occurs, which configurations create rework and which equipment carries the load. Automation can then follow evidence from production rather than assumptions about what ought to be automated. Pricing also stays tied to a specification the production system can understand, while staff can see whether an order is ready, blocked or needs intervention. The aim is to keep selling print online connected to the reality of producing it.

Pricing EngineProduction RoutingSelf-ServicePrint AutomationOrder System
Visit project
App Screenshot
Rules-based pricing

Production choices affect price through defined rules, reducing the need for manual quotations on routine work.

One persistent job specification

File, settings, payment, customer and fulfilment stay attached to the same production job.

Production routing

Jobs can follow manual or automated routes according to readiness, media requirements and printer capability.

In-store self-service

Local customer printing uses the same specification and routing principles as the online workflow.

From checkout to production

Pricing and checkout stay connected to a production specification that operators can execute without rebuilding the order by hand.

03Restaurant Commerce · POS · Brand System

JUBRAN

A restaurant system connecting ordering, point of sale and the customer experience.

Jubran combined the public website, digital ordering, delivery flow and a custom POS setup with the restaurant's visual identity, photography and physical material.

The key systems decision was not to treat digital ordering as an isolated website transaction. Customer orders were connected to fulfilment, delivery and point-of-sale activity so the public interface remained connected to the work happening behind it.

The brand system was developed alongside the restaurant system rather than applied afterwards. Colour, visual language, photography and physical material were shaped around the restaurant, its food, audience and location so the digital and physical experience felt consistent.

The project reflects a practical principle: a digital product often extends beyond the screen. Ordering, POS, delivery, staff workflow and physical customer touchpoints all affect the quality of the same service.

Restaurant software is especially sensitive to timing. An order may be accepted, prepared, delayed, cancelled, handed to delivery or corrected while the customer still expects the public interface to show something credible. Connecting ordering to the restaurant workflow reduces the need for staff to translate website events manually into kitchen or POS actions. The physical and digital experience also need to agree: menu presentation, photography, campaign material, order language and staff workflow all shape what the customer expects after purchase. Reliability matters most during peak service, when a workflow that is merely inconvenient at quiet times can quickly become unmanageable. Clear order status and predictable hand-offs leave staff to fulfil orders rather than interpret ambiguous software.

OrderingPOSDeliveryIdentityPhotography
Visit project
App Screenshot
Order-to-POS continuity

Digital orders enter a defined fulfilment route instead of ending as messages staff have to interpret manually.

POS integration

Point-of-sale behaviour is treated as part of the order system rather than as an unrelated back-office tool.

Delivery built into the workflow

Fulfilment and delivery remain part of the order lifecycle instead of becoming an afterthought after checkout.

Connected brand system

Identity, photography and physical material are developed around the same customer and operating experience.

Peak-service resilience

Clear order status reduces the amount of manual interpretation staff need during the busiest periods.

04Service Product · Booking · Creative Operations

SHOTY

A creative service designed around the full customer journey, not a static portfolio.

SHOTY combines service positioning, identity, website and booking with the photography, lighting, video and campaign work delivered by the business. The digital product and the physical service were designed together.

Creative businesses often separate marketing, enquiry, booking, delivery and presentation into unrelated touchpoints. SHOTY was designed so the advertisement, website, appointment and final work feel like stages of the same service rather than disconnected experiences.

Booking is more than a calendar. It connects interest with actual service delivery, so packages, expectations, availability and customer communication all affect the product design.

The project combines software with direct creative production: booking and service flow on one side, photography, lighting, video, identity and campaign material on the other. That allows the experience to be designed from the first impression through to the delivered work.

A booking product also has to remove ambiguity around availability, package scope, preparation, location, timing and customer communication. Putting those expectations into the booking journey reduces corrective messages after a customer has committed. Because the delivered work is visual, the experience can be judged from both sides: the website needs to establish trust, the booking flow needs to be easy to complete, and the final photography or video needs to match the expectation created earlier. The same principle applies to other service businesses: digital conversion and physical delivery work better when they are designed together. Booking behaviour can also show which services attract interest, where customers drop out and what information they need before committing, providing useful evidence for improving packages and communication.

BookingService DesignPhotographyLightingVideo
Visit project
App Screenshot
From discovery to booking

The journey from first interest to confirmed appointment is treated as one connected customer path.

Clear service packaging

The service is structured with clear positioning, expectations and a defined route to booking.

Creative work and digital product together

Website and booking are developed alongside the photography, video and brand system they represent.

One experience from campaign to delivery

Campaign, website, appointment and final delivery are treated as parts of the same service.

Demand signals from booking behaviour

Booking behaviour can show where service packaging or missing information causes customers to hesitate before confirming an appointment.

05Adaptive Inventory · Shipping · Commerce

VERSION

Inventory and fulfilment decisions driven by actual sales behaviour, not static assumptions.

Version used a purpose-built inventory model that connected stock availability with fulfilment decisions and allowed low-stock thresholds to adapt to the sales rate of individual products.

A fixed reorder threshold makes little sense when products sell at very different rates. The system therefore used sales behaviour to inform low-stock logic so an item selling ten units per month did not receive the same treatment as one selling hundreds.

Fulfilment decisions also considered the delivery location and where stock was available. Carrier selection could therefore respond to the actual order instead of relying on one static shipping configuration.

The result was less manual threshold maintenance and a closer link between purchasing decisions, stock movement and real demand. The wider engagement also included the commerce experience, interfaces, customer journey and SEO.

Adaptive inventory also changes what staff need to see. A useful low-stock warning should show why attention is needed, such as recent sales rate, available units, expected lead time or a threshold derived from current demand. That is more useful than a static warning staff have to interpret manually for every product.

Fulfilment creates a similar opportunity for defined rules. When stock exists in more than one location, the system can consider both availability and destination instead of sending every order through one warehouse or carrier. The value is in making those decisions consistent and understandable, not hiding them behind unexplained automation. Once the system can show why a threshold changed or why an order followed a particular route, later optimisation can be based on evidence while staff retain the ability to inspect and correct the decision.

InventorySales VelocityShipping LogicAutomationCommerce
Visit project
App Screenshot
Sales-rate thresholds

Low-stock logic can adapt to how quickly each product sells.

Fulfilment based on stock availability

Shipping decisions account for both delivery location and where stock is available.

Automated replenishment rules

Replenishment logic reduces repeated manual adjustment across the catalogue.

Commerce connected to fulfilment

The buying journey, stock model and fulfilment logic are treated as connected parts of the same system.

Stock warnings with an explanation

Inventory warnings can reflect sales behaviour and current stock conditions so staff can see why a product needs attention.

Inventory rules encoded in the product

Inventory and fulfilment decisions become defined rules that can evolve without relying on undocumented staff knowledge.

06Multi-Market Commerce · Recommendation Logic

EUTALL

Commerce designed to adapt by customer and market.

Eutall was designed as a multi-market commerce platform rather than one storefront translated several times. Recommendations, content, currency, SEO, fulfilment and the order journey can vary by market while remaining part of the same product.

The recommendation layer can adapt suggestions to user-supplied context, including age and relevant health information. That logic is kept separate from the market-facing commerce layer so recommendations and regional presentation can evolve independently.

Language, currency, content presentation, local SEO, shipping providers and order handling can change by country. Behind the customer experience is an order-management model that supports how each market is fulfilled instead of forcing every region through the same process.

The platform also keeps first-party visitor data alongside optional external analytics. Core behavioural information therefore remains available within the product instead of depending entirely on a third-party analytics account.

Multi-market operation raises a practical question: which differences belong to the market and which belong to the product itself? Keeping that distinction clear prevents localisation from turning into a set of country-specific code branches. Customer, product and order concepts can remain shared while market configuration controls language, currency, fulfilment, content and commercial behaviour where those genuinely differ. Recommendation inputs can likewise be structured and validated independently of regional presentation and commerce rules, so the recommendation logic can improve without becoming tied to one storefront or delivery model. Search behaviour and acquisition also vary by market even when the catalogue is shared. Localisation is therefore treated as part of how the product reaches and converts customers, not as a translation pass added after the commerce system is complete.

RecommendationsLocalisationLocal SEOShippingFirst-Party Analytics
Visit project
App Screenshot
Recommendations based on user context

Recommendation logic can respond to user context instead of presenting the same catalogue in the same way to everyone.

Market-specific product behaviour

Language, currency, SEO, fulfilment and order behaviour can vary by country.

Order management behind the storefront

The order continues into internal handling after checkout rather than ending at the storefront.

First-party visitor data

Core visitor data remains available inside the platform while external analytics stays an optional integration.

Local search and acquisition

Search language and market-facing content can vary by region while still using the same underlying product and order model.