Software Development
Web Application Development
Scalable web platforms and customer portals
A web application is the software your business actually runs on: the portal your customers sign into, the dashboard your operations team works in all day, the platform your service is delivered through. We design, build and launch those systems end to end — and then stay on to run and improve them, which is the part that decides whether the investment pays back.
This is not a brochure website with a login button bolted to it. A web application holds real data, real users and real money moving through it, so the parts nobody sees in a demo are the parts that matter: authentication, permissions, audit trails, backups, and behaviour under load on a bad day. That is where most of our engineering time goes, and it is why these projects are quoted as engineering work rather than as a number of pages.
What's included
What we build
Customer portals and self-service accounts
where your clients check status, download documents, approve work and settle invoices without emailing anyone.
Internal dashboards and operations tooling
the screens your own team runs the business from, usually replacing a spreadsheet that stopped being safe years ago.
Multi-tenant SaaS platforms
one codebase serving many customer organisations, with the data isolation and per-tenant billing that requires.
Booking, scheduling and reservation systems
availability rules, capacity, reminders, cancellations and the calendar integrations around them.
Marketplaces and multi-sided platforms
supply on one side, demand on the other, and the matching, messaging and payout logic in between.
Reporting and analytics tools
heavy queries made fast enough that people actually open the report instead of asking someone to export it.
Progressive web apps
installable to a phone home screen, working offline, with no app-store review standing between you and a release.
Rebuilds of systems that outgrew themselves
a legacy application migrated without losing the data or the business rules buried inside it.
Selected clients in Software Development
8 clients
How the build runs
- Discovery workshop. Two paid days with the people who own the problem. We come out with a scope, a real estimate, an architecture recommendation and a written summary of what we heard — including a recommendation not to build it, where that is the honest answer.
- Architecture and interface design. Screens and data model designed together and reviewed with you before production code is written. Moving a screen at this stage costs hours; moving it after launch costs weeks.
- Two-week iterations. Each one ends in a working demo on a real URL you can click, not a progress percentage. Your project portal shows what shipped, what is next and what is blocked, continuously.
- Hardening and launch. Load testing, security review, monitoring, alerting, backups with a tested restore, and a rollback plan. Then a launch that is boring on purpose.
- Support and iteration. An agreed response time for anything broken, and a standing cadence for the improvements that only become obvious once real users arrive.
What you own at handover
- The full source code, in your own repository, with its commit history intact.
- The infrastructure defined as code, so the environment can be rebuilt from scratch rather than remembered.
- Deployment pipelines, environment variables and secrets, handed over and documented.
- Written technical documentation, plus a recorded walkthrough for whoever maintains it next.
- Administrator accounts, and the ability to add and remove your own users without asking us.
There is no proprietary Codigoo platform you are locked into, and no licence under which ceasing to pay us also means losing your software. If you move the work to another team or in-house, everything they need is already in your hands.
Bilingual from the first screen, not the last sprint
If your users read Arabic and English, that decision has to be made before design starts. Right-to-left layout is not a stylesheet you add at the end — it changes navigation, forms, charts, icons with direction in them, PDF output, and how numbers and dates are written. We build the interface in both directions from the first screen, so the Arabic experience is the same product rather than a mirrored afterthought.
How we choose the technology
We choose deliberately boring, well-supported tools, because a web application is a multi-year decision and the goal is that any competent team can pick it up years from now. In practice that usually means a server-rendered React front end, a typed API behind it, a relational database as the single source of truth, a cache and a queue for work that should not happen while a user waits, and containers so every environment is identical.
What we will not do is pick a framework because it is new, or lock your business logic inside a low-code tool whose pricing and roadmap you do not control. The stack is justified to you during discovery, in writing, in terms of hiring and maintenance rather than fashion.
On working with Codigoo
We had been blaming regulation for two years. They spent a week watching recordings and showed us it was question order.
Questions we are usually asked
- How long will it take?
It depends almost entirely on scope, which is exactly what discovery exists to establish. What we can commit to is that you will see working software within the first few weeks rather than at the end, and that the scope is phased so you can stop after any phase and still have something usable.
- Can you take over an application someone else built?
Often, yes. It starts with a paid technical audit: we read the code, the infrastructure and the tests, then tell you plainly whether it is worth continuing or whether a staged rebuild will cost less than another year of patching. Both answers happen, and you will get the one that is true.
- What happens when the scope changes mid-build?
It will change — that is normal, and pretending otherwise is how projects go wrong. Changes are priced and scheduled openly against the phase they affect, so you decide what to trade rather than discovering the cost at the end.
- Do we need to be technical to work with you?
No. You need to know your business. We handle the technical decisions and explain them in language you can repeat to your board, which is a fair test of whether we understood them ourselves.
If you have a system in mind — or a spreadsheet, a manual process or an ageing platform that has become a bottleneck — a consultation is the fastest way to find out what building it actually involves.
More in Software Development
All of this discipline- Mobile App DevelopmentNative and cross-platform iOS and Android
- E-Commerce DevelopmentOnline stores built to convert and scale
- Custom Software & Internal ToolsAdmin dashboards and operations tooling
- API & Systems IntegrationConnect ERP, CRM and third-party systems
- AI & AutomationIntelligent workflows and predictive models
- Cloud & DevOpsCI/CD, infrastructure and cloud migration
Talk to us about Web Application Development
Thirty minutes with an engineer and a strategist who do this work — not a sales team. You will get an honest answer about whether it is the right thing to buy, and what it would realistically cost.