Applications and portals
Custom web applications: do you have a process a template cannot hold?
I develop web applications, client portals, booking systems and custom integrations. The design always starts from the process and the data, not from a list of screens.
A web application is born where a website stops being a presentation and becomes a working tool. A customer places an order, a client tracks the state of their data, an employee processes requests, and the system talks to invoicing, stock or an external API. Such a project cannot be assembled from a ready-made template. It needs a data model that survives real processes, clear permissions, predictable error handling and a safe way to deploy changes. That is exactly where a process-driven application differs from a page that merely looks like one.
I have developed applications and PHP systems for 19 years, including B2B portals, multi-tenant platforms, conference registration systems, subscription portals and e-invoicing systems. On the frontend I work with modern tools, on the backend most often with Laravel, or as a lean API depending on the task. I am a freelance developer based in Poprad, working remote-first. Throughout the project the client speaks directly with the person who designs the architecture and writes the code. Before development starts we walk through the process, the data and the edge cases together, so the estimate and the stage plan rest on concrete facts rather than assumptions.
01
From process to data model
The first question is not which screens you want, but who creates which data, who may change it and what happens on failure. Entities, relationships, state transitions and rules grow from the answers. A booking system must prevent double occupancy of a slot, an order process must stay consistent when a submission is repeated, a client area must isolate each customer's data. Good modelling limits the exceptions that would otherwise appear only in production and creates a foundation that can be tested and extended.
- Processes and states before screens
- Roles and data ownership
- Predictable error handling
02
Portals, client areas and booking systems
The most requested applications are client areas with documents and order status, booking systems with calendars and capacities, internal team tools and multi-company portals. Each of them involves login and access recovery, role-based permissions, change history and a clear listing of the data users work with daily. I design the interface for the person who will use it repeatedly, not for a presentation in a meeting.
- Client areas and documents
- Bookings with capacities
- Internal team tools
03
Integrations that survive reality
An application rarely stands alone. It connects to a payment gateway, invoicing, stock, CRM or a partner API that occasionally times out or returns an error. I design integrations so they can safely retry an operation, record its state and alert an administrator when something failed. A repeated submission must never create a second invoice or order. These details are invisible in a demo, but they decide whether the system still works in its second year of operation.
- APIs and data transformations
- Safe retries of operations
- Logs the support team can use
04
Technology chosen by the task
On the backend I most often build with Laravel, where I rely on a proven ecosystem for authentication, queues, scheduled jobs and testing. For the frontend I use React where interactivity and fast data updates on screen matter. For smaller processes a server-rendered application without unnecessary complexity is enough. I always choose technology by the nature of the task, the cost of maintenance and the capabilities of the team taking the project over, not by current hype.
- Laravel backend with tests
- React for interactive interfaces
- No unnecessary complexity
05
Estimate, stages and takeover
I price a custom application after analysing the process, not by counting screens. I work at €40 per hour including VAT and divide each project into stages with independently verifiable results, so the first usable part can go live before the whole plan is finished. I take over unfinished projects the same way: first an audit of versions, migrations and deployment, then stabilisation, and only then new features. Code, access and documentation belong to the project, not to the supplier.
- An estimate based on process analysis
- Stages with verifiable output
- Handover without lock-in
?
Common questions about web applications
How much does a custom web application cost?
The price depends on the number of roles, data model complexity and integrations. I work at €40 per hour including VAT and after the initial analysis I split the project into stages, each with its own estimate. A small module and a full portal therefore have no meaningful shared price.
Laravel or WordPress for an application?
WordPress is enough when content and e-commerce form the core. A custom Laravel application makes sense with logged-in users, complex permissions, workflows and integrations. A combination often works: WordPress as the public site and a custom application as the process core.
How long does application development take?
A smaller module takes days, a larger portal weeks to months. I divide the work into stages, so the first usable part usually goes live before the full scope is complete.
Can you take over an unfinished application?
Yes. I review framework versions, dependencies, database migrations, tests and deployment. I first stabilise the critical spots and only then propose further development or modernisation.
Will we be able to administer the application ourselves?
Yes. I prepare an admin interface proportionate to what your team actually needs to change. Technical deployment and deeper changes can be handled within ongoing care, while the code and documentation stay yours.
Have a process that deserves its own application?
Describe the users and the main workflow. I will propose a data model, the first stage and a cost frame.
Discuss the application