Hand built website development with a real performance budget
Design decides what the site says. Development decides whether it loads, works on a patchy 4G connection in regional NSW and can be edited without breaking. We build the second part by hand.
What is website development?
Website Development is the engineering stage that turns an approved design into a working, accessible, fast site. It covers front end code, templating, content modelling, integrations, testing and deployment. It suits Australian organisations that need a site to hold up under real traffic and be maintained by their own team afterwards, not just look right on launch day.
Get a fixed written quote- Typical timeline
- 5 to 10 weeks
- What drives cost
- The main cost drivers are the number of templates, the integrations and the depth of testing required.
- Best for
- Sites where speed, accessibility and long term maintainability matter
- You own
- The repository, the hosting accounts and every credential
- Built with
- Next.js, Astro, TypeScript, Core Web Vitals budgets
Your handover
What a performance budget commits us to
Most agencies say fast. A budget makes it checkable. Before we write code we agree numeric targets for the pages that matter, typically Largest Contentful Paint under 2.5 seconds and Interaction to Next Paint under 200 milliseconds on a mid range Android handset over a throttled connection, plus a ceiling on the JavaScript shipped to a first time visitor. Those numbers go in the scope document and get tested in continuous integration, so a build that breaks the budget fails before it reaches you.
- 01Production repository with commit history
- 02Component library implemented in code
- 03Content models and editor guardrails
- 04Automated performance and accessibility checks in CI
- 05Cross browser and assistive technology test results
- 06Redirect map applied and verified
- Deployment documentation and recorded walkthrough
- Monitoring and error reporting configured
- All hosting and service accounts in your name
The reason to be strict is that Australian browsing conditions are not uniform
The reason to be strict is that Australian browsing conditions are not uniform. A buyer on the North Shore with fibre has a very different experience from a site foreman on a Toowoomba job site with two bars. The second visitor is the one who abandons, and abandonment is invisible in most analytics setups unless someone has deliberately instrumented it. Getting that instrumentation right is part of analytics implementation, and we usually wire it during the build rather than after.
The reason to be strict is that Australian browsing conditions are not uniform.
Accessibility and semantics in the code, not just the design
A design can be accessible and the build can still fail. We check the things that only exist at code level: heading order that never skips a level, landmarks so a screen reader user can jump to the main content, focus that lands somewhere sensible after a modal closes, form fields tied to their labels programmatically, and dynamic content that announces itself rather than changing silently.
More on accessibility and semantics in the code, not just the design
We test with a keyboard and with a screen reader on every project, because automated tools catch roughly a third of real problems and confidently pass pages that are unusable in practice. If you serve older Australians, people with disability, or you deliver services under the NDIS, this is not a nice to have. It is the difference between a participant completing a referral form independently and having to ring you. Providers building in that space usually pair this work with sector specific requirements we scope up front.
How the engagement runs
How the build runs from kickoff to launch
We work in visible increments on a staging URL you can open at any time. There is no long silence followed by a reveal, because a reveal is where scope arguments happen and where a fortnight of rework gets invented.
- 01Technical discoveryIntegrations, data sources, redirects to preserve, hosting constraints and any compliance requirements
- 02Environment setupRepository, staging, preview deployments and automated checks for performance and accessibility
- 03Component buildThe design system implemented as code, reviewed in isolation before pages are assembled
- 04Templates and content modellingPage types, fields and editor guardrails so authors cannot produce a broken layout
- 05IntegrationsForms, CRM, payments, booking or whatever the site genuinely needs to talk to
- 06Quality assuranceCross browser and cross device testing, keyboard only navigation, screen reader pass, broken link sweep
- 07LaunchDNS cutover with reduced TTL, redirect verification, monitoring switched on and a rollback path kept ready for a week
Two decisions on your side that keep the project moving
Content is the dependency that most often moves a launch date, and it is almost never the development. We ask for final copy and images by an agreed point in the schedule, load it into staging as it arrives, and flag anything that does not fit the layouts it was written for. Building with placeholder text right up to launch week is how sites go live with lorem ipsum in a footer nobody checked.
The comparison
Hand built front ends compared with page builder output
The debate is not about craft for its own sake. It is about what happens to page weight and markup when a visual builder generates the HTML for you, and about who can change things later without breaking something else.
Hand built front end
- Page weight
- Only the CSS and JavaScript that page uses
- Markup quality
- Semantic elements, correct heading order, real landmarks
- Editing by your team
- Editing constrained to defined blocks, hard to break
- Long term cost
- Higher at build, lower per change afterwards
- Lock in
- Portable code you own outright
Visual page builder
- Page weight
- Global bundles loaded on every page regardless of need
- Markup quality
- Nested containers that screen readers have to work around
- Editing by your team
- Anything can be moved, which is freedom and risk in equal parts
- Long term cost
- Lower at build, rising as workarounds accumulate
- Lock in
- Tied to the builder plugin and its future
Where the choice usually lands
Neither column is universally correct. Builders exist because they solve a genuine problem for organisations without developer access, and dismissing them wholesale is posturing. The comparison below is meant to help you work out which set of trade offs suits your team, your publishing habits and how long you intend to keep this site running before the next rebuild.
What happens to the site after launch
Website development does not finish at launch, because a site is a running system rather than a delivered object. Dependencies get security patches, browsers change behaviour, and the content your team adds in month four will stress layouts nobody tested in month one. We hand over a repository with a readme that a competent developer can act on, documented environment variables, and a short recorded walkthrough of the deployment process.
Either way the accounts are in your name
From there you can maintain it yourself, use your internal team, or put it on a retainer with us. Either way the accounts are in your name. We are happy to be the ongoing partner, but the arrangement should be a choice rather than a consequence of holding your credentials. Most clients combine maintenance with managed hosting so patching and performance monitoring sit with one party, which shortens the conversation when something breaks at 6pm on a Friday.
When a simpler platform is the honest answer
If you publish two pages a year, sell nothing online and have no integrations, a custom front end is more machinery than your situation needs. A well built WordPress site with a disciplined theme will serve you at a lower total cost and your team will find it familiar. We would rather tell you that during scoping than build something you will resent maintaining.
The rest of the answer
Custom website development earns its cost when at least one of these is true: performance is commercially material, the content model is unusual, you need real integration with a back office system, or the site is a product surface rather than a brochure. If you are heading toward the last of those, the conversation is really about web application development, and the architecture decisions differ enough that it is worth having early.
How we scope it
Four ways to scope your Website Development project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Website Launch
A credible site, built properly, live sooner
Fixed written quote, agreed before work starts
- Production repository with commit history
- Component library implemented in code
- Content models and editor guardrails
Website Growth
A site that has to sell or integrate with something
Fixed written quote, agreed before work starts
- Everything in Website Launch
- Automated performance and accessibility checks in CI
- Cross browser and assistive technology test results
- Redirect map applied and verified
Website Platform
A large site, or one built around your operation
Fixed written quote, agreed before work starts
- Everything in Website Growth
- Deployment documentation and recorded walkthrough
- Monitoring and error reporting configured
- All hosting and service accounts in your name
Website Care
Keeping it fast, patched and improving
Rolling monthly, quoted in writing
- Hosting, patching, backups and uptime monitoring
- Content and design changes as you need them
- Core Web Vitals watched, not assumed
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
Ownership and handover
Who owns the code and the hosting accounts?
You do, without conditions. The repository is created under your organisation or transferred to it, hosting and third party service accounts are registered in your name with your billing details, and We work under collaborator access you can revoke without asking us. If our relationship ends, nothing needs to be handed over because it was never held hostage in the first place.
What do you do if performance drops after launch?
Budgets are enforced continuously, not once. Monitoring reports field data from real visitors, so a regression from a new script, an oversized image or a marketing tag shows up within days. Third party tags are the usual culprit. We identify the offender, quantify its cost in milliseconds, and give you the trade off in plain terms so marketing and engineering can decide together.
Detail and edge cases
How long does website development take?
Allow 5 to 10 weeks between sign off on design and going live. Component build and templating take the bulk of it, with about a week reserved for quality assurance and launch. Integrations move the number most, since a CRM or booking connection with unclear requirements can add a fortnight. Those dependencies surface in technical discovery, not halfway through the build.
Why does development cost more than a template build?
Because the work is different. You are paying for code written for your content model, tested against a performance budget, checked with a screen reader and documented well enough that another developer can pick it up. The main cost drivers are the number of templates, the integrations and the depth of testing required. The written quote comes after discovery, and the number stands for the agreed scope.
Can you work with our existing design or in-house designer?
Yes, and it usually goes well when we join before the design is finalised. We review the files for implementation risk, flag components that will be expensive for the value they add, and agree token naming with your designer so the handover is unambiguous. If the design is already signed off we will still build it, we just note any performance or accessibility issues in writing first.
Do you build multilingual or multi region sites?
Yes. For Australian organisations this usually means an English site with community language pages rather than full localisation, which changes the technical approach considerably. We set up correct language markup, sensible URL structure and a translation workflow your team can actually sustain. Half finished multilingual sites cause more search problems than they solve, so we scope the ongoing effort honestly before you commit.
Related services
Ready to scope the build?
Send through the design, the integrations and whatever deadline you are working to. You will get a technical response within one business day and a fixed written quote with the performance targets stated in it.