How a project runs, from first call to launch
Every WordPress, PHP, or Moodle project follows the same transparent process, clear scoping, honest timelines, and steady communication from kickoff through post-launch support.
Step 1
Kickoff call & requirement scoping
We start with a discovery call to cover your goals, your existing platform (or lack of one), and any must-have features. I ask about hosting, current WordPress or Moodle setup if there is one, and your timeline, so nothing important gets assumed later.
- Discovery call on goals & constraints
- Audit of existing site or LMS, if any
- Clear list of features and priorities
Step 2
Proposal, timeline & tech plan
You get a written proposal covering scope, milestones, a realistic timeline, and pricing, before any code is written. I'll also outline the tech stack, whether that's WordPress, WooCommerce, Moodle, or Laravel, and flag any risks upfront so there are no surprises.
- Detailed scope of work
- Milestone-based timeline
- Transparent pricing before work begins
Step 3
Development in sprints
I build in short, reviewable sprints rather than disappearing for weeks. You get regular updates by email, call, or a shared project board, with staging links so you can see real progress and give feedback while there's still time to act on it.
- Staging links to review live progress
- Regular check-ins by email or call
- Room for feedback mid-build
Step 4
QA, refinement & launch
Before anything goes live, I test across browsers and devices, check page speed and Core Web Vitals, and run through security hardening. Bugs get fixed and you get a walkthrough before we flip the switch, with launch timed to minimize downtime.
- Cross-browser and device testing
- Performance and security checks
- Guided walkthrough before go-live
Step 5
Post-launch support & handoff
After launch, I stick around for a defined window to catch anything that slips through and help your team get comfortable with the new site. You'll also get documentation on what was built, with the option to move into an ongoing maintenance retainer afterward.
- Bug-fix window after launch
- Documentation & handoff notes
- Optional ongoing maintenance retainer
Commonly asked questions
A few things clients often ask before we start working together.
Mostly email, scheduled calls, and a shared project board so you can see progress without having to ask for it. For active builds I send short updates at each milestone; for maintenance retainers, updates go out whenever changes are made.
Your goals for the project, any examples of sites or LMS platforms you like, and access to your current hosting or WordPress admin if you already have a site. A rough budget and timeline helps too, even if it's not final, it makes the proposal more useful to you.
It depends on scope. A WooCommerce store or a Moodle LMS build typically runs a few weeks; larger custom builds or full platform migrations take longer. Timelines are set during the proposal stage once the scope is clear, not guessed at upfront.
You get a defined bug-fix window included with the project, plus documentation on what was built. After that, most clients move onto an ongoing maintenance retainer covering updates, backups, and security monitoring, but it's optional, not required.
Ready to start your project?
Tell me about your project and I'll follow up with next steps, usually within a day or two.
-
Free initial consultation
-
Response within 24-48 hours