Design comes in. A working, tracked, fast site goes out.
Five things, done properly. Most projects are one or two of them. All of them assume someone else is waiting on a launch date.
(01)
Design to build
Your Figma, XD or Photoshop file becomes a pixel-faithful WordPress site — or hand-coded responsive HTML and CSS when the build needs to be lighter than a theme.
Most of my work starts as somebody else's design. I read it properly before I start, and I tell you where it will fight the platform while there's still time to change it. Breakpoints, hover states, empty states and the long-name case get built, not improvised.
What you get
- Responsive build to your design
- Editable in the builder your team knows
- Semantic markup and real heading order
- Core Web Vitals checked before handover
- A written note of everything I changed
(02)
Funnels and order forms
Sales pages and checkouts tested before they take money. Every button, every upsell path, every declined-card state.
An order form that looks right and silently fails on a declined card costs more than the whole build. I test the unhappy paths — expired cards, duplicate submissions, the back button mid-checkout — because those are the ones nobody checks until launch day.
What you get
- Page build to your design or template
- Checkout wired to your processor
- Upsell and downsell paths tested end to end
- Tracking that fires on the right events
- A test-pass checklist you can re-run
(03)
Membership and course sites
Courses, drip content and gated communities that hold up when four thousand people log in the same hour.
Membership builds fail in the seams: the tag that should have granted access, the drip that fires a day early, the cancelled member who can still log in. I wire the seams first and build the pretty part second.
What you get
- Course structure and drip schedule
- Access rules tied to your CRM tags
- Cancellation and refund paths handled
- Load-tested before launch week
- Admin walkthrough so your team can run it
(04)
CRM and automation
Forms, tags and hand-offs that put the right person in the right sequence without anyone touching a spreadsheet.
I map what should happen before I build what does. Most automation problems turn out to be two tags doing the same job under different names.
What you get
- A written map of the flows before build
- Forms wired to the right lists and tags
- Zapier or native integrations, documented
- Test contacts run through every branch
(05)
Speed, tracking and care
Core Web Vitals, GTM and pixel implementation, quarterly audits, weekly backups. The part that keeps working after everyone else has moved on to the next launch.
This is a flat monthly retainer, not a project. It exists because most of the sites I'm asked to rescue were fine at launch and simply never touched again.
What you get
- Weekly backups and plugin updates
- Uptime and Core Web Vitals monitoring
- Tracking and pixel implementation
- A quarterly audit you actually receive
- A named person when something breaks
how I price
A fixed fee against a written scope.
Every project is quoted as a fixed fee after one short conversation. You know the number before anything starts.
If the scope changes, I send a change note with a new number before I build it — you will never get a surprise invoice. Ongoing care is a flat monthly retainer, billed the same day each month.
I ask about budget in the inquiry form because it decides the shape of the work, not the size of the invoice. It tells me whether to scope one page or twelve.