How I work

Clear expectations

My approach works best on projects where expectations are clear from the start.

This doesn't mean everything has to be fixed in detail from day one, but there should be agreement on:

• What is being built
• What is explicitly not part of this phase
• What success looks like

This prevents misunderstandings and makes planning much easier.

Independent and focused

I work independently and take full responsibility for what I build.

This works best when I can focus for longer periods without frequent interruptions. Room for uninterrupted work leads to steady and predictable progress.

Async communication

I prefer to work asynchronously. In practice, this means:

• Most communication happens via email or chat
• Updates are written down and can be read when convenient
• Meetings are kept to a minimum and only used when they clearly add value

Written communication is often more efficient and makes decisions explicit and easier to revisit.

Meetings

Meetings can be valuable, but I prefer to keep them limited to moments when they really add something.

A meeting is useful when:

• A complex decision needs alignment
• Something is quicker to discuss than to write
• Multiple people need to get on the same page at once

Status updates, progress, or quick questions are faster via email or chat.

Quality over speed

I prefer to build well rather than fast. This means:

• Thinking carefully about structure and edge cases upfront
• Avoiding shortcuts that cause problems later
• Being deliberate about technical choices to prevent surprises

This approach may take more time initially, but results in systems that are easier to maintain.

Dealing with change

Change is part of software development.

I'm open to adjustments, as long as we discuss and align on them together. Too many course corrections make it hard to maintain progress.

Who this works for

This approach works best for:

• Projects or phases with clear specifications
• Clients who value clarity and predictability
• Work that calls for thoughtful technical decisions

My approach stems from years of working on long-running projects. The Work page gives a good picture of how this plays out in practice.