How I Work: From the Free 30-Minute Call to a Live Site
Most "how it works" pages are vague on purpose — keep the prospect warm, avoid scaring them off with specifics. This one is the opposite.
If the process sounds like too much for your project, that is useful information. Better to find out now than two weeks in when the build is underway.
The Stages
Stage 1 — Free 30-Minute Discovery Call
No sales pitch. This is a scoping conversation.
I want to understand what you're trying to accomplish, what currently exists, and whether what you need falls inside what I actually do. If it doesn't, I'll say so and point you somewhere else.
What you get out of it: a clear sense of whether this project is the right fit, and a rough idea of scope before any money changes hands.
What I get out of it: enough to write a real proposal, not a guess.
There's no obligation after this call. If you want to proceed, I'll send a proposal within a few days. If not, no follow-up.
Stage 2 — Scope + Proposal
After the call, I write a fixed-scope, fixed-price proposal. No hourly billing. No "it depends on how long it takes."
The proposal defines exactly what gets built, what does not get built, and what happens if you want something added after signing. Scope changes are quoted and approved separately — they don't just quietly absorb into the project cost.
What you get: a document you can read in 10 minutes that tells you exactly what you're buying.
What I need from you: read it. Ask questions before signing, not after. A signed proposal means we both agree on scope.
Stage 3 — Architecture + Design System
Before any page is built, I establish the structural and visual foundation:
- Information architecture — which pages exist, how they connect, what each page needs to accomplish
- Elementor Kit design system — global colors, global fonts, button defaults, heading defaults. Every visual decision that will propagate site-wide gets decided here, not improvised later
- Schema plan — structured data strategy (Organization, LocalBusiness, Article, FAQ, etc.) mapped to content type
- Hosting and plugin stack decisions — if we're starting from scratch, this is when we select and justify every tool
This stage is why the build goes fast. Skip it and you spend twice the time fixing what should have been decided on day one. Every hour spent on architecture here saves three hours of rework later.
What you get: a documented architecture that survives the project. Not a wireframe that lives in a Figma file nobody will open again.
What I need from you: access to any existing branding assets (logo files, brand guide, fonts) before this stage starts. A brand guide delivered mid-build slows everything down.
Stage 4 — Build
This is where the pages get built in WordPress + Elementor against the design system established in Stage 3.
I work on a staging environment. You will never see a half-finished page on your live domain.
Every section is built with the site owner in mind — components that a non-developer can edit without breaking the layout. That's a design constraint, not a nice-to-have.
What you get: a staged site you can preview in a real browser, on real devices, before anything goes live.
What I need from you: all final copy and images before this stage starts. I build to content — I do not build to placeholder text and swap it in later. Placeholder content produces layouts that fall apart the moment real copy lands. Send final copy first. Build starts after.
Stage 5 — Review Rounds
The proposal specifies how many review rounds are included — typically two.
Each round works like this: you review the staged site, collect all feedback into a single consolidated document, and send it once. I address it and update the stage. Then we go to round two.
What I need from you: one decision-maker. Not five stakeholders sending separate lists. One person owns the feedback doc and sends one consolidated list. If I receive five separate emails with conflicting notes, I pause and ask you to consolidate before I act on any of it.
Review rounds are not unlimited. Changes that fall outside the original scope — new pages, structural redesigns, feature additions — are quoted separately.
Stage 6 — Launch
Before launch, I run a pre-launch checklist: redirects, canonical tags, schema validation, page speed baseline, broken-link scan, mobile QA, SSL, backup verified.
When everything clears, I do the DNS cutover or deploy to the live environment.
What you get: a live site with a clean technical baseline on day one — not a site that passes visual inspection and quietly has broken structured data and no sitemap.
What I need from you: DNS access or a contact at your registrar who can action a record change the same day. Launches that drag over 72 hours because DNS access is unclear are a pattern I've seen too many times. Have it ready before we set a launch date.
Stage 7 — Documented Handoff
Every project closes with a handoff document. It covers:
- How to edit the things you'll want to edit (without breaking the design system)
- What not to touch without talking to me first (and why)
- Plugin update policy — which plugins are safe to auto-update, which ones are not
- Backup configuration — where backups live, how to restore
- Credentials inventory — what accounts exist, who owns them
This is not a generic WordPress tutorial. It's specific to your site, your stack, your content model.
What you get: a document that means you're not dependent on me for basic edits — and that means you know when to call me back because something is genuinely complex, not just unfamiliar.
Ideal Timeline
This is the schedule on a project where content arrives on time and feedback rounds close in 2–3 business days.
| Week | What happens |
|---|---|
| Week 1 | Discovery call, proposal sent + signed, contract executed |
| Week 2 | Architecture and design system built, content brief sent to client |
| Weeks 3–4 | Client delivers final copy and assets |
| Weeks 5–7 | Build on staging |
| Week 8 | Review round 1 |
| Week 9 | Review round 2, pre-launch QA |
| Week 10 | Launch + handoff |
Most projects do not run on this schedule. The most common delays: content arrives in week 6 instead of week 4, or round 2 feedback sits for two weeks while the client is traveling. Both are normal. Both push the launch.
The timeline is a model for what's possible, not a guarantee. What I can tell you is that my side of the schedule stays on track. The variable is almost always content and feedback speed on the client side — which is why both of those are called out explicitly below.
What I Need From You
These are not preferences. They are the conditions under which good work gets done. Every item here exists because its absence has broken a project timeline.
Content arrives finalized before the build starts. No exceptions.
Copy and images are the raw material. Building to a content brief you have not finished is building in sand — the layout will fail the moment real content lands. Final content first. Build starts after. This is not negotiable.
One decision-maker. Not a committee.
One person owns approvals and sends consolidated feedback. If your organization requires internal sign-off from multiple people, handle that internally — one person aggregates it into a single document before it reaches me. Multiple simultaneous reviewers sending conflicting notes halts the project until you resolve them. That is on you, not on the timeline.
Feedback within 3 business days per round. The clock is real.
Review rounds close. If feedback does not arrive within three business days of the staged review link, I mark the round approved and move forward. One reminder. After that, the round closes on my schedule, not yours.
Access and credentials secured before kickoff. Not the week of launch.
Hosting access, domain registrar access, existing WordPress admin, Google Search Console, any third-party integrations the site requires. Access issues that surface mid-build stop the build immediately. Gather everything before we start. If you need to track down a forgotten login or talk to a registrar, do it before kickoff, not during.
Direction changes go through scope, not the feedback doc.
Priorities shift. That is real and I can work with it. What I will not absorb is a strategic direction change arriving as a casual comment in a review round dressed up as a minor tweak. If the scope needs to move, say so directly and we will quote it. Major changes require a scope conversation before any work starts on them. Minor changes go in the feedback doc. The distinction is not yours to decide unilaterally.
Frequently Asked Questions
Do you do hourly work or maintenance outside of projects?
Yes, on a retainer basis after a completed project.
Can I supply my own design?
Yes, if it's properly specified. A Figma file with no defined typography scale, no color tokens, and no mobile states is not a design — it's a sketch. I'll tell you that during the discovery call.
Do you work with existing WordPress sites?
Sometimes. It depends on the condition of the codebase, the plugin stack, and whether a rebuild is cheaper than a remediation. That's a discovery-call conversation.
What builders do you use besides Elementor?
Elementor Pro is my primary builder for custom WordPress work. I do not use Divi, WPBakery, or Beaver Builder on new projects. If you're on one of those and want a migration, that's a separate scope.
Start With a Call
The process is designed to remove surprises — on both sides. If after reading this it sounds like a fit, the next step is a free 30-minute discovery call.
You describe the project. I tell you exactly what I see. We determine whether the scope makes sense before any money moves.