FAQ

05
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 — 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 can recommend against the project, a smaller version, or a different approach — that's the point of doing it before you commit.

    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.

    [ 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 not dependent on me. Your code is yours, documented, and on a standard stack — any competent developer can pick it up; there's no bespoke system only I understand and no lock-in to me. An active project pauses if I'm out, it doesn't die: the written feasibility report and scope mean the work can be continued by someone else. And I diagnose single-maintainer risk professionally — it's exactly what I advise other companies on — so I don't hand you a system that recreates it.

  • What's your stack, and why?

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

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

    Requirement changes go to a ledger for the next version instead of silently expanding scope and cost. You always know what you're paying for and when it lands.

    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

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 anything. src: How I work · step 03

Start the conversation