Custom development vs templates

Choose custom when the website has to do something specific to your business, rather than describe it.

Go custom if:

• Your process does not fit any existing plugin — quoting logic, complex bookings, a configurator
• You need to integrate with systems you already run
• Performance or SEO is a competitive weapon, not a checkbox
• The site is the product, not a brochure for it

Stay with a template if the site's job is to explain who you are, show your work and collect enquiries. That is most business websites, and paying for custom code to do it is money that would work harder somewhere else.

Usually not at the very beginning, and the reason is that you do not yet know what to build.

A new business changes its offer, its pricing and its target customer several times in the first year. Custom code freezes decisions; a template lets you change your mind cheaply. Spending $5,000 on a bespoke site before you have validated the offer is the most common way small businesses waste their launch budget.

The sensible sequence: launch on a solid template, spend the difference on getting customers, and move to custom once you know exactly which parts of your process the site needs to handle.

Four that are real, and one that is usually oversold.

Real:

• Speed. No unused code. Custom sites routinely load two to three times faster than template sites carrying features you never use.
• Exact fit. The site matches your workflow instead of you matching the template's.
• Security surface. Fewer third-party plugins means fewer known vulnerabilities.
• Scalability. You extend it instead of fighting it.

Oversold: uniqueness of design. A good designer can make a template look entirely distinctive, and visitors do not recognise templates. Pay for custom because of what it does, not how it looks.

Custom scales better in capability; templates scale better in cost at the start. Which one matters depends on where your growth comes from.

A template handles more traffic fine — that is a hosting question, not a code question. Where templates break down is more complexity: the fifth integration, the second business line, the workflow that no plugin supports. At that point each new requirement costs more than the last, because you are working around the template rather than with it.

The practical rule: if you expect the site's job to change substantially within two years, build custom. If you expect it to do the same job for more people, a template is fine.

When your business runs on a process that no off-the-shelf product models correctly. Typical triggers:

• You are coordinating work in spreadsheets that several people edit and that keep going out of sync
• You pay for three tools that each do part of the job and none of them talk to each other
• Clients ask you for status updates that you have to assemble by hand
• You have rules — pricing, availability, eligibility — that are specific enough that no plugin encodes them
• You are paying per-seat for software where most seats use 10% of the features

The economic test is simple: if the manual workaround costs more per year in hours than the app costs to build, build it.

A well-run custom project moves through five phases, and you should see something at the end of each:

1. Discovery. Your goals, your process, your constraints. Output: a written scope and a price.
2. Design. Structure first, then visual design. Output: screens you can react to before anything is coded.
3. Development. Built in blocks, with visible progress each week rather than a black box.
4. Testing. Speed, security, mobile, browsers, accessibility. Output: a report, not a promise.
5. Launch and handover. Publishing, training and documentation so you are not dependent on one person.

If a proposal does not name phases and deliverables, you have no way to tell whether it is on track.

Realistic timelines for a small business, assuming content and decisions arrive on time:

• Brochure website: 2–4 weeks
• Online store: 4–8 weeks, plus catalogue loading
• Simple web application (one core workflow, a couple of user roles): 6–12 weeks
• Complex application with integrations: 3–6 months

The variable that delays projects most is not development speed — it is content and feedback. Projects slip because copy is not ready, photos never arrive, or a decision waits three weeks for approval.

When we quote, we assume a specific feedback turnaround and say so. If that slips, the date slips with it, and we would rather tell you up front.

Ask one question: who edits this site, and how often?

If the answer is "me or my team, weekly", choose WordPress. Content editing is what it is best at, and a custom CMS rarely justifies its cost for a small business.

If the answer is "almost never, but it has to handle a process", choose custom. You are paying for behaviour, not for an editor.

A third option people forget: both. A custom application for the part that is genuinely specific to you, with WordPress handling the public pages and blog. That combination is often cheaper than forcing either one to do the other's job.