Contact

Send me the messy version of what you're trying to build or fix.

You do not need a polished brief. A rough description of the problem, the current setup, and what should work better is enough for me to understand whether I can help.

Email the rough brief Check services first

Start with a clear email

Simple scoping

Use the fields below if you want a little structure. It opens an email draft, so you can still edit everything before sending.

Your name Email What is it about? What are we trying to improve?

Use normal email

How to reach me

Direct line

The form is optional structure. Underneath, it is just an email that lands with me, no ticket system and no sales team in between.

1
The message lands with me
No bot and no team sorting requests before I see them.
2
I reply directly
If something is missing context, I ask instead of guessing.
3
You get a concrete answer
Either a suggested next step, or an honest read on whether it is something I can help with.

Emailhello@deskdude.dk
BaseCopenhagen, independent
LanguageDanish or English
Who repliesMalte, personally

Email me directly

What's good to include

A good first message

The best first message is specific, but not overworked. These points are enough to start a real conversation.

1
What are you trying to build or fix?
Give me the practical goal, even if the shape of the solution is not clear yet.
2
What's slowing you down right now?
Mention tools, manual steps, a broken flow, or repeated work that keeps creating friction.
3
What does a good solution look like?
Describe what should be easier, faster, or more stable once the work is done.
4
Who is involved?
Tell me who will use it, who decides, and who needs to understand the result afterwards.
5
What's your timeline?
Share the real constraints. If there's no deadline, that's fine to say too.

How I handle requests

No theatre

Step 1

I read the context first

I look for the real problem behind the request: unclear positioning, manual work, fragile tools, or a system that needs to be simplified.

Step 2

We define the smallest useful scope

The first version should do something concrete. I would rather make one part work properly than turn a loose idea into a bloated project.

Step 3

I map the implementation path

That can mean page structure, automation flow, app scope, data inputs, or the technical decisions that need to be made before the work starts.

Step 4

We review in small loops

You see progress before too much is locked in, and the work stays close to the actual problem instead of drifting into decoration.

Step 5

You get a usable handover

The result should make sense after delivery: what changed, how it works, and what the next useful improvement could be.