Mathias / MKP Digital

My name is Mathias Kjær Pedersen and I run MKP Digital from the Aarhus area. MKP Digital is a one-person studio, so you work directly with the person designing and building the solution.

I work with websites, web apps and integrations for businesses and organisations. The technical field is broad, but the collaboration model is simple: no project managers or other middlemen between you and the person actually building the solution.

Professional background

I am a qualified data technician specialising in infrastructure, with 11 years of professional experience across IT, operations, production and web.

That background means I am used to seeing a digital project as more than what appears in the browser. How the solution is deployed, which systems it depends on and how it operates after launch are part of the technical assessment when the project requires it.

View projects

What that background means for your project

A digital project is not assessed only by what the user can see in the browser. When the solution requires it, deployment, access, data, error handling and operation are considered as part of the solution rather than after launch.

More than the visual layer

A solution is also judged by how it is deployed, maintained and operated in production. Where relevant, hosting, databases and technical dependencies are considered from the start.

Data and access are part of the design

If a solution handles users or data, access boundaries and the data model are treated as part of the solution rather than something added afterwards.

Failure is part of system design

External systems can be unavailable, input can be invalid and processes can fail. When the project requires it, error handling and logging are designed explicitly.

Built with operation in mind

A solution should not only be launchable. Where continued operation or data makes it relevant, maintenance, updates and backup/recovery are part of the technical considerations.

How I work

These principles describe the collaboration and technical decisions rather than another process timeline.

Direct contact

You work directly with the person designing and implementing the solution. There is no project manager between you and the developer translating your requirements first.

Clear scope

Before substantial development starts, there should be a shared understanding of what will be built, what is excluded, relevant dependencies, price and expectations. If the scope changes, that change should be communicated clearly.

No unnecessary complexity

The solution should not be larger or more advanced than the problem requires. If a simple website or an existing system solves the need better than custom development, that is the relevant solution.

Technical problems are communicated directly

Platform limitations, API constraints, technical debt, uncertainty and trade-offs should be made clear when they matter to the project.

Operation is considered where relevant

If the solution requires ongoing technical operation, that is included in the technical decisions from the start. This does not mean every client needs an operations agreement.