How much does it cost?

You get a fixed quote after the feasibility report, not before. The report itself is a paid service, priced at a fraction of what starting the build without it would cost; the first conversation and the scoping are free. I price what I've understood, not what I've guessed.

What if the feasibility report says it's not worth building?

Then it says so, and you've paid for an honest answer instead of a build you didn't need. The report can recommend the full build, a leaner version, or a different approach entirely; that's exactly why it comes before you commit, so the decision is yours to make with the facts in hand.

Who owns the code, the IP, and the domain?

You do. The domain is registered in your name from day one, not mine, and the repository, the documentation, and the deployment sit in your own accounts too. You own all of the code and the intellectual property in what I deliver; I keep only the general practices, patterns, and know-how behind it, plus the right to show the work in my portfolio unless we've agreed otherwise.

You're one person. What happens if you're unavailable?

Yes, it's me, and that's deliberate: you deal directly with the person who designs and builds your system, not a rotating team. You're never dependent on me to keep it running, though, everything I deliver runs on a standard, documented stack any competent developer can pick up, with the repository, deployment, and domain in your own accounts. If I'm ever unavailable mid-project, the work is kept in a documented state another developer, or you, can carry on from.

What's your stack, and why?

My default stack is Vue and Nuxt on the front end, server-rendered; a Hono monolith in TypeScript on the back end; Prisma for data; Cloudflare for hosting and infrastructure. TypeScript end to end, so the same types travel from the database to the browser. I work in React as well; Vue and Nuxt are my default.

Do you do maintenance after launch?

Yes: maintenance, documentation, and assessing or untangling existing systems. Assessment and roadmapping is where I'm strongest, and deeper legacy work is scoped for what the codebase actually is, so you get a real plan rather than a blanket promise.

How do changes and new requirements work?

A change to the requirements mid-build doesn't quietly stretch the scope or the bill. It goes on the record for the next version as an explicit decision you make, so nothing about the cost or the timing catches you off guard.

Do you take over an existing project, or only greenfield?

Yes, I take over existing systems, and I start by assessing what's there and giving you a written roadmap before I touch anything. The same feasibility-first approach: understand it, then act.

A few things. Payments never run through a homemade system: they go through Stripe or Mollie, so an established processor carries the compliance and fraud risk. And some work sits outside what I take on entirely, from mechatronics production code to data science, big data, financial-services software, and standalone security audits.

Is what you build secure?

Security is built into how I work, and I back it in practice: an OWASP-aware review posture as I build, and anything security-critical routed to the providers built for it rather than a homemade answer. Card payments run through Stripe or Mollie, so a PCI-compliant processor carries fraud and compliance. Where a project needs a formal, standalone security audit, that's a specialist service, and I'll point you to the right people for it.

FAQ · Full-Stag Digital

FAQ

The questions I get asked before a project, answered plainly: cost, ownership, availability, technology, and where the boundaries are.

SEC.09// 12 questions

How much does it cost?
You get a fixed quote after the feasibility report, not before. The report itself is a paid service, priced at a fraction of what starting the build without it would cost; the first conversation and the scoping are free. I price what I've understood, not what I've guessed.
source: How I work · step 04
What if the feasibility report says it's not worth building?
Then it says so, and you've paid for an honest answer instead of a build you didn't need. The report can recommend the full build, a leaner version, or a different approach entirely; that's exactly why it comes before you commit, so the decision is yours to make with the facts in hand.
source: How I work · step 03
Who owns the code, the IP, and the domain?
You do. The domain is registered in your name from day one, not mine, and the repository, the documentation, and the deployment sit in your own accounts too. You own all of the code and the intellectual property in what I deliver; I keep only the general practices, patterns, and know-how behind it, plus the right to show the work in my portfolio unless we've agreed otherwise.
source: Services · 04 Get online
You're one person. What happens if you're unavailable?
Yes, it's me, and that's deliberate: you deal directly with the person who designs and builds your system, not a rotating team. You're never dependent on me to keep it running, though, everything I deliver runs on a standard, documented stack any competent developer can pick up, with the repository, deployment, and domain in your own accounts. If I'm ever unavailable mid-project, the work is kept in a documented state another developer, or you, can carry on from.
What's your stack, and why?
My default stack is Vue and Nuxt on the front end, server-rendered; a Hono monolith in TypeScript on the back end; Prisma for data; Cloudflare for hosting and infrastructure. TypeScript end to end, so the same types travel from the database to the browser. I work in React as well; Vue and Nuxt are my default.
Do you do maintenance after launch?
Yes: maintenance, documentation, and assessing or untangling existing systems. Assessment and roadmapping is where I'm strongest, and deeper legacy work is scoped for what the codebase actually is, so you get a real plan rather than a blanket promise.
How long does a project take?
[ answer on its way: I write these myself ]
How do changes and new requirements work?
A change to the requirements mid-build doesn't quietly stretch the scope or the bill. It goes on the record for the next version as an explicit decision you make, so nothing about the cost or the timing catches you off guard.
source: stated commitment, no ledger exists yet
Do you take over an existing project, or only greenfield?
Yes, I take over existing systems, and I start by assessing what's there and giving you a written roadmap before I touch anything. The same feasibility-first approach: understand it, then act.
Where are you, and do you work remotely?
Eindhoven, Netherlands.
What don't you do?
A few things. Payments never run through a homemade system: they go through Stripe or Mollie, so an established processor carries the compliance and fraud risk. And some work sits outside what I take on entirely, from mechatronics production code to data science, big data, financial-services software, and standalone security audits.
source: Fit · what I don't take on
Is what you build secure?
Security is built into how I work, and I back it in practice: an OWASP-aware review posture as I build, and anything security-critical routed to the providers built for it rather than a homemade answer. Card payments run through Stripe or Mollie, so a PCI-compliant processor carries fraud and compliance. Where a project needs a formal, standalone security audit, that's a specialist service, and I'll point you to the right people for it.
source: service tradeoffs

Tell me what you want to build. I'll find the way that fits your business.

The first conversation is free and in plain words. Then a paid feasibility report gives you the direction, the honest cost, and the right way forward, so you commit with confidence. source: How I work · step 03

Start the conversation

FAQ