Web
Web application development for products people use all day
We build web applications for customers and staff: portals, internal tools, dashboards, and the public sites that have to do more than display a brochure. The browser is the client. The system of record, permissions, and integrations sit behind it.
- Portal development
- Dashboard development
- Enterprise web apps
- SaaS web applications
The kinds of web systems we take on
A marketing site and a multi-role operations portal fail in different ways. We are usually hired for the latter, and for customer applications that need accounts, files, payments, or workflow. Content sites are in scope when they are part of the same product.
- Customer and partner portals
- Staff dashboards over operational data
- SaaS web applications with roles and billing hooks
- Progressive web apps when an installable mobile client is useful and a store release is not the constraint
Architecture we default to
A typed API, a clear permission model, and a front end that does not become the place where business rules hide. Server-side rendering or prerendering is used when the pages must be findable or the first view must be fast. File uploads, exports, and background jobs are designed as part of the product, not patched on after the demo.
When a web app is the right client
Choose the web when people work at desks, when you need to update the product without an app-store review, or when partners should enter through a browser. Choose a native or cross-platform app when cameras, offline field work, or push on a locked phone are central. Many products need both, sharing one API.
A web product, not a set of screens
Ships together
- The journey a customer or clerk repeats
- The admin that keeps that journey true
- Roles for the people who sign in on day one
A later slice
- Every dashboard someone might want
- A second brand or a second country
- Pages that have no owner for the content
Decisions that change a web build
Who signs in
Customers, staff, and partners are different products if they share one accidental login.
Where the record lives
A portal over a system you already run is smaller than a new database of truth.
Languages
Arabic and English in the first release is real layout work. One language, with room for the other, is an honest cut.
What a web brief needs
- 01
Who signs in
Customers, staff, partners, or a mix.
- 02
The journey
The one path people repeat, not the full sitemap.
- 03
The record
Whether this site owns the data or shows a system you have.
- 04
Languages
Arabic, English, or both in the first release.
Marks a web release is in use
- 01
The journey completes
The repeated task, from sign-in to done, works for the role that owns it.
- 02
Admin matches
What staff change in the back office is what the customer or clerk sees.
- 03
Roles are real
Day-one accounts cannot open each other by accident.
- 04
Content has an owner
Every page that ships has a person who will update it.
What we build
Portal development
Separate experiences for customers, agents, suppliers, or franchisees, with the same underlying records.
Dashboard development
Operational views with definitions someone can explain, not a wall of charts without an owner.
Enterprise web apps
Long forms, approvals, audit history, and integrations into identity and finance systems.
SaaS web applications
Tenancy, roles, and the admin tools you need before the second customer arrives.
How an engagement runs
- 01
Map roles and screens
Who signs in, what they are allowed to see, and which task the first release must finish.
- 02
Build the vertical slice
One complete path, from interface through API to data, before the rest of the screens multiply.
- 03
Harden for launch
Sessions, authorization tests, error handling, and a way to see failures after go-live.
Related reading
Questions we hear
Which front-end framework do you use?
Angular, React, Vue, or a server-rendered framework, chosen for the product and the team that will maintain it. We do not pick a framework because it is fashionable in a given month.
Can you improve an application we already have?
Yes, if we can see the code, the hosting, and a list of the failures that matter. Some rescues start by making release and rollback boring again.
Do you build in Arabic and English?
When the product needs it. Layout, content entry, and formatting are planned at the start so Arabic is not a translation pass squeezed in at the end.