Custom web application development is the building of browser-based software for one organisation's own process: a client portal, an internal dashboard, a booking or job system, an approval workflow. It is distinct from a marketing website, which presents the business, and from a CRM, which tracks sales. Listonics designs, builds and maintains these for Dubai offices without in-house IT, in the client's own hosting accounts.
Part of our guide to Custom Software & Web Apps.
What a web application is, and what it is not
A marketing website tells the world what you do and asks a visitor to get in touch. A web application is something your staff or your clients log in to and work in. The difference is not technical polish. It is that a web application holds live data and enforces a process: who may see a record, what happens when it is approved, what the manager sees on a Monday morning.
It is also distinct from a CRM. A CRM tracks enquiries, contacts and deals. A web application can sit next to a CRM, pull from it or feed it, but its job is usually a process the CRM was never meant to run: a client checking the status of their file, a technician closing a job from a phone, a finance lead approving a purchase.
We build both, and we will tell you plainly which one you are describing.
When a web app is the right answer, and when it is not
Buy before build. If your process is standard, there is almost certainly a product that already does it, and configuring that product will be cheaper and better supported than anything we write. We say this on the first call and we mean it. Our IT consulting work includes recommending off-the-shelf tools we earn nothing from.
A custom web application earns its place in three situations. The process is genuinely yours and the products on the market force you to change it. The spreadsheet that runs the business has become the system of record, with several people editing it and nobody sure which copy is current. Or two systems you already pay for need to talk to each other and the vendors have no interest in making that happen.
If none of those apply, we will usually point you at a product and offer to set it up.
What we commonly build
Every project is specified from scratch, but most fall into a small set of patterns.
Typical web applications:
- Client portals: a client signs in, sees the documents and status that belong to them, uploads what you need, and nothing else.
- Internal dashboards: live figures drawn from your accounting system, your CRM and your job records, shown in one place without anyone compiling a spreadsheet.
- Booking and job systems: appointments, service calls, site visits or deliveries, assigned to staff and closed from a phone with photos and signatures.
- Approval workflows: leave, purchase requests, expense claims, contract sign-off, routed to the right person with a record of who approved what and when.
- Document portals: controlled sharing of contracts, drawings or reports with outside parties, with expiry and an access log.
- Integrations: data moving between Microsoft 365, your accounting package and a third-party system on a schedule, so that nobody re-keys it.
Discovery and a signed specification
Discovery is a short, paid piece of work before any code is written. We sit with the people who actually run the process, watch how it works today, and write down what the application must do, screen by screen and rule by rule. It also records what the application will not do, which prevents most of the disagreements that software projects are known for.
The output is a specification you sign. It fixes the scope, the schedule and the price for the build. If the business needs something added later, that is a change with its own small quote, not a surprise in the final invoice. You own the specification and can take it to another developer if you prefer.
Pricing is quoted after a scope call, never from a form on this page, because the same words describing a portal can mean a week of work or a season of it.
Sign-in through Microsoft 365, roles and permissions
Almost every office we work with already runs on Microsoft 365. So the application signs people in with the accounts they already have. There is no separate password to forget, multi-factor authentication is inherited from the tenant, and when someone leaves, disabling their Microsoft account removes their access to the application in the same moment.
Inside the application, roles decide what a signed-in person can see and do. A technician sees their own jobs. A supervisor sees the team's. The finance lead sees costs. A client sees their file and only their file. These rules are written into the specification in plain language before they are written into code, so that the owner of the business can read and approve them.
For portals used by outside clients without an account in your tenant, we add a separate client sign-in with the same discipline: individual accounts, verified email, and an optional second factor.
Security baseline and UAE data protection
A web application is reachable from the internet, which means it is tested by strangers from the day it goes live. We build against the OWASP Top Ten, the standard list of web application security risks: injection, broken access control, misconfiguration, weak authentication and the rest. Each item has a specific defence in the code and in the hosting, and we document which.
The data inside the application is your clients' and your staff's. UAE data protection law sets out obligations on how personal data is collected, used and kept, and some free zones add their own rules. We design for the minimum data the process needs, record where it is stored, and make deletion and export possible rather than theoretical. Where the hosting region matters to you or your regulator, we choose it with you and write it down.
The same team that handles our cybersecurity work reviews every application before launch.
Hosting, code and what happens if you leave us
The application runs in a hosting account that belongs to you, paid for by you, with us as an administrator you can remove. The source code lives in a repository you own. The database is yours. The domain is registered to you. None of this is unusual to ask for, but it is unusual to get, and it is the first thing to check before engaging any developer in Dubai.
If you decide to stop working with us, you keep everything: a running application, its code, the specification, the documentation and the administrator credentials. Another developer can pick it up without asking us for anything. We would rather earn the maintenance work than hold it hostage.
Listonics is not an authorised reseller or partner of any software vendor or hosting provider. We recommend platforms because they fit the job, and the bill for them goes to you directly.
Maintenance and pricing
Software needs looking after: security patches, library updates, a tested backup, small changes as the business shifts. Clients on our managed IT support have the application covered under the same agreement as their laptops and network. Clients who are not can take a standalone maintenance arrangement.
Projects at Listonics run from AED 2,500 to AED 30,000 depending on requirement. A simple internal tool with one or two screens sits at the lower end. A client portal with Microsoft 365 sign-in, roles, document handling and an integration into the accounting system sits towards the upper end. Everything is quoted after a scope call and fixed in the signed specification.
If what you are describing is closer to a full business system covering quotes, stock, jobs and invoicing, read our page on custom ERP software first. It is the same team and the same approach, applied to a bigger problem.
Frequently asked questions
Yes, and we recommend it. The application trusts your Microsoft 365 tenant for identity, so there is no second password, multi-factor authentication carries over, and leavers lose access when their Microsoft account is disabled. For outside clients without an account in your tenant, we add a separate client sign-in with its own controls.
You do. The code sits in a repository registered to your business, the application runs in a hosting account you pay for, and the database is yours. We hold administrator access while we maintain it and you can revoke that access at any time. This is written into the specification, not left to goodwill.
Buy if the process is standard. We will say so on the first call and, if useful, set the product up for you. Build when the process is genuinely yours, when a shared spreadsheet has become the system of record, or when two systems you already pay for need to exchange data and their vendors will not help.
We build web applications that work well on a phone, which covers most office needs: a technician closing a job, a manager approving a request, a client checking status. A native app store application is a different undertaking with ongoing store and device costs, and we only recommend it when the phone's hardware is genuinely needed.
The schedule is set in the signed specification, because it depends on the scope and on how quickly your side can review and test. We split larger projects into phases so something useful goes live early. We will not quote a timeline on this page, since we do not yet know what you need.
You keep the running application, the code, the specification, the documentation and the administrator credentials. Another developer can take over without needing anything from us. We provide a handover note describing how the system is built and deployed as part of every project, not only at the end of a relationship.
Written by Srinivasan Ramachandran, Founder, Listonics · Last reviewed October 8, 2026