Included in a typical proposal
- Build of the named journeys and roles.
- Integrations listed.
- Deployment to the environment in the proposal.
SOFTWARE DEVELOPMENT
Web application development
in Dubai & the UAE.
Put business workflows into a browser-based application. Portals, dashboards and internal tools can make information easier to access and reduce the need to move records between separate files.
WHAT THIS SERVICE IS
A plain explanation of the work.
Web application development is a browser-based system for people who need to log in and complete work: an internal tool, a customer portal, a dashboard of records, a booking back-office. It is heavier than a marketing website and lighter than a mobile app you must publish in a store. If the public site is mostly brochure content, use the web hub instead.
Portals fail when they are a dump of every report someone might one day want. They succeed when a role can finish a task — submit a reading, approve an invoice, download a document — without training slides. Offline use, if you need it, is a requirement, not a pleasant surprise of the framework.
Authentication, roles and audit of who changed a record belong in the first release if the data is sensitive. Bolting them on later is more expensive than naming them now.
A CLEAR PICTURE
A labelled diagram, not a decoration.
- Roles Who is allowed to do which task.
- Records The objects people create and approve.
- Sign-in How identity is proven, preferably with an existing account.
- Host & backups Where it runs and how you get it back.
WHO IT IS FOR
The situations this page is written for.
Operations teams who want staff to stop emailing spreadsheets, businesses that must give customers a login to see their own records, and departments that need a shared queue rather than a shared inbox.
- Managers who can name the roles: requester, approver, admin.
- Teams with an identity source (Microsoft 365 or similar) they want to reuse.
- Companies that need the tool on office laptops and on a phone browser.
- IT owners who care where the application is hosted.
TYPICAL SCOPE
What a proposal usually names.
01
Application scope
User journeys, data entities and the first useful release. Reporting that needs a warehouse is called out. A portal that only displays PDFs is still in scope if that is the job.
02
Permissions and data
Who may see whose records. Multi-tenant separation, if you serve several customers, is a design, not a CSS class. Personal data handling follows your instructions and applicable law; we implement the rules you set.
03
System connections
Documented APIs, file drops, or single sign-on as named. A nightly CSV can be the right integration. It is not a moral failure.
04
Release preparation
Environments, backups, how you deploy, and a rollback if a release fails. Browser support is current major versions unless you still depend on an old internal browser — say so, it changes testing.
HOW THE WORK RUNS
The sequence we follow once the brief is clear.
-
List tasks per role
If a role has no task, it does not need a login yet.
-
Design records and permissions
On paper, then in the application.
-
Build the journeys in slices
Each slice is demonstrable.
-
Deploy with a runbook
Someone other than the author should be able to ship a fix.
INCLUDED AND QUOTED SEPARATELY
Labour versus things that sit on their own line.
Quoted separately
- A public marketing website.
- Native iOS or Android apps (see mobile).
- Data cleanup projects.
- Around-the-clock operations unless maintenance is signed.
AFTER HANDOVER
What you should hold when the work is done.
Admin users, environment URLs and secret storage are yours. If we used sample data, it is removed from production. Logs that contain personal data need a retention rule you approve.
Browsers and identity providers change. A web application without maintenance still needs someone to renew certificates and dependencies. Name that someone.
PRACTICAL NOTES
Details that usually affect the proposal.
Single sign-on against Microsoft 365 is often worth it if staff already live there. It is still a named integration with a redirect URI in your tenant, not a toggle we can invent. If you prefer separate logins, password reset and lockout rules must be in the first release. Forgotten-password mail needs an email-sending account in your name.
Audit logs that nobody can read are decoration. If you need to know who approved a record, we will store that and show it to an admin. If you do not, we will not build a fake compliance screen. Say which you need; both are valid, they are not the same build.
PLANNING THE WORK
Questions worth asking.
Is this the same as custom software?
It is a common shape of custom software: delivered in a browser. The custom software page is the broader workflow conversation; this page emphasises portals and logged-in tools.
Can it work on a phone?
If we design the layouts for it, yes, as a responsive web app. A store-listed native app is the mobile service.
Will you host it?
If the proposal says so, on an account you own or a clearly described arrangement. Silent hosting on a personal cloud is not acceptable handover.
CONNECTED SERVICES
Explore the next piece.
LET’S BUILD WHAT’S NEXT
Your next step starts
with a conversation.
Tell us what you want to improve, build or simplify. We’ll help you define a practical way forward.
Discuss your project