A paid diagnosis
I go through what exists and write down what works, what will break, and what it would take to fix. You get the document whatever you decide next — and if we go ahead, its cost comes off the project.
For clients
What it looks like when one person owns the whole thing
No account manager, no handover, nobody to point at. Here is how a project actually runs, what I need from you, and where my limits are — before you spend anything.
Four ways to start
Pick the one that matches where you areA new product, phase by phase
Scope written down first, then a fixed price per phase. Every phase ends with something you can open and use — not a progress report. You can stop after any of them and keep what's built.
Rescue of a running system
Before touching anything I write down how it runs and put tests around the parts that matter. Only then do the changes start — so that shipping a fix stops being a gamble.
An operations retainer
Monitoring, nightly backups, certificate renewals, updates — and a person who answers when something stops. This is what the oldest of my products has been living on for eleven months.
How a project runs
Same five steps, same order — you always know which one we're in1
Scope
What is being built, what is not, and what «finished» means — written down before any code exists.
2
Build
In phases you can see. At the end of each one there is a working thing on a real address, not a demo video.
3
Test
Before it reaches you. The awkward cases are written first, so you meet the version that has already been broken on purpose.
4
Launch
Your domain, your certificate, your accounts. Backups running from day one, and a tested way back to yesterday.
5
After
Either I keep watching it, or you get documentation written for your staff and a clean handover. Agreed at the start, not improvised at the end.
What I need from you
Three things, and only three
Decisions
The questions only you can answer — prices, rules, what happens in the awkward cases. They arrive as one list with my recommendation on each, not as a drip of messages.
Real content
Your actual text and photographs. Placeholder content hides problems until launch day, and that is the worst day to find them.
Accounts in your name
Domain, hosting and payment accounts registered to you, with me added as a user. You should never need my permission to reach your own business.
What you end up holding
Yours, whatever happens to me
- 1A working product on your own domain, in your own accounts.
- 2An admin panel, so ordinary changes never need a developer.
- 3Documentation written for your staff, in plain language, not for engineers.
- 4Nightly backups, and a restore that has actually been tried.
- 5The source code, in a repository you own — so another developer can pick it up.
Where my limits are
Said now, not after the invoice
mobile
Native mobile apps
I build installable web apps that work on a phone, install from the browser and need no app store. If you specifically need Swift or Kotlin, I'm the wrong person and I'll say so at the first email.
size
Scope past one person
If the work needs a team to hit your date, stretching alone would only cost you the deadline later. I quote against the ceiling instead of hoping, and I'll tell you in the first reply.
business
Decisions that are yours
Prices, commission, refund rules. Where a choice belongs to the business, I bring options and a recommendation — and hold that part rather than guess in your name.
three sentences are enough
Start with the diagnosis
The task, the deadline, and what state it's in. You'll get a straight answer on scope and timing in the first reply.