01
Customers need one place to act
Give customers access to their own requests, documents and updates, with the permissions and approval steps your service needs.
CUSTOM SOFTWARE & SAAS · SAUDI ARABIA & THE GCC
A customer portal, an internal tool or a subscription product should fit the people who use it. We turn the agreed workflow into working software, with Arabic and English screens, clear permissions and a plan for the systems it connects to.
Priced after discovery. We agree the users, workflows, integrations and acceptance criteria before committing to a build.
One request. A traceable path.
- Customer requestCapture the information needed to begin.
- Team reviewShow the record to the people allowed to act.
- DecisionApprove, return or ask for missing information.
- Shared recordKeep the outcome and its history together.
An illustrative approval workflow
A design illustration. The workflow, access rules and integrations are agreed for your project.Custom software & SaaS
Web applicationsArabic / EnglishRoles and permissionsDocumented APIsSource handover
WHEN CUSTOM SOFTWARE FITS
We first check whether an existing product can do the job. Custom development makes sense when your workflow, customer experience or integration needs justify owning and maintaining the software.
02
Your team works between spreadsheets
Bring a repeated task into an internal tool. Define who can change each record, what happens next and how exceptions reach a person.
03
You are testing a software product
Choose a useful first release, then agree how accounts, subscriptions and support will work before adding a wider feature list.
WHAT WE AGREE AND BUILD
The proposal names the deliverables and the boundaries. A portal with one workflow and a multi-tenant SaaS product need different architecture, tests and operating plans.
A workflow worth building
Map the people, decisions and exceptions. Turn the agreed first release into a backlog with acceptance criteria and explicit exclusions.
One request. A traceable path.
- Customer requestCapture the information needed to begin.
- Team reviewShow the record to the people allowed to act.
- DecisionApprove, return or ask for missing information.
Web applicationsArabic / EnglishRoles and permissionsDocumented APIsSource handover
A prototype before the build
Review the main journeys in Arabic and English, including empty, loading, validation and permission states. Agree which devices and browsers we will support.
Access rules applied to the data
Specify roles and record access, then test them at the application boundary. For SaaS, define tenant separation and the administrative exceptions.
Integrations with an owner
Document the agreed APIs, data mapping and failure handling. Decide which system owns each field before building a connector or migration.
Release evidence
Check the agreed scenarios, permissions and performance targets in a test environment. Record what passed, what remains and who accepts the release.
A handover your team can use
Hand over the agreed source, deployment instructions and operating notes. Confirm repository access, third-party licences and support responsibilities in the proposal.
FROM WORKFLOW TO WORKING PRODUCT
Each stage ends with something you can review. We keep new requests visible so they can be prioritised without quietly changing the agreed release.
Walk through a real task
Show us how the work happens today, including the awkward exceptions. We compare an existing product, a small custom extension and a new application.
A scope with a reason to exist
- Users and responsibilities
- Current systems and constraints
- First-release acceptance criteria
Test the route through it
Review a clickable prototype with the people who will use the product. Settle the main decisions before they become implementation work.
Screens connected to decisions
- Arabic and English journeys
- Permissions and exceptional states
- Feedback recorded against the scope
Build in reviewable increments
Implement the agreed workflow, data model and connections. Demonstrate working increments and track changes against the release backlog.
Working behaviour you can inspect
- Application and integration checks
- Permission tests
- Migration rehearsal where included
Release with an operating plan
Review acceptance evidence, agree the cutover and transfer the operating knowledge. Plan support and future improvements separately from the first release.
A product with named owners
- Acceptance and release record
- Source and configuration handover
- Support and rollback responsibilities
CONCEPT WORK
These are illustrative pieces from our demo portfolio. They show possible interface directions, rather than client projects or measured business results.
A workspace for a growing product
A platform concept brings account activity and product tasks into one workspace. The permissions, subscription logic and integrations would be defined for the actual product.
An internal view of moving work
A logistics concept explores how an operations team could follow tasks and exceptions. It is a starting point for discussing the workflow and the data it would need.
ENGAGEMENT OPTIONS
You can commission discovery, a defined build or a review of an existing application. Each engagement receives its own written scope and price.
Discovery
Map the product
For a team deciding what should be built and whether a custom application is justified.
Proposal after scope review
- Review of the current workflow and alternatives
- Agreed journeys, roles and data boundaries
- Prototype or technical investigation as scoped
- Prioritised release brief and delivery options
Defined build
Build the first release
For an agreed workflow with a defined audience, a scope owner and a clear acceptance process.
Proposal after scope review
- Application screens and access rules in the proposal
- Agreed data model, APIs and migration work
- Acceptance checks and release preparation
- Source, documentation and operating handover
Existing software
Improve an existing product
For a working application that needs a new workflow, a safer release path or a planned modernisation.
Proposal after scope review
- Assessment of inherited code and dependencies
- A change plan with compatibility boundaries
- Agreed feature, integration or migration work
- Regression checks and handover updates
The proposal confirms deliverables, milestones, payment terms and acceptance criteria. Hosting, subscriptions, usage charges and ongoing support are separate unless explicitly included. Existing website and app package inclusions remain as published; this service covers separately scoped business software.
BEFORE THE FIRST BUILD
Start by testing existing products against your real workflow, data access, integrations and exit needs. A configurable product may be the better choice. Custom software is worth considering when a material requirement remains unmet and your team is ready to own the cost of operating and maintaining it. We can help document that decision before a build.
No. Customer portals, approval tools and subscription products can use ordinary application logic. If an AI feature has a useful role, we scope its data, evaluation and operating costs separately. We do not add a model simply because the application is custom-built.
We quote after reviewing the workflow, user roles, integrations, migration and delivery constraints. There is no fixed starting price for this service. The written proposal sets out the work, exclusions and payment terms so you can compare a defined scope.
Yes. We agree the language coverage, supplied content and translation responsibilities in the scope. Arabic layouts need right-to-left behaviour, readable forms and checks with realistic names and content, alongside the English experience.
The proposal records source-code handover, ownership terms and repository access. Third-party packages keep their own licences. We also agree who owns hosting, domains and paid accounts, so access and operating responsibilities are clear before release.
We begin with access to the code, deployment process, dependencies and relevant documentation. The assessment identifies the work we can safely scope and any unknowns that need investigation. A migration or rewrite follows an agreed plan with checks, cutover responsibilities and a recovery approach.
The proposal defines the included defect-support period, if any, and the handover. Hosting, monitoring, ongoing maintenance and new features need named owners and an agreed support scope. Round-the-clock response and availability commitments are only included when explicitly agreed.