WordPress theme development of any complexity
A theme is how a site looks and how it is run — not the site itself. It survives a redesign of the content, moves to other projects, and can exist apart from any of them. Here one is written from scratch against a design or against the content model, or somebody else's is put in order without breaking its updates.
- 42 projects
- on WordPress, in the archive
- 19 years
- in development
- No page builder
- the editor, configured instead
The subject
A theme is not a site
What a site is
A site is the content model, the pages, the settings, the domain and the launch. It belongs to one business and to one set of data.
What a theme is
A theme is the presentation layer: the templates, the styles, the palette, the fields the editor sees. It knows nothing about the particular content and works with any that has the same structure.
Why that matters in practice
Content changes more often than the theme, and the theme more often than the site. Split them and a redesign happens without touching the data, while a second property launches without being written again.
When it is ordered on its own
There is a finished design and only the code is missing. There is a family of sites on a common base. There is a site that works but cannot be run — and what needs rebuilding is the presentation, not the contents.
The scope
What the work includes
A theme from scratch
With no third-party framework underneath: the templates are written against the content model rather than against a demo import. A parent theme where there will be several sites, a child theme where there is one.
A child theme for somebody else's
Changes to a bought or inherited theme are moved into a child theme, so the author's updates stop erasing the work. It is also the way back for a theme already edited in place: the changes are found, moved across, and the parent returns to a state that can be updated.
The editor and its blocks
The palette, the type scale and the set of blocks are declared in theme.json, so the editor cannot step outside the design even deliberately. Editor styles are built from the same variables as the front end rather than approximated by eye.
Fields instead of a blank canvas
Where a page has to be laid out the same way every time, the editor gets fields rather than an empty page: fill it in, yes; break the layout, no.
Speed as a consequence
What stays in the stylesheet is what the site actually uses. Speed here is not a separate service but a side effect of there being no surplus code to begin with.
Bought themes
Why they cost more
A bought theme looks cheaper right up until the work starts.
The hours go into the fitting
Somebody else's template takes longer to fit to a design and to test than writing one does: the further the design sits from the theme's standard layout, the more hours go into fighting it. Production contractors who build both say so themselves.
Changes live until the next update
Edits made straight into a theme are erased by its update. From there the choice is not to update — and keep the vulnerabilities — or to update and lose the work.
The author is a third party
A theme can be abandoned, sold or rewritten. The site is yours while the decision about its future is not.
Sometimes a bought theme is the right answer: the site is needed tomorrow, it lives a year, and the standard layout is enough. Then it is more honest to buy one than to dress the work up as development.
For agencies
You have the design
The studio draws; the code is written here. The design stays yours, and the theme is handed over with its repository.
The design is the source of truth
The work runs from Figma: the design's variables become the theme's variables rather than being rebuilt by eye. Inconsistencies in the design surface before the markup, not after the client has seen it.
Your process, not mine
A branch, a pull request, your review — or simply an archive with the theme in it, if there is no process. The second is no worse where it suits you better.
The client stays yours
The role here is technical: the code, and not the correspondence with your client, unless you want it otherwise.
The handover
What you receive
The code is yours
The source goes into your repository, the rights stay with you. Changing contractors is a change of access, not a negotiation.
Somebody else can pick it up
The WordPress coding standards, template names that say what they are, and no home-made machinery where the platform already has some. The test is simple: the next developer finds their way around the theme without phoning its author.
Documentation
A README with the build and the structure, the variables and the extension points described — so the theme can be changed deliberately rather than by trial.
Warranty fixes
Bugs found within a month of handover are fixed for free. After that — per request.
The price
What it is made of
An estimate against the volume
What is counted is not the calendar but the volume: how many templates, how many post types, how many blocks and fields. Describe the volume and the price and the date follow, both fixed.
What moves it
The number of unique pages against repeating ones, how deeply the editor is configured, work with somebody else's code. A child theme over a tidy bought one costs less than a theme from scratch; a child theme over one edited in place does not always.
After the launch
The warranty window is free. Then per request: a task, an estimate, the work. There is no retainer.
Questions
Before you write in
Nearby
Which page you need
Start
Fill in the brief
Send the design, or the address of the site that needs putting in order. The reply brings the questions about volume, an estimate and a date.