Everything you need to know before we start.
How I structure engagements, what you receive when we're done, and what happens after launch.
Engagement types
I work in two ways, depending on what fits the project. Both start with a short scoping call, and that call commits you to nothing.
Scope-first projects
Best for well-defined work: a new feature, a redesign, a full product build. We settle scope, timeline, and price before I write any code, so you know what you're getting and what it costs.
Ongoing work
Best for teams that need a reliable senior pair of hands on complex or shifting work. Billed weekly, cancel with a week's notice. Rate on request (see the contact section on the main site).
I take on one or two clients at a time, so you get real attention rather than a place in a queue. Most projects have a two to four week lead time from first email to kick-off.
What you receive
A project ends with a real handover, not just a link to a running site. Here's what comes as standard.
Code & access
- Full source code in a private Git repository
- Production deployment on your own infrastructure
- Every credential and environment variable documented
- Storage, backups, and queue workers set up
Documentation
- Architecture overview: what it is and why it's built that way
- A run book covering deploy, update, and rollback
- Environment variable reference with safe defaults
- A recorded walkthrough if your team is non-technical
- ✓Database schema with full migration history, so there are no manual SQL scripts to run
- ✓Automated tests covering the critical paths
- ✓A CI/CD pipeline (GitHub Actions or equivalent)
- ✓A staging environment that matches production
- ✓Basic monitoring: an uptime check and error alerting
Tech defaults
These are my defaults. If your team already runs on something, or has strong preferences, we sort that out in the scoping call. I'm not precious about the stack.
Back-end
- PHP 8.x
- Laravel
- REST APIs
- MySQL
Front-end
- Vue.js 3
- TypeScript
- Modern JavaScript
- Inertia.js
- Tailwind CSS
Tooling
- Git
- Vite
- Scrum / Agile
- Linux
What I do avoid is anything that hides complexity or makes the code hard to hand off. A competent senior developer who has never seen the project should be able to read it and get to work.
Revisions & feedback
Feedback is part of how I build, not a step tacked on at the end. Here's how the rounds work.
Design & architecture review
Before I write code, you get a short document covering the technical approach, the data model, and any open questions. We agree on the plan first, which saves a lot of rework later.
A staging link that's always live
You have a staging environment from day one, so you watch the work take shape instead of waiting for one big reveal at the end.
Two rounds of UI revisions
Fixed-price projects include two consolidated feedback rounds on the final UI. Consolidated means you gather all the notes and send them in one pass, not one at a time. Scope changes are quoted on their own.
Bug fixes at no charge
Anything that doesn't match the agreed spec gets fixed for free within the support window. Changed requirements are a new scope item.
After launch
Every project comes with a 30-day support window. During it I'm on hand for bug fixes, small adjustments, and questions about the handover.
Included in every project
- 30 days of bug-fix support
- Patch-level dependency updates
- A handover call with your team
- Email access for questions during the window
Available on a retainer
- Ongoing feature development
- Security and major-version upgrades
- Performance monitoring and tuning
- On-call availability (quoted separately)
I'm not a hosting company. You get full control and there's no lock-in. If you decide to carry on with someone else, I'll make that handover as painless as I can.
Contract & intellectual property
Every engagement runs on a written contract, signed before any work starts.
Standard contract terms
I use a plain-Dutch freelance agreement based on the FNV model contract, adapted for software projects. It covers scope, deliverables, timeline, payment, and liability. You get the draft to read and mark up before signing, and there's no pressure to accept the first version.
An NDA is available on request and adds no time to the project start.
Who owns the code
When the final invoice is paid, full intellectual property in the work transfers to you: all source code, design assets, database schemas, and documentation produced during the engagement.
I keep the right to mention the project name and outcome as portfolio work, unless you ask me not to in writing, in which case it stays confidential.
Third-party libraries and open-source components keep their original licences. The contract lists the significant dependencies and their licence types, so you can audit the IP stack whenever you need to.
Payment schedule
I invoice in euros. Amounts are exclusive of VAT (BTW 21%), which is added for Dutch clients.
50% upfront
Invoiced the day the contract is signed. Work starts once it clears, usually one or two business days for a Dutch transfer (iDEAL or SEPA).
50% on handover
Invoiced once the production deployment is live and the handover docs are delivered. Payment terms: 14 days net.
Weekly billing
For ongoing work I invoice every Friday for the time worked that week. Payment terms: 14 days net. Cancel with a week's written notice.
Privacy & data handling
On most projects I end up with access to production databases, credentials, and sometimes personal data belonging to your users. Here's how I treat that.
- ✓I don't keep client credentials past the project. Secrets live in a local encrypted vault and are deleted at handover.
- ✓I don't pull production databases onto my machine unless debugging genuinely needs it, and never without written permission.
- ✓If the work needs access to personal data, we sign a Data Processing Agreement (verwerkersovereenkomst) before that access is granted.
- ✓I'm registered with the Dutch Chamber of Commerce (KVK) and work under Dutch and EU law, including the GDPR / AVG.
- ✓Any tool or subcontractor I use that touches personal data is held to the same agreement.
If your project involves health data, financial data, or any other special-category data under the AVG, mention it in the scoping call so we can agree on how to handle it before work starts.
Working hours & communication
I'm based in the Netherlands (CET/CEST, UTC+1/+2). Most of the day-to-day happens in writing; I prefer written updates over calls for routine things, so there's always a clear record.
I don't promise same-day turnarounds on new features or scope changes; the work is planned. If something is genuinely on fire, tell me and we'll sort it out together.
Getting started
Once we've agreed on scope and signed the contract, here's what I need to start without delay. Most hold-ups come from waiting on access or approvals, so the sooner this list is done, the sooner I can start.
- →A short brief: what you're building, the problem it solves, and who uses it
- →Access to any existing codebase (a GitHub or GitLab invite), if there is one
- →Staging server credentials, or a go-ahead for me to provision one
- →A domain or subdomain for staging (for example
staging.yourproject.nl) - →Any third-party API keys the project depends on (Stripe, Mailgun, and the like)
- →Design files in Figma, or a written brief if there are no designs yet
- →One named contact who can answer product questions and sign off on deliverables
- →The 50% upfront invoice paid; work starts once it clears (see section 07)
Ready to start?
Send a short description of what you're building and I'll get back to you within one business day.
Get in touch →