How I work
The method, what the working relationship actually looks like, and the things I’ll argue with you about.
The method
Seven steps. Step two is the one people remember, and it’s the reason to hire a partner rather than a pair of hands.
Step 1
Understand
What you’re trying to achieve, who it’s for, and what’s actually in the way.
Step 2
Challenge
If a feature, timeline, or assumption doesn’t make product sense, I say so. This is the part people remember.
Step 3
Recommend
What to build first, what to skip, and what it’ll cost. In plain language.
Step 4
Plan
A written scope: what’s included, what isn’t, milestones, and dates.
Step 5
Build
Development in scoped phases with working check-ins, not one black-box handoff.
Step 6
Launch
Testing, deployment, documentation, and app-store guidance where it applies.
Step 7
Improve
What the product tells you after real people use it.
What working together actually looks like
This is the Statement of Work in plain language. It’s the same agreement every project runs under, so none of it should be a surprise later.
- Communication
- Email, a shared project board, and scheduled calls. I aim to reply within 1–2 business days. Rush timelines and evening or weekend work get agreed separately, not assumed.
- Check-ins
- Regular working check-ins during a build, usually weekly, so you see progress instead of waiting for a reveal.
- Revisions
- Each package includes one structured revision round. A revision refines work already in scope. A new feature, flow, integration, or redesign is a change request, not a revision.
- Scope changes
- Written before work starts, with the impact on cost and timeline stated up front. Silence and verbal comments don’t add work, which protects both of us.
- What I need from you
- Timely feedback, access to systems, content and assets, and consolidated feedback rather than five conflicting messages. Delays on your side move the timeline; I’ll tell you when that happens rather than absorbing it silently.
- Handover
- Source code, deployment setup, documentation explaining what was built and why, credentials, and a walkthrough. You own the final deliverables once the project is paid in full.
- Payment
- 50% deposit before development starts, balance per the schedule in the agreement. Third-party costs are yours and quoted separately: hosting, domains, app stores, paid APIs.
- After launch
- Maintenance, monitoring, and ongoing feature work aren’t included by default. If you want me to stay involved after launch, there’s a rolling retainer at $1,200 CAD/month. If you don’t need one, I’ll say so.
What I’ll push back on
Not to be difficult. Each of these costs a founder more than the argument does.
- A feature list with no priority order.
- A launch date chosen before the scope.
- A rebuild when a fix would do.
- Building for scale you don’t have yet.
- Skipping the written agreement because the project is small. I use one every time, including for small projects.
What this costs you
Nothing, until there’s a written scope and a deposit. If a conversation ends with me telling you not to build anything yet, that conversation was still free. What each package costs is published, and the starting prices are real starting prices.
Still deciding whether this fits?
Tell me where the product stands and I’ll tell you what I’d do first - including if that’s nothing yet.