Contact

Send me the messy version of what you are 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

plain scope

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 Service interest What are we trying to improve?

Use normal email

What to include

useful 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 is slowing you down?
Mention the tools, manual steps, broken flow, unclear page, or repeated work that keeps creating friction.
3
What does success look like?
Describe what should be easier, faster, clearer, or more reliable when 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 is your target timeline?
Share any real constraints. If there is no deadline, say that too.

Clear context helps me reply faster Best format: plain email, links, screenshots, rough notes

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, missing structure, 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, access needs, or the technical decisions required before building.

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 handoff

The result should be understandable after delivery: what changed, how it works, what to watch, and what the next useful improvement would be.