Web applications with accounts, roles, workflows and data, not just pages.
Thalenor develops custom web applications: customer portals, admin dashboards, SaaS products, booking platforms and internal tools that run in the browser and connect to real data.
What is the difference between a website and a web application?
A website presents information to visitors: services, proof, contact. A web application lets signed-in users do work: create records, manage orders, approve requests, see dashboards, collaborate. Web applications need authentication, roles and permissions, a database, an API and careful interface design for repeated daily use.
Each with a different interface logic.
Customer portals
Self-service accounts: documents, status, requests, payments.
Internal operations tools
Dense tables, filters, bulk actions, audit trails, roles.
SaaS products
Multi-tenant architecture, billing, onboarding, admin.
Booking and scheduling systems
Availability, confirmations, reminders, calendar sync.
Analytics and reporting platforms
Dashboards, drill-downs, scheduled exports, permissions on data.
A client portal request, from login to resolution.
Illustrative portal for a professional firm. Roles decide what each person sees; the audit trail shows what happened.
- 14:02Client signs in and opens 'Documents'. Sees only their own matters.
- 14:05Uploads a signed agreement and raises a request: 'Please confirm receipt.'
- 14:05Request routed to the matter owner; notification sent; SLA timer started.
- 15:30Associate reviews, adds an internal note (invisible to client) and replies.
- 15:31Activity logged; client sees the reply and the document status 'Received'.
Permissions are enforced by the API, not just hidden in the interface.
The client's session expires mid-upload.
The upload resumes after re-authentication; nothing is lost.
The interface explains what happened rather than failing silently.
Expired sessions cannot be reused; the event is logged.
The browser is the most practical place to run a business tool.
No installs, works on every device, one version for everyone. Most internal systems, portals and SaaS products belong here.
What every serious web app needs.
Authentication
Secure sign-in, sessions, password reset, optional SSO.
Roles and permissions
Who can see and change what, enforced on the server.
Data model and API
A schema that matches the business, exposed cleanly.
Interface
Fast, accessible, designed for repeated use.
Operations
Monitoring, backups, deployment pipeline.
What a web application needs underneath.
Explained plainly: each layer answers a question a buyer should ask.
For SaaS: tenant isolation at the data layer, per-workspace roles and billing.
Pagination, indexing and caching where volume demands it.
Pipeline, staging environment, rollbacks.
Straight answers to the questions that decide a project.
- Enforce permissions only in the interface.
- Build a mobile app when a responsive web application meets the requirement.
- Skip staging and monitoring to launch a week earlier.
Website or web app?
If visitors read, it is a website. If users sign in and do work, it is a web application. Many businesses need both, connected.
Can it grow into a SaaS product?
Yes, if it is designed with tenancy and billing in mind from the start. We ask early.
What about mobile?
Responsive first. A native app only when device features or offline use justify it.
How do you handle permissions?
Role-based access enforced by the API, with an audit trail of who changed what.
Can it integrate with our CRM and accounting?
Usually, through APIs. Integration points are designed as adapters so providers can change.
Questions worth asking first.
Yes. Responsive design covers most needs. If offline use or device features are essential, a mobile app may be justified; we will say which.
Describe what your users need to do.
Roles, tasks and the data they touch. From that we can shape the application and a realistic first release.