FAQ

08
FAQ

The questions I get asked before a project: cost, ownership, availability, the stack, and what I don't do. Always visible, never behind an accordion; an answer I haven't designated yet shows as a pending slot.

  • 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.

    src: 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 is a paid service either way, priced at a fraction of what starting the build without it would cost, and it can recommend against the project, a smaller version, or a different approach. That's the point of doing it before you commit to the build.

    src: 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. On a standard, documented stack, nothing ties you to me.

    [ code & IP ownership terms: pending ]

    src: Services · 04 Get online
  • You're one person. What happens if you're unavailable?

    It's just me, so I build so you're never dependent on me. Everything I deliver runs on a standard stack and comes documented, so it stays legible to any competent developer, not locked to the one who wrote it. An active project pauses if I'm out, it doesn't die, because the written feasibility report and the agreed scope let someone else carry it on. Diagnosing that exact single-maintainer risk is part of what I advise other companies on, so I make a point of not handing you a system that recreates it.

    [ formal continuity arrangement (a named backup, a handover protocol, an escrow): pending ]

  • 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 also work in React and am consolidating on Vue.

  • Do you do maintenance after launch?

    Yes: maintenance, documentation, and assessing or untangling existing systems. My proven strength there is assessment and roadmapping; I scope deeper legacy work honestly rather than promising to fix anything on any stack.

    [ terms (retainer / ad-hoc / handover-only): pending ]

  • How long does a project take?

    [ answer pending: authored by the operator, not generated ]

  • 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.

    src: 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.

    [ remote-work posture: pending ]

  • What don't you do?

    I don't hand-roll payment handling (it goes through Stripe or Mollie so a processor carries PCI and fraud); I don't start UI before the data model is defined.

    [ additional exclusions: pending ]

    src: service tradeoffs
  • Is what you build secure?

    Security is part of the work, and I state it as principle rather than a promise I can't stand behind. Security-critical handling stays with specialists instead of a homemade system: card payments run through Stripe or Mollie, so a PCI-compliant processor carries fraud and compliance. And I build on a standard, documented stack rather than a bespoke black box only I understand, so your system stays reviewable by any competent developer. What I won't do is claim blanket security implementations, like encryption-at-rest, daily backups, or a formal certification, that aren't genuinely part of your project.

    [ my specific security-review posture (what I assess, and how): pending ]

    src: service tradeoffs

Not sure it's even possible? That's what the first conversation is for.

You get a written feasibility report and an honest cost before you commit to the build. src: How I work · step 03