Nearly every business owner we build a website for asks some version of the same question once the site is live: “can I change this myself?” Usually they are pointing at a price, a photo, or the opening hours over a public holiday — small things, all of them urgent to the business, none of them worth waiting on a developer for.
The answer is yes, and this article is about what that costs. Short version: expect 20–30 hours of setup work depending on complexity, starting from around $1,500 AUD for consultation and implementation. The rest of this explains what you get for that, and what makes a build land at the top of the range instead of the bottom.
What an “owner-editable admin console” actually is
It is a private page on your own site — usually /admin — that only you and the people
you nominate can reach. You sign in, you see the parts of your site that are meant to
change, you change them, and you press Publish.
What it is deliberately not is a full website builder. You are not given the layout, the fonts, the navigation or the code. That is the entire point: the console exposes the handful of things that genuinely move in your business and locks everything else, so there is no way to accidentally break the site while fixing a price.
For a restaurant, “the things that move” is a short and obvious list — menus and prices, photos, opening hours. For a trades business it might be the service area and the current list of jobs. For a clinic it might be the practitioner list and the fee schedule. Working out that list with you is genuinely half the job, and it is the part that determines whether the console gets used or ignored.
The worked example: China Tea Club
China Tea Club is a 40-year-old Chinese restaurant in Canberra, and they were the first client we built one of these for. Their owner agreed to let us show it.
Before the console, every menu change came back to us as a message. Nothing hard, but everything sat in a queue. Now the restaurant edits its own menus, prices, photos and hours, and the site rebuilds itself.
Two details from that build matter more than they sound. The first is that there is no password — you type your email address, a short code arrives in your inbox, you type it in. Restaurant staff do not need another password, and a shared password on a sticky note behind the till is worse than no password at all.
The second is what happens on Publish.
Every publish is one tracked change: who did it, when, and exactly what moved. Because it is one change, it can be undone as one. If a price goes in wrong at 6pm on a Friday, the previous version goes straight back up.
The full write-ups are here: the admin console and the website build that came before it.
How we build them
The shape is the same every time, and it is worth understanding because it is what keeps the ongoing cost low.
A static site, not a database-backed CMS. Your pages are plain HTML files served straight from a global edge network. Nothing is assembled on request, so there is no database to keep alive, no plugin to patch on a Tuesday, and nothing sitting on the public internet waiting to be exploited. It is also very fast and very cheap to host.
A secure email-code login. No passwords to manage, share or leak. Only addresses on your approved list can request a code, and a code is short-lived and single-use. Removing someone’s access is removing their email address from a list.
Every publish is one tracked, reversible change. Your edits are committed as a single recorded version rather than written over the live site. That gives you a history of who changed what, and a rollback that is a button rather than a phone call.
An automatic rebuild. Pressing Publish kicks off a rebuild of the static site and a redeploy. For a site the size of a restaurant’s, the change is live in about a minute. You do not do anything; you just refresh.
The trade-off worth naming: because the site is rebuilt rather than rendered on demand, your change is not instantaneous. A minute is not the same as a second. In exchange you get a site that cannot go down because a database did, and a hosting bill that is close to nothing.
Where the 20–30 hours goes
The number that surprises people is how little of the effort is the console itself. A typical build breaks down roughly like this:
- Working out what should be editable. Sitting down with you and deciding what is genuinely dynamic, what should stay locked, and who is allowed to touch it. Get this wrong and you have either built a console nobody uses or one that lets a Tuesday afternoon break the homepage.
- Modelling the content. Turning “the menu” into a structure — sections, dishes, descriptions, prices, availability, photos — that is both faithful to how you think about it and stable enough to build a site on.
- Building the editing screens. The forms themselves, on a phone as much as a laptop, because that is where a restaurant owner actually is when they notice something is wrong.
- Authentication and access control. Email-code login, the approved-address list, and making sure the console is genuinely unreachable to everyone else.
- The publish and rollback path. Wiring publish to a tracked change, the automatic rebuild, and testing that a rollback really does put things back.
- Handover. Walking you through it, watching you do a real change, and fixing the two things that were obvious to us and not to you.
What pushes a build toward 30 hours rather than 20 is usually the second item, not the fourth: content that is genuinely complicated (multiple menus with seasonal variations, per-location hours, multilingual pages) takes longer to model well. More editable areas, more user roles, or an existing site whose content has to be migrated in will push it too.
Pricing, plainly
Consultation and implementation start at around $1,500 AUD. That covers the scoping conversation, the content modelling, the console, the login, the publish-and-rollback path, and the handover, for a site with a straightforward set of editable areas — which is most small businesses.
Builds go up from there with complexity. If you have several distinct content types, a number of people who need different levels of access, or an existing site whose content needs migrating, we will scope it and give you a fixed number before anything starts. We would rather quote you properly than surprise you.
Hosting for a static site of this kind is a small monthly cost, and we will tell you what it is up front rather than folding it into something vague.
Is it worth it for your business?
The honest test is frequency. Count the changes you would have made to your website in the last three months if asking had been free — not the ones you actually requested, the ones you decided were not worth the bother. If that number is more than a handful, a console pays for itself quickly, mostly in the changes you stop not making.
If your site genuinely changes twice a year, it does not. You are better off with a good static site and emailing us when something moves, and we will tell you so rather than sell you a console you will log into once.
Talk it through
If you can tell us what parts of your site you would want to change and roughly how often, we can give you a real number rather than a range. Get in touch — the scoping conversation is where this either becomes obviously worth doing or obviously not, and either answer is a useful one.