Built around users
Real workflows and clear states before decorative UI.
Web Applications
Products for the web
Build powerful web applications.
Scalable, secure and high-performance web applications for real products and real users.
SaaS PlatformsBusiness ToolsMarketplace AppsCustom Web Apps
Start a conversation 
Why it matters
Complex workflows. Clear experiences.
Web applications should make difficult work feel simpler. We balance product logic, interface clarity, performance and room to scale.
Useful data at a glance
Dashboards that make important signals easy to understand.
Secure foundations
Privacy-aware patterns and maintainable architecture.
Designed to scale
Reusable components and flexible product structure.
Ways we can help
Designed around the work.
Start with the outcome. Then shape the right experience, tools and technical foundation around it.
Discuss a project
Subscription and SaaS products
Subscription products with account management, plans, role-aware workspaces, billing integration and operational visibility.
Internal operations tools
Internal workflows that connect requests, approvals, records, reporting and hand-offs without fragile spreadsheet chains.
Marketplace and member platforms
Searchable listings, profiles, transaction states, moderation, messaging and trust-related controls for multiple user groups.
Custom business workflows
Purpose-built tools that model a specific business process, including validation, exception handling and auditability.
What sits beneath the surface
A web app is a working system, not just a dashboard.
Web applications connect people, data and operations. The interface is only one layer: permissions, state transitions, error recovery, integrations and data integrity determine whether the product holds up in daily use.
Workflows and product logic
Model the real sequence of work: who starts it, what information is needed, what changes state, what can fail and how a person resumes. Make primary paths efficient and exceptions understandable.
Roles, accounts and permissions
Design sign-in, account recovery, invitations, organisations, teams, role-based access, session expiry and administrative controls. Keep permissions enforced by the backend rather than trusting interface hiding alone.
Data models and APIs
Shape entities, relationships, validation rules, pagination, filtering and API contracts around the domain. Keep data consistent across the UI, server and connected services, and make failures explicit.
Dashboards and decision support
Present status, trends, exceptions and next actions instead of visual noise. Give charts context, define metrics clearly and provide useful empty, loading, partial-data and error states.
Integrations and automation
Connect payment, identity, messaging, storage, reporting or internal services when there is a clear need. Plan retries, idempotency, rate limits, audit trails and human review for consequential actions.
Reliability and scale
Separate application concerns, monitor critical flows, protect sensitive data, test access boundaries and plan for load. Scale architecture to actual product needs instead of adding infrastructure without a reason.
A considered process
How we turn a business process into a reliable web application.
The sequence moves from domain understanding to an operating product. Decisions are validated early so expensive changes to data and permissions are not discovered at the end.
Map the domain and users
Document user roles, jobs, records, business rules, approvals, exceptions, data sensitivity and the outcomes the system must support.
Output: domain brief, user roles and workflow map.Specify requirements and boundaries
Define permissions, acceptance criteria, integrations, retention, non-functional needs and what must remain outside the first release.
Output: scoped requirements and risk register.Model data and state
Define entities, relationships, state transitions, validation, ownership, audit needs and API contracts before locking the interface to assumptions.
Output: domain model, state map and API specification.Prototype the important work
Test the highest-value user journeys, forms, tables, search, permissions-aware screens, empty states and exception paths using realistic data.
Output: validated interaction model and UI system.Build identity and core services
Implement authentication, server-side authorization, core business rules, persistence, migrations, validation and consistent error responses.
Output: secure application foundation.Connect the full workflow
Build client screens, API integration, background jobs, external systems, notifications, billing or reporting only where required by the agreed scope.
Output: end-to-end functional workflows.Test integrity, security and recovery
Exercise role boundaries, repeated requests, concurrent edits, invalid data, external failures, slow connections, restoration and performance at expected load.
Output: test evidence, resolved blockers and operational notes.Deploy and operate responsibly
Release through a controlled process, verify health and critical workflows, assign support ownership, monitor errors and define rollback and follow-up improvements.
Output: release plan, operational runbook and roadmap.Engineering and quality
The layers that make the app dependable.
Architecture should be understandable, testable and proportionate to the product. A small focused app and a multi-tenant SaaS platform need different levels of complexity.
Frontend
Reusable UI, typed contracts where appropriate, forms, state management, accessible interaction and clear loading/error states.
Backend and APIs
Domain rules, validation, authentication, authorization, rate limiting, consistent errors and versioned contracts where needed.
Data and search
Relational or document structures chosen for the use case, migrations, indexing, retention, backups and safe export.
Security
Least-privilege access, secrets management, server-side validation, secure sessions, audit logs and privacy-aware data handling.
Integrations
Webhooks, queues, retries, reconciliation and clear status when an external provider is unavailable.
Observability
Useful logs, health checks, error reporting, performance measurements and recovery runbooks for critical operations.
A deeper look at the discipline
A web application is a product system: people, data, permissions and operations.
Web applications do ongoing work rather than simply publish information. A trustworthy application has a coherent domain model, correct state transitions, safe access boundaries, predictable failure handling and a user interface that makes complex work understandable. We design those layers together so the application remains useful under real operational conditions.
01 / Product logic
Model the work before drawing the dashboard
We identify each user type, task, input, decision, approval, hand-off and exception. A status such as “pending” needs a defined meaning, an owner and a permitted next action. This workflow model becomes the shared reference for product design, API contracts, database rules and test cases; without it, every screen can look polished while different parts of the system disagree.
02 / Identity and data
Make access and data integrity explicit
Authentication establishes who is signed in; authorization determines what that person may read or change. We define roles, organisation boundaries, ownership, validation, retention, audit history and export requirements. Permissions must be enforced by trusted server-side logic, and sensitive operations need clear failure handling. Data structures and migrations are planned to support the actual domain without premature architectural complexity.
03 / Interaction and feedback
Show status, exceptions and next actions
Tables, forms, dashboards, search, filtering and reporting are useful only when they answer a real question. We plan loading, empty, partial, stale, successful and failed states; explain validation; prevent accidental duplicate actions; and make long-running work visible. For operational dashboards, labels, units, time ranges and metric definitions matter as much as visual polish.
04 / Integrations and operation
Design for the days services fail
Third-party systems can time out, send the same event twice or return an ambiguous result. Integration design covers retries, idempotency, reconciliation, timeouts, queues and clear reporting back to the user. Deployment, monitoring, backup/restore, support tooling and rollback are part of product readiness, scaled to the application’s risk and expected usage.
Definition of done
The checks that make an application dependable.
The product is judged by correct work and recoverable failures, not by the number of screens or the sophistication of its architecture.
Permission boundaries
Users cannot access or mutate records outside their authority, including through direct API requests or guessed identifiers.
Data integrity
Validation, transaction boundaries, duplicate requests and concurrent changes preserve consistent and auditable state.
Failure recovery
Timeouts and provider outages produce known statuses, safe retries and clear recovery paths instead of false success.
Security and privacy
Secrets are protected, sensitive data is minimised, sessions are managed carefully and critical actions have appropriate audit trails.
Operational visibility
Logs, health checks, error reporting and alerts help locate issues without exposing secrets or unnecessary personal information.
Performance and continuity
Common tasks remain responsive, larger data sets are handled intentionally, and backup/restore and rollback are rehearsed where required.
Capability map
Design the complete operating logic behind the interface.
Web applications work when the screen, data, permissions and state changes agree. A useful build makes both the main path and the exceptions understandable.
Accounts, roles and organisations
Define sign-in, recovery, invitations, teams, multi-tenant boundaries, role permissions and account administration. Keep authorisation enforced by trusted server-side rules, not only by hidden controls.
Core workflows and state
Map statuses, approvals, hand-offs, dependencies, edits, cancellations and recovery paths. Every state should have a clear meaning, a permitted next action and a useful error response.
Data models and API contracts
Specify entities, relationships, validation, filtering, sorting, pagination, versioning and consistent errors. Protect data integrity when requests repeat, arrive late or conflict.
Search, reporting and real-time views
Make important records findable and operational signals actionable. Define whether updates need to be live, how charts should be interpreted and how large datasets remain responsive.
Integrations, billing and automation
Connect approved external services through explicit contracts, webhooks, retries, idempotency and reconciliation. Treat payments, messaging and automated actions as states that must be verified.
Administration and service operations
Provide appropriate audit trails, permissions management, data export, retention rules, support tools, health signals, error reporting and a safe deployment/rollback plan.
Scope and handover
From product model to a working web system.
A production-minded web application needs deliverables for user experience, domain logic, data and operations—not only a front-end component library.
User and workflow specification
Roles, primary jobs, business rules, state transitions, exceptional cases and acceptance criteria.
Interaction prototype and design system
Navigation, dashboards, forms, tables, search, filters, permissions-aware states and reusable UI patterns.
Domain model and API plan
Data entities, constraints, API schemas, pagination, error contracts, ownership and migration considerations.
Identity and access model
Authentication, sessions, role rules, account recovery, tenant boundaries and administrator workflows.
Integration and operational design
External service contracts, event/retry strategy, logs, metrics, backup/restore and deployment approach.
Verification and handover
Workflow tests, security checks, performance scenarios, operational notes, known constraints and a prioritised backlog.
Questions worth answering
A few practical questions.
Clear expectations make better projects. These answers describe the decisions usually worth making before work begins.
Discuss your requirementsHow is a web app different from a website?
A web app usually manages user-specific data and ongoing workflows, accounts, permissions and state. It therefore needs domain logic, data integrity and operational controls in addition to a clear interface.
Do all web apps need the same architecture?
No. The right architecture depends on users, data sensitivity, integration needs, traffic, team size and expected change. Start with the simplest structure that supports the real requirements safely.
How do you handle third-party integrations?
Define the service contract, credentials, failure states, timeouts, retries, duplicate-event handling and reconciliation. The interface should not report success until the underlying operation is confirmed.
What should be tested before release?
Core workflows, permissions, invalid input, concurrency, API failure, slow connections, large datasets, browser behaviour, backups and security-sensitive operations all deserve planned checks.
Selected directions
Different challenges.
Thoughtful solutions.
Examples of the kinds of experiences and systems that this discipline can make possible.
01 / Selected direction
Operations dashboard
Bring important activity, metrics and next steps into one view.
02 / Selected direction
Connected work platform
Reduce context switching across a team’s everyday tasks.
03 / Selected direction
Insight-led product
Turn complex information into useful decisions.
Have an idea?
Let’s make it
real.
Bring us the ambition, the problem or the rough sketch. We’ll work through the right next step together.
Connect with Black Hole