Customer portals
Self-service for the things your support team answers by email all day: documents, statuses, invoices, requests and account settings.
Applications built the way the web actually works: semantic markup, progressive enhancement, and JavaScript used where it earns its weight. The result loads on a bad connection, works with a keyboard, and is still maintainable next year.
01 — Position
A dashboard that ships two megabytes of JavaScript to render a table is not a technical achievement. It is a decision that someone else will pay for — in load time, in battery, in the cost of every future change.
We start from the platform. HTML that means something, CSS that does the layout, and a framework introduced when genuine interactivity justifies it. When a project does need React or Next.js, we use them properly rather than reflexively — and we say which parts of the page they are responsible for.
This site is a small example: nine pages, no framework, no third-party requests, no cookies, and every asset served from its own domain.
02 — What we build
Self-service for the things your support team answers by email all day: documents, statuses, invoices, requests and account settings.
Tenancy, plans, entitlements, billing integration and per-tenant configuration designed in from the first schema rather than retrofitted.
Dense, fast interfaces for people who look at them all day — server-side aggregation, virtualised tables, and keyboard navigation that works.
A documented component library with tokens, states and accessibility built in, so the tenth screen costs a fraction of the first.
An existing app that has become slow. We profile, measure, fix the real bottleneck and leave a budget in CI so it does not creep back.
Audit against WCAG, a prioritised remediation plan, and the fixes themselves — with automated checks added so regressions get caught.
03 — Delivered
04 — Questions
Yes. If you have a designer or an agency, we implement their work and give them honest feedback on anything that will be slow, inaccessible or expensive to maintain. If you do not, we design the interface ourselves — functional and clean rather than decorative.
Often. We begin with a short paid audit: we read the code, run it, check the dependencies and test coverage, and give you a written assessment of what it would take to continue versus to rebuild. Sometimes the honest answer is that the existing code is fine and only the process around it is broken.
Public pages are server-rendered with real URLs, correct heading structure, canonical tags and structured data. Application pages behind a login are excluded from indexing on purpose. We treat SEO as a consequence of building the page correctly, not as a plugin added afterwards.
An existing app to fix, or an idea on a napkin. Either way you get a written technical opinion, not a brochure.
HALDIR LTD · HE 459882 · Nicosia, Cyprus