Internal tools
Systems for employees that bring cases, tasks, registration, administration, data or internal workflows into one working flow.
Web apps and custom systems
Systems for workflows that do not fit standard software
I build internal systems, client portals, dashboards and other web-based tools for processes, data and administration that your current tools do not handle well.
Typical problems I solve
It rarely starts with a request for a specific technology. It starts with a workflow that takes too much time, lacks overview or does not fit the tools you use today.
- We manage the process in Excel or spreadsheets.
- Employees enter the same information in several places.
- Customers have to contact us for status updates or documents.
- We lack one shared overview of data or cases.
- Administrative tasks are repeated manually every day or week.
- Standard software does not fit our workflow well.
- We have an idea for a digital product but need the first working version.
From problem to possible solution
The name of the solution is secondary. These examples make the categories concrete, but the right solution depends on the workflow and the systems already in place.
“We manage the whole process in Excel.”
Internal system / web app
“Customers keep asking for status updates.”
Client portal
“Management lacks one shared overview.”
Dashboard
“Employees repeat the same administrative steps.”
Workflow system / automation
“We need to bring data and functions together in one place.”
Custom web app
“We have an idea for a digital product.”
MVP / first SaaS release
If the main problem is system-to-system data flow or automation between existing tools, an integration may be more relevant than a new web app. See integrations and automation.
Typical solutions
The same company may need one type of solution or a combination. Scope should follow the problem, not a predefined feature list.
Dashboards
A shared interface when data or processes need to be made clear across several sources or areas of work.
Client portals
Login-based areas where customers can view status, access documents, submit information, communicate or manage their own data.
Read more about client portalsBooking and administration systems
Specialised flows for booking, calendars, capacity, administration, forms and notifications.
Custom systems
When a company's process does not fit naturally into an existing standard product, functions and data can be structured around the actual workflow.
MVP / SaaS
A first working version of a digital product with the core functionality needed to put it into use and define the next release.
Example of implemented system work
A concrete product shows how data, validation, recovery and multiple system components can work together in a solution designed for real operation.
Own product
pgDumpster
pgDumpster is a source-available backup and restore tool for hosted Supabase projects. The project includes work across databases, Storage, Auth, Edge Functions, project configuration, validation and recovery.
View the project- Handles data and configuration across databases, Storage, Auth, Edge Functions and project configuration.
- Implements validation, integrity checks, checkpoints, resume and an explicit recovery flow.
- The release SHA is documented through CI, CodeQL and hosted source-to-target E2E.
- The documented live recovery test produced a terminal coverage result for 55 registered components.
How the solution is structured
A web app is not just a collection of screens. The key decisions concern users, data, workflows and the systems the solution needs to work with.
Users and access
Who should be able to sign in, which roles exist, and who may view or change which data and functions?
Data
Which data should the system handle, where does it come from, who owns it, and how is it related?
Workflows
What happens from start to finish, which statuses and rules exist, and which steps can be automated?
Integrations
Should the solution communicate with a CRM, accounting system, payments, email, calendar or other APIs?
Error handling and operations
Validation, logging, retries and recovery are used where relevant, together with a clear model for deployment and maintenance.
Further development
The solution is structured so new functionality can be added later without unnecessary rewrites of parts that already work.
Technology follows the requirements.
Solutions are typically built with a modern TypeScript-based web stack, database/backend and cloud deployment. The specific choices only make sense after users, data, workflows and integrations have been defined.
Pricing and complexity
Prices are indicative. Two web apps with the same number of views can have very different complexity because functionality, data and integrations drive scope far more than the number of screens.
MVP / first release
DKK 40,000–65,000
A focused first version with the core functionality needed to put the solution into use and validate the next step.
Larger web app
DKK 65,000–120,000
A larger solution with more roles, workflows, data relationships or integrations within a clearly agreed scope.
Platform / more complex solution
DKK 120,000+
Solutions with several user interfaces, advanced flows, many integrations or other requirements that increase technical complexity.
What typically drives complexity
- Number of user roles and permissions
- Data model and relationships
- Number of workflows and business rules
- Integrations and APIs
- Payments and authentication
- File handling and notifications
- Number of user interfaces and admin tools
- Migration of existing data
- Reporting and operational requirements
Process
System development starts with the workflow and a clear first scope — not a long list of technologies.
1
Needs and workflow
We clarify the problem, the current process, users, existing systems and the desired outcome.
2
Scope and technical model
Core functionality, roles, data, integrations, the first release and price are made concrete before development starts.
3
Development
The solution is built iteratively within the agreed scope, focusing on the functionality the workflow actually depends on.
4
Launch and operations
The solution is deployed to production, and operations, maintenance or further development can be agreed as needed.
FAQ
Questions about web apps and custom systems
It depends on functionality and complexity. An MVP or first release is typically DKK 40,000–65,000, a larger web app DKK 65,000–120,000, and more complex platforms typically start from DKK 120,000. The final quote is based on scope.
It cannot be estimated meaningfully from the number of pages or views alone. The timeline depends on workflows, roles, data, integrations and how much is included in the first release, so it is agreed together with the scope.
No. The project can be limited to a first release containing the functionality the workflow actually depends on. Later functionality can be added in subsequent scopes.
Yes. An MVP can be used as the first working release when the goal is to put the core functionality into use before larger further development.
Yes, when the relevant systems provide a usable integration or API. Integration requirements are clarified as part of the scope because they can affect both architecture and price.
Yes. Roles and access can be structured so different user types can only view and change the data and functionality they should have access to.
Yes. The first release can be focused, and the solution can be extended later. The architecture is planned around the agreed scope so new functionality can be added without unnecessary rewrites.
Yes. Operations and maintenance can be agreed as needed after launch, and further development can be agreed separately.
Do you have a process that should work better?
Describe how it works today, what takes time, and what you want to achieve. You do not need to know the technical solution in advance.
Describe your needs