How I work: daily consulting rate

When I take on consulting work, I charge a flat rate of 480€ per day. This isn't hourly billing where every question costs money, and it's not a fixed project bid where scope creep becomes a problem. It's a straightforward model that's worked well for both me and the teams I've helped.

A day means focused work on your project. It doesn't mean exactly eight hours logged to the minute - some days run longer when we're in flow, others are shorter when we've accomplished what we set out to do. What it means is that for that day, your project has my full attention.

What a consulting day includes

When you engage me for a day, you're getting:

Technical work. Writing code, refactoring existing systems, reviewing architecture, debugging issues, setting up infrastructure. The actual engineering work that moves your project forward.

Direct communication. I'm available throughout the day for questions, discussions, and real-time problem solving. Whether that's a quick Slack message or a longer call to work through a design decision, it's included.

Documentation where it matters. When I work on your codebase, I document the decisions that need documenting - useful notes that help your team understand what was done and why, not pages of process documents nobody will read.

Knowledge transfer. I work with your team, not in isolation. When I implement a pattern or solve a problem, I make sure the relevant people understand it well enough to maintain and extend it.

Why this rate

480€ per day reflects the experience and value I bring to technical problems. I've been building backend systems since 2009, primarily with Laravel and Symfony. I maintain open source packages with hundreds of thousands of downloads. I've worked with startups, agencies, and established companies across Europe and beyond.

More importantly, a senior engineer who knows what they're doing can often accomplish in a day what would take a less experienced developer much longer - not just in terms of typing speed, but in avoiding dead ends, making better architectural decisions, and writing code that won't need to be rewritten later.

The daily rate also keeps things simple. There's no negotiation about how many hours something took, no invoices with line items for every conversation, no incentive for either of us to game the system. One day of work, one price.

How engagements work

Most engagements start with a conversation. You describe what you're dealing with, I ask questions to understand the situation, and we figure out whether I can actually help. This initial discussion doesn't cost anything - I'm not going to charge you just to find out if we're a good fit.

If it makes sense to work together, we agree on scope and schedule. For shorter engagements - say, a code review, architectural assessment, or specific feature implementation - we might book a few days over a week or two. For larger projects, a monthly collaboration often makes more sense.

Once we start, I prefer to work in focused blocks rather than scattered hours. A full day of concentrated work produces better results than the same hours spread across a week. For remote work (which most of my engagements are), I'm typically available during European business hours, though I can accommodate other time zones when needed.

Payment terms are straightforward: invoiced monthly or at the end of shorter engagements, due within 14 days. For new clients, I usually ask for partial payment upfront for the first engagement, after which we can work on standard invoicing.

What I don't do

Being clear about what I don't offer helps avoid misunderstandings:

I don't do fixed-price projects. Software development is inherently uncertain, and fixed pricing creates bad incentives on both sides. The daily rate lets us adjust scope as we learn more about what's actually needed.

I don't work for equity alone. While I'm open to hybrid arrangements for the right project, I don't take on work purely for potential future value. The daily rate is for actual work, paid in actual money.

I don't pretend to know everything. My expertise is backend engineering, particularly PHP with Laravel and Symfony. If your needs are primarily frontend, mobile, or in a technology stack I don't specialize in, I'll tell you - and probably recommend someone better suited.

I don't disappear after delivery. Engagements have a defined scope, but I'm not going to leave you stuck if something comes up right after we finish. Reasonable follow-up questions are part of the deal.

Getting started

If you have a technical challenge that might benefit from senior engineering help, let's talk. The initial conversation is free and typically gives us both enough information to decide whether working together makes sense.

For sustained work - building features over months, ongoing architecture guidance, or embedded team support - you might want to look at my monthly collaboration options, which offer better rates for longer commitments.

Either way, reach out and tell me what you're working on. If I can help, I'll say so. If I can't, I'll try to point you in the right direction.