TekOnline.com.au is a small technical website and online shop built around a simple idea: useful engineering work should be documented clearly enough that someone else can build on it.
That sounds straightforward until the site includes products, firmware, installation guides, customer questions, analytics, stock control, and the occasional infrastructure problem. At that point, “the website” is no longer just a collection of pages. It becomes a small operating system for a maker business.
This article explains how I think about managing TekOnline without exposing private infrastructure details, customer information, credentials, or internal network configuration.
The website has three jobs
TekOnline has to do three different jobs at once:
- Explain technical products and projects.
- Let customers buy the things that are available.
- Preserve the reasoning behind the work through useful articles.
The best result is when those jobs reinforce each other. A product page explains what a device does. A setup guide helps someone install it. A project article shows why it exists. The shop then gives the reader a practical next step without turning every article into an advertisement.
A content-first structure
The site is managed as a set of connected content types:
- Product pages for specifications, pricing, stock, compatibility, and purchasing.
- Blog posts for build notes, troubleshooting, experiments, and lessons learned.
- Setup guides for details that need to be followed in order.
- Firmware and configuration references for repeatable technical work.
- Internal management notes for stock, publishing, deployment, and follow-up tasks.
Keeping those roles separate makes maintenance easier. A product description can stay focused on the buyer, while a technical article can explain the underlying decisions in more depth.
Managing products like small releases
Each product change is treated more like a software release than a one-off edit. Before publishing, I check:
- What changed in the hardware or firmware.
- Which versions are compatible.
- Whether the photos and diagrams match the current revision.
- Whether stock and lead-time wording is accurate.
- Whether the product links to the relevant guides.
- Whether the guides link back to the product where appropriate.
This is especially important for hardware that evolves over time. A clear “current version” label prevents an older article or cached search result from becoming the customer’s main source of truth.
Automating the repetitive work
Routine website management is a good candidate for automation. Publishing scripts can prepare or update posts and products through the website’s supported API, while credentials remain outside the public source and documentation.
Automation is useful for repeatable changes such as:
- Updating product descriptions and structured data.
- Applying consistent links between related pages.
- Checking whether a post already exists before creating another one.
- Reviewing product and order information for management reports.
Automation still needs a review step. A script can update the right record and still put the wrong emphasis in a paragraph, use an outdated photo, or describe stock incorrectly. The reliable workflow is preview, inspect, apply, and verify on the live page.
Separating public and private information
A public technical blog should explain methods without publishing the keys to the workshop.
That means keeping these out of public articles:
- Passwords, API keys, application passwords, and private tokens.
- Customer names, email addresses, order details, and private correspondence.
- Internal IP addresses, private hostnames, VPN addresses, and firewall rules.
- Storage paths, backup locations, and administrative access instructions.
- Unreleased product information or operational notes that are not ready for customers.
The public version can still be useful. Instead of publishing a real endpoint, describe the role it plays: “the internal printer hostname,” “the private management interface,” or “the authenticated deployment server.” Readers learn the design principle without receiving a map of someone else’s network.
Infrastructure is part of publishing
Publishing a post is not complete just because the editor reports success. I also want to know that:
- The page loads normally.
- Images have useful alt text and reasonable file sizes.
- Internal links resolve.
- The page has a sensible title and description.
- The article works on a phone as well as a desktop.
- The public site is not exposing a management interface or secret value.
This is where monitoring and deployment records help. A small site does not need an enormous platform, but it does need a clear answer to “what changed, when did it change, and how can I undo it?”
The lesson from a small printer failure
One recent example came from a networked 3D printer used for prototypes and small product runs. The slicer could still reach the printer’s web interface, but the print API was unavailable. The cause was not the hostname or the slicer: a required service configuration file had disappeared, so the printer’s Moonraker service could not start.
The recovery was simple once the failure was identified:
- Confirm name resolution and the separate web and API roles.
- Inspect the service log instead of guessing at the client error.
- Restore the service configuration from its local backup.
- Restart the service.
- Verify the API, printer state, and web interface independently.
The camera feed was a separate service, which is another useful reminder: one green interface does not prove that every backend component is healthy.
A practical management rhythm
The most sustainable approach is a short maintenance loop:
- Record meaningful changes while they are fresh.
- Keep public writing separate from private operational notes.
- Use scripts for repetitive, testable updates.
- Check the live result after deployment.
- Keep backups before editing configuration.
- Review old pages when a product revision changes.
- Treat monitoring alerts as investigation prompts, not as proof of root cause.
None of this requires a large company or a large team. It is mostly about reducing the number of things that depend on memory.
Closing thought
TekOnline works best when the shop, the documentation, and the engineering process are treated as one connected system. The products create questions. The questions become guides. The guides build trust. The management work keeps the whole loop accurate.
That is the real purpose of the site: not just to list parts, but to make practical technical work easier to understand, reproduce, and improve.