Custom website development for the job a template cannot do

What custom website development actually means

Custom website development means the site is built from your requirements rather than assembled from a theme and a plugin stack. The data model, the page types and the behaviour are designed for what your business actually does, and the code is written rather than configured.

It is worth being blunt about when this is the wrong purchase. If your business is conventional and your content fits a normal page, a template will serve you faster and cheaper, and anyone telling you otherwise is selling. Custom earns its cost when the workaround has a running cost — when a template forces manual work every week, or blocks a rule your business depends on.

Who this is for

• Businesses whose pricing is calculated rather than listed, and cannot be expressed as a variant dropdown
• Companies that have hit a hard limit in a builder or theme and been told the answer is "not possible"
• Businesses running an expensive manual workaround because the website cannot do one specific thing
• Anyone maintaining a stack of plugins that fight each other after every update
• Organisations that need to own their code outright for procurement or compliance reasons

Who it is not for

Saying this out loud costs me some enquiries and saves both of us the ones that would have gone wrong. If you are on this list, I will tell you in the first reply rather than after a deposit.

• Businesses whose requirements a good template genuinely satisfies. I will tell you when that is the case
• Anyone who wants custom because it sounds better, without a specific limitation driving it
• Projects with no internal decision-maker, because bespoke work is decision-heavy by definition
• Businesses that need it next week. A specification cannot be responsibly compressed into a weekend

The problems it solves

"The platform will not let us do that"

The rule is implemented in code, because the constraint was a vendor decision rather than a technical one.

Manual re-entry every week

The process is modelled properly, which is usually where the entire return on a custom build comes from.

Plugin conflicts after every update

No plugin stack. Fewer moving parts, fewer things that break when one of them updates itself.

Page weight from features you never use

Multi-purpose themes ship code for every business they might have served. A custom build ships only yours.

Nobody can explain how it works

A written specification and documented deployment. The system is legible to the next developer, which protects you rather than me.

Locked into a proprietary builder

Standard PHP, MySQL and CSS in your repository. Portable by construction.

What you get

• A written specification agreed before any code, including what is explicitly out of scope
• Custom data model designed around your business logic rather than a theme author’s assumptions
• Hand-written PHP 8 and MySQL — no page builder, no multi-purpose theme, no plugin stack to maintain
• Front end in Tailwind CSS with Alpine.js only where interaction genuinely needs it
• Admin interface a non-technical person can operate without a training course
• Technical SEO built in during the build rather than retrofitted afterwards
• Source code in a repository you own, with deployment and rollback documented
• 30 days of snag fixes after go-live

What is included in the starting price

Everything below is in the $200 figure. Nothing here is quoted as an extra once the build is underway, which is the point of publishing it.

• Written specification, agreed and signed off before any code is written
• Custom database schema with constraints enforced where they belong
• Hand-written PHP 8 application code, no page builder and no theme framework
• Responsive front end in Tailwind CSS, designed mobile-first
• Admin interface built around your workflow rather than a generic CRUD screen
• Technical SEO baseline: schema, sitemap, canonical tags, crawlable rendering
• Security baseline: prepared statements, server-side validation, security headers
• Repository, deployment procedure and written handover documentation
• 30 days of snag fixes after go-live

What costs extra, and why

A quote that omits these is not cheaper — it is less honest. Each one is real work that someone has to do, and pretending otherwise is how a fixed price becomes a negotiation in week two.

Third-party integrations

Each external system is its own small project with its own failure modes and its own testing.

Data migration

Moving existing content or records, with a redirect map where URLs change. Quoted on volume and messiness.

Content entry at volume

Loading several hundred records by hand is real time and is quoted separately once we know the count.

Design system

Where you need a documented component library rather than a site, that is a broader piece of work.

Ongoing feature development

Bespoke systems grow. A retainer is usually better value than a series of small quotes.

How the work runs

