Web development & delivery
You need a site built properly, and you have been burned by handoffs.
The usual failure is not technical. It is that the person who understood your project was gone by week three, and you spent the rest of it explaining your own business to their replacement.
From $6,000 · per project
The work
What I build
Content-heavy sites for organizations that publish: colleges, non-profits, associations, service businesses with something to say. Sites with hundreds or thousands of pages, real editorial workflows, and staff who need to update them without raising a ticket.
- Fast by construction. Pages that hold up on a phone on a bad connection, because that is where most of your traffic is.
- Accessible during the build. Tested as it is made, not audited in a panic afterwards. Why that matters here.
- An editing experience your staff will actually use. If publishing is unpleasant, the site goes stale and nothing else you paid for matters.
- Search built in from the structure up — how content is organised decides what can rank, long before anyone writes a meta description.
- Integrations that hold. Forms, CRM, events, payments — where they break is at the seams, so the seams get the attention.
The handoff
One senior person, start to finish
An agency puts a senior person in the room to win the work and a junior one on the keyboard to do it. That is not cynicism, it is the economics — it is how the model has to work.
Working with me, the person who scoped it is the person writing it. Nothing is lost in translation, decisions get made by someone who understands both the business reason and the technical cost, and there is no week three.
Method
From $6,000
How the work runs
- Scope. What it must do, who maintains it, what it integrates with, what happens if it is late. Fixed price comes out of this — not before.
- Structure. Content model and navigation first. Get this wrong and every later decision is a workaround.
- Build. In visible increments you can click through, so course corrections happen while they are cheap.
- Launch. Tested for accessibility and performance, with an actual rollback plan.
- Hand over. Accounts, repository, documentation and a working session for whoever runs it next.
From $6,000, fixed once scoped. Larger builds are staged so you are never committing to the whole thing at once.
Limits
When I am the wrong choice
- Rebuilding an existing site. That is a redesign — different work, different risks, mostly around not losing what you have.
- A five-page brochure site. A template will serve you better and cost a fraction. I will say so.
- Apps and product engineering. I build websites. Software products are someone else's specialism.
Ownership
What you will be running on
The tool is the least interesting decision in the project, but the question underneath it is not. So, plainly:
- Mainstream, boring, and widely known. Whatever gets used, a competent developer who has never met me can pick it up. That rules out anything clever for the sake of it, including tools I personally find more interesting.
- A real CMS your team edits without me. If publishing a page requires a developer, the site goes stale and everything else you paid for stops mattering.
- Hosting in your account, billed to you. Typically tens of dollars a month, not hundreds. I do not resell hosting — a vendor who owns your hosting owns your exit.
- Your existing platform is a strong argument for itself. If your team knows WordPress, that familiarity is usually worth more than any technical gain from moving. I will tell you when it is not.
- No proprietary framework of mine. Nothing that only I can maintain, and nothing you have to keep paying me to keep running.
The short version: you should be able to fire me and lose nothing but my time. That constraint shapes every technical decision on the project.
The difference
The small things that decide whether a build holds up
A build is not won by one big decision. It is won by a few dozen small ones that are easy to skip and expensive to retrofit. A sample of what gets done here without being asked:
- Every image is sized and served in a modern format — the single most common reason a site feels slow on a phone is a 4MB photo nobody resized.
- Forms are tested with a keyboard before launch — a form that cannot be completed without a mouse excludes people and, in Ontario, is a legal problem.
- Error and empty states are designed, not left to the framework — the first time a visitor sees a raw error page is the moment they stop trusting the organization behind it.
- The CMS is configured so bad input is hard — if a required field can be left blank, it will be, on the busiest day of the year.
- Every dependency is one a mainstream developer knows — clever tooling is a hostage note to whoever inherits the site.
- The staging site is not indexable — a duplicate of your site in search results competes with the real one, and it happens constantly.
Evidence
Sites built like this
A parade landing page and a national directory need the same care, at different scale.
A bought-in product replaced by something the college owns — the same functionality, run by the same staff, now with no external cost and full control.
Orientation ran on a purchased platform. Staff already updated the scenarios themselves; what the subscription bought was the functionality underneath — renewed on the vendor's cycle, on a product the college did not control.
Distance and continuing education
distance.confederationcollege.ca (opens in a new window)
Public college, Thunder Bay
The department now has pages of its own worth promoting — mobile-friendly, searchable, discoverable — and can put up a landing page to market an upcoming course.
A site built many years ago, before the department worked the way it does now — not responsive, not accessible, and fed by hand.
Top positions on competitive terms, with no link building and no ongoing search spend.
The information existed but was scattered across dozens of places, so nobody could compare anything.
It has carried successive parade seasons without a rebuild.
Thousands of people need the route and the start time, on a phone, outdoors, in a Thunder Bay winter — over about two weeks a year.
A migration has a mapped URL inventory rather than a memory of one, and handover is a document rather than a phone call.
Most agency delivery lives in someone's head. Decisions get made in a call and never written down, the reason for a choice is lost by the time it matters, and the next person — including the client — inherits a site with no record of why it is the way it is.
This site runs on a theme it produced, and its colour files are generated rather than chosen by eye.
Every project starts by rebuilding the same foundations, and a palette chosen by eye tends to fail contrast somewhere nobody checks.
Questions
Practical questions
What do you build on?
Whatever survives you leaving. Usually a modern static or hybrid stack with a proper CMS behind it, because it is fast, cheap to host and hard to break. If you already have a platform your team knows, that is a strong argument for keeping it — familiarity is worth more than my preferences.
What if you get hit by a bus?
Fair question, and the reason handover is a deliverable rather than a favour. Everything lives in your accounts and your repository from day one, on mainstream technology any competent developer can pick up. You are never holding an asset only I can operate.
Can you work with our internal team?
Yes, and it is usually the best outcome. Building alongside people who will own it afterwards means the knowledge stays with you.
Do you do the content?
I structure it and I will push hard on what it should say. I do not invent it — the good version comes from your people who know the subject, with me making it usable. Content is also the most common reason projects run late, so we plan it early.
How do you handle hosting?
It runs in your accounts, billed to you directly, on hosting that costs tens of dollars a month rather than hundreds. I will set it up and hand over the keys. I do not resell hosting, because a vendor who owns your hosting owns your exit.
What does the timeline actually look like?
Scope and structure take two to three weeks, the build four to ten depending on how many templates and integrations there are, then launch and handover. The parts that slip are almost always content and approvals on your side, which is why they get named and dated at the start.
Tell me what you are building
What it needs to do, who will run it, and what is driving the date. You will get a straight answer on scope, price and whether I am the right person for it.
Tell me what you are building
What it needs to do, who will run it afterwards, and what is driving the date.
Goes straight to me. No list, no automated sequence — see the privacy policy.