Business platforms and internal systems
Approvals, records and audit trails for the work your team does every day.
WWeb
Web application development, from the first screen to the servers behind it
Customer portals, internal platforms and SaaS products, built around roles, approvals and a record of every decision, then handed over so your own team can run them.
- 40+projects delivered
- 3 yrsa fleet platform we built and ran
- 12years building software
What we build
What we build, and have already shipped.
These are the six kinds of web application development we are asked for most. We have built platforms, portals, SaaS products, APIs and CMS-run websites for government, healthcare, retail and nonprofit clients, and for ourselves — and we have taken on an app somebody else started and carried it forward.
Customer portals and dashboards
Each customer signs in and sees their own data, live.
SaaS and multi-tenant products
Many customers, one system, with plans and billing built in.
APIs and integrations
The services behind the screens, and the systems you already run.
Websites with a CMS your team runs
Pages your own staff publish and edit, without a developer.
Taking over an existing app
We review what exists, then keep, fix or rebuild it a piece at a time.
Our strengths
Five things we get right, and the systems that prove it.
Most of what makes web application development expensive is invisible on a screenshot, which is why we point at the systems instead. Each one names the system it was proved on.
-
01
We model roles and permissions before the first screen
Who may see a record, and who may approve it, is settled before anything is drawn, and the server enforces it. ADVETI serves three audiences on one permission model.
-
02
We write the audit trail on day one
Who changed what, when, and what it said before. Added later it tells you nothing about last year, which is the year an audit asks about.
-
03
One back end, however many surfaces sit on it
A website, a portal, a staff console and an app are four views of the same data. One back end serves them all, so a rule changes once, not four times.
-
04
We size the screens that will slow down, first
Long lists, searches and reports slow down on the data you will have in three years, not the data you launch with. We build them for the bigger number.
-
05
We stay on after launch, when you want us to
We ran a vehicle-tracking platform for three years after building it, and a healthcare client still has us looking after theirs. Handing over is equally fine.
What we build with
What we build with, and what we can work in.
We choose the tools to suit the project, and everything here is something we have used on real work. We also write code the next developer can pick up, because a system like this usually outlasts the team that built it.
Angular
React
PHP / Laravel
Node.js
Python / FastAPI
Java
REST APIs
MySQL
PostgreSQL
MongoDB
Redis
SSO and OAuth
WebSockets
AWS
Docker
GitHub Actions
If your team already uses one of these, we work in it. And if your project needs something that is not on this list, tell us — we will look at it and give you a straight answer on whether we are the right people for it.
Cost and ownership
What affects the cost, and what you walk away with.
No two web application development projects cost the same, and what moves the price is usually not what people expect.
What affects the cost
- Roles and permissionsHow many kinds of user, and what each one may do.
- Workflows and approvalsA form filed once is cheap. One that can be returned, approved or escalated is not.
- SurfacesA website, a customer portal, a staff console and an app are four front ends, not one.
- IntegrationsWhether your existing systems have an API, and whether anyone wrote it down.
- Moving your old dataRarely the interesting part, and regularly bigger than it looks.
- ScreensEach one is design, build, empty and error states, validation and test.
What you walk away with
What you own
Handed over at the end of the build.
- Cloud and domain accounts in your name
- Source code you own
- A deployment pipeline
- Backups, tested by restoring
What else we can include
Quoted with the build, or added later.
- Automated tests
- A written runbook and handover notes
- Hosting and monitoring after launch
- New features and changes as you need them
Our work
Three from our work, in three different sectors.
Education · Admissions and management
ADVETI: online admissions and management system
A complete admissions and management platform for a government institute in Abu Dhabi. It includes a public website, an applicant portal and a staff console.
Nonprofit · Website and CMS
Roshni Helpline: website, CMS and management system
The public website, custom CMS and internal management system for Pakistan’s 24-hour helpline for missing children. It has report forms, a public gallery of posters, news and media, and a CMS that the team manages themselves.
Retail · Point of sale
Point of sale system for shops and branches
Eiglou POS is a point of sale and stock system for retail stores, including pharmacies. It handles fast billing, batch and expiry tracking, purchasing, accounts and daily reports from one control center.
The whole engagement was refreshingly smooth. The admissions and management platform did exactly what was promised — document checks, fee verification, approvals, all of it — delivered on time and properly documented. A team that clearly knows what it’s doing.
How we work
From first idea to a working web app.
01
Discover
We learn who will use the app, what they need to do, and what data it must handle.
02
Design
We plan the pages, the data and the user roles together, and start with the smallest version that works.
03
Build
We build in small steps and show you working pages regularly, so you can give feedback early.
04
Run
If you want us to, we host and monitor the app, keep it updated and secure, and fix problems as they appear.
FAQ
Common questions.
How soon could we have something our team can actually use?
It depends on what you need, but usually two to three months for a first release people can do real work in. We would rather get that into your hands than hand you everything six months later. What goes into it is agreed with you first, and it is normally the one or two things your team does most.
How much can our own team change without calling you?
As much as you want, and it is worth settling early. Content, pages and users are normally yours to manage yourselves. Rules, roles and workflows are normally ours to change, because getting one of those wrong causes a lot more trouble than a typo does.
Will it still be fast when there is far more data in it?
The screens that get slow are the long lists, the searches and the reports. They slow down on the data you will have in a few years, not the data you start with, so we build and index those parts for the bigger number from day one.
Can it work with the systems we already run?
Usually, yes. If your system already has an API, we use it. If it has no API but one can be built for it, we build that. And if it is completely closed, we will tell you early rather than discover it halfway through. Whichever it is, the part that matters most is agreeing which system owns each piece of information, so the two never disagree with each other.
Can it grow into something bigger later?
Yes, and most of our work goes that way. On a fleet-tracking platform we built, the client kept coming back with new requirements as they grew, and we added them a piece at a time over three years. Growing later is much cheaper when the first version was built expecting it, so we plan for that from the start even when it is not in the first release.
Do you host it and keep it running afterwards?
Yes, if that is what you want. We can host it, keep it updated and fix things as they come up, for as long as you need us. And if you would rather your own team ran it, that is just as fine — we set it up so they can.
What happens if we want to hand it to another developer?
You hand it over. The accounts are already in your name and the code is already yours, so there is nothing for us to release and nothing locked to us. If you want written handover notes for whoever takes it on, tell us and we will include that in the work.
Still deciding? Tell us what you are building and we will tell you what the first release should be, and what it would take.
Let’s talk about your project.
Tell us about your web app project. We will reply with what we would build first and what it would involve.