1. Specify. The most valuable day of the project. What the system does, what it explicitly does not, and where the edges are. You sign it off and get a confirmed number.
2. Model. The database comes before the design. Getting the data model wrong is the one mistake that stays expensive for the life of the system.
3. Build. Daily on a staging URL you can open at any time. You see it wrong before you see it right, which is how scope problems surface in week one instead of week four.
4. Harden. Prepared statements, server-side validation, security headers and error handling. Not a phase that gets cut when time runs short.
5. Launch. Deployment, SSL, Search Console, sitemap, and a written handover that includes how to deploy the next change.

Day by day

10 days from the day scope is signed off. Published as a schedule rather than a promise of speed — you should be able to tell on day three whether a build is on track.

The technology

Deliberately boring, and that is the feature. A stack another developer can pick up is worth more to you than one that impresses other developers.

Application

PHP 8, written directly rather than through a heavyweight framework the project does not need

Database

MySQL, schema-first, with foreign keys and constraints actually used

Front end

Tailwind CSS with Alpine.js where interaction requires it

Rendering

Server-rendered HTML, so content exists without JavaScript execution for crawlers and answer engines

Hosting

Standard cPanel or a VPS. Nothing here requires a specific vendor, which is deliberate

What it integrates with

• Stripe for payments, where the build takes money
• Transactional email through your own authenticated domain
• Any documented REST or JSON API — suppliers, dispatch, CRM, accounting
• CSV and spreadsheet import and export, which is what most businesses actually run on
• Google Search Console and privacy-respecting analytics
• Authentication against an existing directory where one already exists

What I need from you

Short list, and the first item matters most. Projects do not usually slip because the code was hard — they slip because a decision waited a week.

• A decision-maker available during specification. This is the phase where your input has the most leverage
• The real rules, including the exceptions. The exceptions are where bespoke projects overrun
• Examples of the awkward cases — the order that broke the old system is worth more than a description of the normal one
• Existing data in whatever form it is in, however untidy
• Hosting, domain and any third-party accounts, in your name

Content and photography

Specification is content in a bespoke project, and it is the part clients most often want to skip. Two days spent writing down what the system does is the cheapest insurance available, because every ambiguity left in it becomes a decision made by a developer who is guessing.

Bring the edge cases specifically. Everybody can describe the standard order; the value is in the one that had a partial refund, a changed address and a discount applied after dispatch. Systems are shaped by their exceptions, and a specification that only covers the happy path is a specification for a system you will immediately need changed.

Performance standards

Targets, not aspirations — measured before handover on a throttled mobile connection rather than on a fast laptop.

Accessibility standards

This site is built to the same standard it sells, and the accessibility statement lists what is conformant and what is not — which is the part most statements leave out.

Security practices

The SEO included in every build

Not an upsell. A site that launches unindexed is a shop with the shutters down, and the work below is cheap during a build and expensive afterwards because the fixes are structural.

Ownership and handover

You own everything: the domain registered to you, hosting in your account, code in a repository you control, and the payment provider account in your business name. Credentials are handed over as they are created rather than at the end.

A supplier who resists this is protecting recurring revenue rather than your interests. If you want the reasoning in full, including how to check your current site, there is a guide on it.

Aftercare and what happens after launch

Thirty days of snag fixes are included. A snag is something that does not work as scoped — not a new feature, and the difference is written down before launch rather than argued about after it.

You also get written handover documentation aimed at whoever maintains the site next, which may well not be me. That is deliberate: the test of a good handover is whether another developer could take over without calling me, and on my projects they can.

Ongoing maintenance

Optional, monthly, cancellable. Nothing here is required to keep what you paid for.

Payment terms

How this compares to the alternatives

Including the routes that do not involve me, because a comparison that only flatters the author is not a comparison.

What could go wrong, and how it is handled

The specification changes mid-build

Re-quoted before work continues. Silent absorption is how bespoke projects end in dispute.

A rule turns out to be more complex than described

This is exactly what specification exists to catch, which is why it takes two days rather than an hour.

An external system is undocumented

Discovered during specification where possible. Undocumented APIs are a schedule risk and you are told so before committing.

You want to leave

The code is in your repository, the accounts are yours, and handover documentation is a deliverable. Nothing is engineered to keep you.