← daviddavisbukenya.no
Process

What working with me actually looks like

Five phases, in this order, every time. No account managers and no handoffs — you talk to the person writing the code. This page is the shape of the work; tell me about your project and I will come back to you with what it takes.

The five phases

01

Discovery

We work out what is actually being built, before either of us commits to it.

If your project fits one of the fixed packages, this is short — a kickoff call, and I write down the scope we agreed so we are both looking at the same list on day one.

If it does not fit a package, discovery is its own paid piece of work. I spend the time on the problem properly, and you own what comes out of it whether or not you build it with me.

What you get
  • The architecture written down — what gets built, on what, and why
  • A written scope: the list of what is in, and the list of what is out
  • A real figure to plan a budget against, not a range
What I need from you

An hour or two with whoever knows the business, and honest answers about the constraints.

02

Proposal

One document, seven sections, one price. Written to be read, not decoded.

Everything discovery produced becomes a proposal: what you asked for, what I will build, what I will deliberately not build, how the work runs, what it costs, when it is finished, and what would change the number.

It never grows past those seven sections. I read every proposal myself before it reaches you, and no figure in it comes from a model — the prices are produced by code and checked by me.

A proposal is valid for 30 days from its date. Until we both sign, it is indicative rather than binding, and it says so on the page.

What you get
  • A PDF with seven sections and exactly one price
  • The exclusions written down next to the inclusions
  • What would move the figure, named up front instead of discovered later
What I need from you

A proper read, and your questions. If something is missing or wrong, tell me before we start rather than in week three.

03

Build

Fixed weeks. You see it working every week, on a real URL.

The number of weeks comes from the package and it does not move. Scope flexes inside the box; the box does not stretch. That is the whole reason to buy it this way.

Every week you get a demo on a staging URL — the actual thing, running, that you can click. If something looks wrong in week two, we deal with it in week two.

Done means the list in the proposal is built, works properly on a phone, and is deployed. Not "mostly".

Wanting something that is not on the list is normal, and it is fine. Small things I absorb. Anything real becomes a change order with its own price and its own time, or it waits for the next package up. What I will not do is quietly swap it for something else on the list and let you find out at launch.

What you get
  • A staging URL you can open from the first week
  • A demo every week, on the same day
  • A change order in writing before anything outside the scope gets built
What I need from you

One person who can make decisions, and a reply within a day or two when I ask something. Plus the content and the access — text, images, and logins to whatever I have to connect to.

04

Launch

It goes live on your domain, and it stays yours.

I point the DNS, set up HTTPS, and put it on hosting — mine if you want me to run it, yours if you would rather. Either way you get the keys.

Handover is part of every package and never an extra: repository, deployment, environment variables, and documentation written for whoever comes after me.

You own the code on final payment. Nothing about it depends on me still being around.

What you get
  • Live on your domain, over HTTPS
  • Repository, deployment and documentation handed over
  • In writing: who owns and pays for what — domain, hosting, third-party accounts
What I need from you

Access to the domain, and a decision on where it is hosted after launch.

05

Care

Optional, monthly, and for when you would rather not think about any of this.

Care is hosting, security and dependency updates, uptime monitoring, and nightly backups that I restore from time to time to check they work — a backup nobody has ever restored is a hope, not a backup.

It also means I answer when something breaks, and it is the same person who built it.

New features are not care. Those are their own piece of work, scoped and priced like any other.

What you get
  • Hosting, security updates and uptime monitoring
  • Nightly backups, with restores actually tested
  • Me on the other end of an email when something breaks
What I need from you

Nothing month to month. Just tell me when the business changes, so the monitoring keeps watching the right things.

If the scope moves

It usually does, a little. Here is the rule, written down now so nobody has to negotiate it under pressure later.

The weeks are fixed. They are an appetite, not an estimate — a promise about time rather than a guess at it. Scope flexes inside them: if something turns out harder than it looked, we simplify or drop something else on the list instead of moving the date.

The package boundary is fixed too. If what you want is genuinely outside it, it is a change order with its own price, or it is the next package up. Both are honest answers; pretending it fits is not.

Either way, you decide, in writing, before it gets built.

What yours would take

Describe the project in plain words — what should exist when it is done, and roughly who it is for. I read every one myself, and I come back to you with the shape of it and a figure.

Describe your project