Engagement model 01
Project engagements
An idea, a pitch or a problem, and nothing built yet? I take it from a conversation to something people can use.
How the engagement is shaped
Typical duration
6 to 10 weeks
Long enough to test and build, short enough to stay urgent.
Commitment
Part-time
Two to three days a week, one weekly review.
Scope
Agreed up front
Modules chosen before we start, each with one outcome.
Best for
A defined outcome
One thing that has to exist by a date.
What we assemble
Six modules; most projects use three or four.
Knowing which to leave out saves you a month.
01
Product strategy
What to build and what to cut, argued in writing, not assumed. I synthesise with Claude instead of by hand.
Include it whenThe scope is contested, or someone above you needs convincing.
02
Research
Interviews with people from your market, turned into a recommendation you can act on.
Include it whenYou are guessing about people unlike you, and being wrong is expensive. Skip it if you are the user.
03
Exploration
Directions to choose between: rough and wide when structure is open, close to final when it is taste.
Include it whenThe obvious answer might not be the right one.
04
Prototype and test
Working HTML, CSS and JS on your data, tested with real users, then changed by what they did.
Include it whenBehaviour is the risk: anything that reads fine as a static frame and falls apart in use.
05
Design system
Tokens, specified states and a validation layer that holds after I leave.
Include it whenMore than one person will build on this.
06
Shipping
Front-end code in your repo, reviewed in your process. AI does least here, on purpose: shipping is judgement and accountability.
Include it whenYou want it live, not just approved. Skip it if your engineers prefer a spec.
AI sits inside most of these, so the work takes weeks, not quarters. The expensive part is knowing which to skip.
What I need from you
- 01One decision-maker who can say yes, available weekly.
- 02For research: five or six people from your market.
- 03Whatever exists: notes, a deck, a spreadsheet, a half-built thing. Messy is fine.
- 04For shipping: a repository to push to.
What this does not include
Both can be arranged; say so on the call.
Backend engineering I write the front-end. Server-side belongs to your team or a developer you bring in.
Brand identity A different discipline. I design inside your brand, or a plain one, and can refer you.
Relevant work
Questions
What teams ask before a project
Can you work with our engineers, or do you replace them?
With them. My front-end code lands in your repo, through your review. Backend, infrastructure and scale stay theirs.
What if the work says the idea is wrong?
Then I tell you, with the evidence, and we decide together. I have redirected a build after testing before; that engagement saved more than it cost.
Do we own the work?
Yes: design files, code and documentation. I only ask to reference the work publicly, anonymised if you prefer.
Is AI writing our product?
No. Claude Code and Claude Design speed up exploration and implementation. Every decision, review and shipped line is mine.
Can you start immediately?
Yes. A short brief and one call usually mean starting within two weeks.
What if we need more after the project ends?
Some teams continue as an embedded partner. Others take the system and run. Both are fine.