Service · 03
Custom web application development.
When the site stops presenting information and starts running an operation: accounts, databases, role-based dashboards, payments, integrations.
The spec comes first
Most failed software in this market failed before anyone wrote code. It was scoped in a meeting, quoted from a guess, and built towards a target nobody had written down. So nothing gets generated here until there is a document that answers six questions:
- Problem — what is actually broken.
- Users — who has to live with it.
- Scope — what is in, and explicitly what is out.
- Data — what the system has to remember.
- Flows — what happens, in what order.
- Done — how we both know it works.
Only then: the stack. Runtime, database, authentication, hosting, admin, and an exit route if you ever want one. Chosen for your constraints rather than for my convenience, and boring wherever boring is cheaper to run.
- React
- React Native
- TypeScript
- Tailwind CSS
- Vite
- Supabase
- PostgreSQL
- Firebase
- Cloudflare
- three.js
What gets built
- Authentication and roles. Who gets in, what each role may see, and what they may change. Enforced on the server, not hidden in the interface.
- A real data model. Designed before the screens, so the system can answer questions you haven’t thought of yet.
- Admin dashboards. For the staff who operate the thing daily — the screens most agencies leave until last and then rush.
- Payments, where money moves: local gateways, receipts, reconciliation, and the failure cases nobody demos.
- Integrations. Existing databases, Microsoft 365, eFaas, SMS, third-party APIs — scoped and named in the spec rather than discovered later.
- Automation and reporting. Scheduled jobs, exports, notifications, and the reports that currently live in somebody’s spreadsheet.
- Security and testing as part of the build, not sold as a separate line item.
The stack, when you want to know
Chosen after the spec, never before it — but for most work it lands on a familiar, deliberately boring set: Next.js and React with TypeScript on the front, Supabase or Postgres behind it, and edge hosting that costs almost nothing to run at Maldivian traffic volumes. Where a client already runs something else and it works, staying there is usually the honest answer and I will say so.
The test is never which technology is fashionable. It is what it costs you every month, who can maintain it after I hand it over, and how you would leave if you ever wanted to.
Government and institutional work
I am building the Mosque Directory for the Ministry of Islamic Affairs and Endowments: every mosque in the country, searchable, on a map, bilingual in Dhivehi and English and right-to-left throughout, with a role-based admin module for ministry staff. What runs today is a demo on sample data. Alongside it the ministry specified a wider system, also in build, as native iOS and Android — prayer times, Qibla, Hijri calendar, offline access and issue reporting.
Institutional work has requirements ordinary commercial work doesn’t: accessibility, bilingual content, audit trails, role separation, and a handover that survives the person who commissioned it moving on. That is a different kind of care, and it is worth asking whoever quotes you whether they have actually done it.
On AI, honestly
Yes, AI writes a lot of the code. No, that is not the part that matters. Code generation is the last step of the process, not the process. The spec, the data model and the architecture are written before anything is generated; knowing what to reject is most of the skill; and nothing ships that I wouldn’t sign.
You can prompt an AI yourself. The difference is knowing what to ask for, what to throw away, and what finished means.
Common questions
What’s the difference between a website and a web application?
A website presents information. A web application runs something: it has accounts, it remembers state, it enforces who may do what, and people use it to get work done rather than to read. If you find yourself describing logins, approvals, statuses or reports, you are describing an application.
Do I need to know what technology to use?
No, and you shouldn’t have to. The stack is chosen after the spec, never before it — based on what it has to run on, what it costs every month, who has to maintain it, and how you would leave if you ever wanted to. Boring wherever boring is cheaper.
Can it integrate with systems we already run?
Usually yes. The Mosque Directory is being built with integration points for the ministry’s own SQL Server, Microsoft 365 and eFaas. Integration is a scoping question — it gets written into the spec and priced, rather than discovered halfway through.
Who owns the code?
You do, on completion, per the terms agreed before the build starts. Source code and repository, admin accounts, hosting and domain access, DNS, credentials and documentation all transfer. Ownership is settled in writing beforehand, not argued about afterwards.
What does it cost to run each month?
Quoted before the build begins, itemised by name: hosting, database, metered APIs, file storage, domain. Nothing recurring appears later as a surprise. See the pricing page for how running costs are presented.