Web applications

Area: Dashboards & Web Applications · Usual shape: a product with accounts and roles · Access: any browser

The difference between a website and a web application is the difference between what is read and what is worked in. Here the user opens the same screen every day, so every unnecessary step becomes a repeating cost. We build browser products that actually get used: clear roles, short screens, predictable behaviour under load.

Talk to us about your project See the whole area

Opens WhatsApp. Nothing is sent until you press send there.

What this solves

A service is delivered manually and cannot grow past the people delivering it.
A desktop application ties the work to particular machines.
An internal tool worked well and other people now want it.
The product must run anywhere without anything being installed.

What we build

Product definition, its boundaries, and what is deliberately deferred.
The account, role and — where relevant — subscription model.
The core screens where users will spend their time.
The data model and the rules that keep it consistent.
Performance under real use rather than demo use.
An internal admin panel for the people running it.
A release path that repeats reliably.
An interface in Arabic and English.

Where it is used

A service delivered manually that should become a product.
A desktop application moving to the browser.
An internal tool that could be offered to others.
A product that must run on any device without installation.

What this does not include

We do not set the business model, the pricing or the market strategy.
We do not undertake that the product will find a market.
Payments and subscriptions are agreed separately and never assumed.
App-store distribution is different work.

How the work goes

We define what the product is for in one sentence, and what it is deliberately not.
We design the two or three screens people will live in before anything else.
We build a usable first version rather than a complete one.
We measure real use and let it decide the second version.

Custom business systems
when it is internal and shaped by one company’s process.
Admin & control panels
when what is missing is the back office behind an existing product.
Product & app interface design
when the product needs designing before it is built.
API design & development
when other systems will need to reach it.

Questions about this service

How is this different from a website?

A website is read; a web application is worked in. If someone opens it daily to get something done, and it has accounts and permissions, it is an application — and it is built and tested differently.

Does it work on a phone?

It is designed to, with different priorities on a small screen. We agree early which tasks genuinely need to work on a phone rather than trying to fit everything onto one.

Can we start with a limited first version?

Yes, and it is usually the right call. A narrow product that a few people use properly teaches you more than a broad one nobody finishes setting up.

How are accounts and subscriptions handled?

Accounts and roles are core and always in scope. Subscription billing is a separate decision we agree explicitly, and never assume because a product looks like it should have it.

How many users can it handle?

We design for the number you give us with a sensible margin, and measure before launch rather than promising. A figure quoted without a test behind it is not a number.

Tell us what the product should let people do.

Talk to us on WhatsApp Or send the details through the form