Disclosure: Tristan runs Cards4, TeeTrack, Sandglass, holy-mail.de, holyco.de, and this site’s optional TeeTrack analytics. No outside-vendor payments or commissions. Editorial method →
Choose a senior freelancer for a focused scope with direct technical ownership. Consider an agency when your brief needs several disciplines or parallel delivery. Compare capacity, responsibilities, and handover before choosing a name.
Written by freelance developer Tristan Döhl. The decision guide applies to your brief; holy-mail.de is his own service and is shown as a disclosed example.
START WITH THE WORK, THEN THE TEAM.✳LET'S LOOK AT THE WORK.
01 / PICK YOUR WAY TO BUILD
How do freelancers, agencies, and DIY compare?
Compare the engagement models before comparing individual providers. The right choice depends on how much parallel work you need, who makes technical decisions, and who supports the result.
On a small screen, scroll sideways to see all three options.
Our editorial guide to choosing a software development approach
One primary developer owns implementation. Ask about availability, backup arrangements, and how decisions are reviewed.
Choose this route when you need a team. Ask who will implement, review, and maintain the work.
You own the architecture, review, testing, and maintenance, including any generated code.
What needs doing?
A focused build, specialist change, or incremental modernization with a scope that fits one person’s capacity.
Useful to explore when design, engineering, and other disciplines need to run in parallel.
A route we'd consider for learning, experiments, or a small project you can support yourself.
What can you inspect?
Request examples close to your problem and discuss the actual decisions, constraints, and handover.
Request relevant case studies and meet the people assigned to your project.
Make a prototype, then check whether you can explain, test, and operate what you've built.
What should you agree?
Scope, reserved capacity, review, ownership of the code, documentation, and support after delivery.
Team allocation, responsibilities, delivery milestones, and support after handover.
Your time budget, hosting costs, security responsibilities, and when to bring in help.
These are engagement tradeoffs, not guarantees about any provider. Ask an agency which people will actually work on the project, a freelancer how capacity and absence are handled, and yourself whether you can maintain a DIY result. Compare written scopes with the same acceptance criteria.
BEFORE YOU ASK FOR A QUOTE
What should you compare in a proposal?
Give each candidate the same problem, users, existing stack, desired outcome, timeline, and constraints. Ask for deliverables and assumptions before comparing prices. A day rate alone does not tell you how much work, review, or support a proposal includes.
Scope and acceptance. Define the result you can check, the milestones, and the work outside the proposal. Agree how changes to that scope are handled.
Capacity and continuity. Ask for the people assigned, their reserved time, and the plan for absence or substitution. Check capacity against the deadline.
Relevant evidence. Walk through a similar problem, the technical decisions, and what the provider would do differently. A client logo alone does not explain their role.
Communication and review. Agree who makes product decisions, who reviews the work, and how progress is demonstrated. Put review time into the plan.
Handover and maintenance. Clarify code ownership, repository access, documentation, operating instructions, and responsibility for fixes after delivery.
The whole budget. Include discovery, coordination, licenses, hosting, and ongoing support. Compare proposals against the same responsibilities and acceptance criteria.
Choose the freelancer or team whose proposal fits those answers. If the brief needs parallel specialists, compare agency staffing plans. If one senior operator can own it, compare focused freelance engagements.
02 / A DISCLOSED FREELANCER EXAMPLE
Which published projects show the author’s work?
Here is how you could assess a solo provider’s portfolio. These examples are from the author’s own holy-mail.de service; the outcomes are self-reported and do not predict your project’s results.
01
DKMS / MODERNIZATION
Make the existing thing better.
His DKMS case study reports migrating more than 50,000 lines of JavaScript to TypeScript and reaching 95% test coverage, alongside ongoing feature work. We like that combination: improve the foundations and keep the product moving.
The Ribbon Home account connects an onboarding rebuild with GraphQL APIs and Docker deployment improvements. That's what catches our eye: attention to both the experience people use and the systems that deliver it.
At his startup, Tristan describes building the machine-control software, operator desktop app, and backend for CNC welding robots, with more than ten productive units delivered. React, Electron, Elixir, and Phoenix all appear in the story. Consider our attention thoroughly earned.
Project outcomes above are reported by holy-mail.de. Follow the case studies for their context, scope, and technical details.
03 / WAIT, WE KNOW THOSE TABS
Build it. Run it. Care about it.
Tristan's projects page lists TeeTrack and Sandglass as products he founded, builds, and operates. Both already have a spot in our little hall of excellent links. [5]
TEETRACK.IT
For the hours you put in.
Time tracking, billing, and invoicing for freelancers and small teams, according to his product overview.
Consider a team when design, engineering, testing, and coordination need to happen in parallel. Ask who is assigned, how substitutions work, and who owns delivery. A company name alone does not establish capacity.
When should I prefer a freelancer?
Consider a senior freelancer when the work can fit a focused engagement and direct communication matters. Discuss capacity, reviews, time off, and what happens if the scope grows beyond one person.
What should every proposal cover?
Agree deliverables, acceptance criteria, milestones, access, code ownership, documentation, support, and a handover. Compare the total scope and responsibilities rather than a day rate alone.
A NEXT STEP / IF A SOLO ENGAGEMENT FITS
A focused project? Discuss the scope.
If the freelance model fits your brief, holy-mail.de is the author’s own senior development service. Use the same scope and handover questions when evaluating it alongside other providers.
Based on holy-mail.de's published pages, checked . The recommendation is editorial; portfolio outcomes are self-reported. Check the current service details directly with Tristan.