Pseudocode for Real Life: How I Decide to Take a Project

I like writing logic as pseudocode. It has no syntax to hide behind. If a rule cannot be written in a few plain lines, I do not understand it yet.

In an earlier note I wrote my feature rule that way. This note does the same for a bigger question. When someone brings me a project, how do I decide to take it?

The rule in a few lines

IF scope AND price ARE NOT approved in writing THEN REFINE the scope first
ELSE IF work HAS NO tested milestones THEN REFINE the scope first
ELSE IF client WOULD NOT keep accounts, hosting, domain THEN REFINE the scope first
ELSE IF limits ARE NOT said before starting THEN REFINE the scope first
ELSE TAKE it

There are two outcomes. Either I take the project, or we refine the scope first. Refining is the next step. Most ideas become good projects once the first version is small and clear.

Scope and price, in writing, before code

This is the first check, and the rest depend on it. Before I write code, the scope and the price are written down and the client approves them. Nothing starts on a handshake.

I get there with a free tech-stack consult, then a one-page written recommendation. I give one clear recommendation and the alternative. You decide. You can read the whole flow on the how I work page.

New ideas are welcome while I build. A new idea becomes a scope change, and it gets its own price. That keeps the first version honest and keeps surprises out of the invoice.

Milestones and tested releases

A project I take can be cut into milestones. Each milestone ends in a release that I have tested. I test where the change lives: a small local change gets a targeted test, and shared code gets the full set.

This is the same lean habit as before. Build the smallest thing that works, ship it, then look at the next piece. If I cannot see a first milestone, the scope is not ready yet.

You keep what is yours

The client keeps the accounts, the hosting and the domain. Nothing is locked to me. At handover you get a rollback plan and the docs. Before a risky change I take a backup, and I keep a way back.

If a project could only work with me holding your keys, I would want to refine the scope first.

Honest limits, said first

I cannot guarantee rankings, traffic, downloads or store approval. Nobody honestly can. I say it before we start, so the plan is built on work we control.

Why a toy, not a form

Try it above. Answer four yes/no questions and it ends in "take it" or "refine the scope first". It runs the same rules in this note and nothing leaves the page. You can find more small tools like it on the widgets page, and more essays in the notes.

If you have an idea and want to know where it lands in the rule, the first step is free. I reply within one business day.

Book a free consult

You can also contact me directly.

Where this comes from

These are my own working rules, the same ones on the how I work page. There are no outside sources here.