How I work

02
How I work

Four steps from your problem to a built thing, and what you hold after each one. You get a written feasibility report and an honest cost before you commit to the build.

  1. 01: Interview

    Your problem, in your words. No jargon, no forms: a conversation to understand what you actually need.

    Outcome
    Your problem, stated in plain words we both agree on.

    Fig.01Interview

  2. 02: Investigation

    I dig into the specifics: what exists, what's feasible, and where the real cost and risk sit.

    Outcome
    A clear picture of what's feasible and where the real cost and risk sit.

    Fig.02Investigation

  3. 03: Feasibility report

    A written recommendation: the direction I'd take, what it involves, and an honest cost. A paid service, priced at a fraction of what starting the build without it would cost.

    Outcome
    A written recommendation you can take to any developer.

    A paid feasibility report, a fraction of the build, before you commit to it.

    Fig.03Feasibility report

  4. 04: Quote & build

    You approve the plan; I build it end-to-end and stay accountable for the result.

    Outcome
    A working system, delivered end-to-end, with me still accountable.

    A fixed quote before any build begins.

    Fig.04Quote & build

Engagement model

  • A paid feasibility report, a fraction of the build, before you commit to it. src: How I work · step 03
  • A fixed quote after it. src: How I work · step 04
  • Requirement changes go to a ledger for the next version instead of silently expanding scope. src: stated commitment, no ledger exists yet

Pricing specifics

Pending

Not yet designated for publication.

After launch

After launch, the work can continue

Handover isn't the end of the relationship unless you want it to be. Maintenance, documentation, and making sense of an existing system are all on the table, and where I'm strongest is sizing up a codebase and mapping the road ahead.

Deeper work on an existing system I scope for what it honestly is, rather than promising to fix anything on any stack, so what happens after launch stays a real conversation instead of a blanket guarantee.

src: FAQ · maintenance after launch

A clean exit, by design

Leaving is something you can do at any point, with everything you paid for in hand. What I build is documented and runs on a standard, widely-used stack, so a handover reads as an ordinary onboarding for the next developer, not a rescue. The repository, the documentation, and the deployment already sit in your own accounts, and the domain is in your name from day one.

Nothing depends on a private system only I understand, and nothing ties you to me. Moving on to another developer is a choice you're free to make, not a wall you hit.

src: FAQ · who owns it

The shape of ongoing support

Pending

The specific support terms (a retainer, ad-hoc work, or handover-only, and how each is arranged) are mine to set and designate. Until then they stay off the page rather than appear as a promised tier.

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

Start the conversation