2 Geeks Web Design
How building an R2-D2 droid sharpened our web design process
Many owners running a busy cafe in Brisbane or a small tradie outfit near Wollongong don't expect a Star Wars droid to teach them anything useful about their website. Yet that is exactly what happened at 2 Geeks Web Design, a small studio in Princeton, Illinois, that has logged every nut, bolt, and solder joint of building a life-size R2-D2 inside a public journal called Project Astromech. The same minds writing CSS and debugging PHP for small business clients have spent years reverse-engineering servos, motor controllers, and radio gear. The crossover turned out to be larger than anyone first thought.
Engineering logic rarely stays neatly inside one discipline. The way a builder thinks about a drive base, a power distribution board, or a wiring harness translates surprisingly well to the way a web studio should think about navigation, hosting, or content hierarchy. Where small business owners tend to get stung is by treating their website like a single lump of marketing rather than a system of connected parts. Seeing how a droid is built exposes how lazy that thinking really is.
This piece walks through five lessons carried straight from the Project Astromech workshop into client websites. Each one solves a frustration that keeps showing up in conversations with Australian small business owners, from solo accountants in Adelaide to boutique retailers in Hobart. None of them require a degree in electronics. They do, however, reward anyone willing to think a bit more like a maker.
2 Geeks Web Design has spent the past decade turning these ideas into practical workflows for shops, professional services, and trades. The points below come from real builds, real client launches, and the late-night problem-solving that bridges both worlds.
| Engineering approach used in R2-D2 | Parallel in custom web design | Outcome for small business owners |
|---|---|---|
| Modular subsystems (drive base, dome, electronics) | Modular templates and component libraries | Faster updates and consistent branding |
| Bench testing before any flight | Staging environments and progressive rollouts | Fewer broken features on launch day |
| Wiring diagrams and circuit labels | Clean code documentation and naming conventions | Easier handovers to future developers |
| Calibration logs for servos and motors | Performance budgets for page speed and images | Better search visibility and visitor retention |
Thinking in subsystems rather than single pages
The first thing you notice building a life-size droid is that nothing works until lots of small pieces start talking to each other. The drive motors need a controller board, the controller board needs power, the dome rotation needs a separate signal path, and so on. A robot built as a single black box would be impossible to fix on the road. Treating a website the same way turns out to be just as risky.
Small business sites often arrive at 2 Geeks Web Design as one tangled folder of images, half-edited pages, and a WordPress install from 2017 that nobody dares touch. Splitting the site into modular components — header, footer, contact block, service grid, blog feed — changes how the client thinks about their own content. Updating the opening hours no longer risks breaking the homepage. Adding a new service offering becomes a twenty-minute job rather than a weekend lost.
Business owners juggling multiple locations across Sydney, Perth, or regional Victoria feel this benefit straight away. A single source of truth for the brand means the Ballarat team and the Bendigo team publish from the same well of approved content. The droid taught us that modularity is cheaper than heroism.
Prototyping before anything goes live
Every R2-D2 builder worth their soldering iron runs the droid on blocks for hours before letting it touch the floor. Wheels spinning in mid-air catch wiring faults, misaligned sensors, and software glitches long before they become embarrassing videos. The same cheap, repeatable testing loop is pure gold for a website that will be judged by real visitors within seconds of loading.
Most studios skip this step because clients are impatient. "Arvo mate, can we just push it live?" is something we have heard from more than one owner-operator who wanted the page up before the weekend trade. Pushing back with a proper staging pass, a checklist, and a real-device test is the only way to keep quality intact without slowing things down too much. Tradies, in particular, respect the rigour because they already run their own job sheets the same way.
A reliable pre-launch pass covers the basics:
- Spelling, links, and phone numbers checked on every page
- Forms submitted end to end on real mobile data
- Image weights measured against the performance budget
- Browser console scanned for errors before the public switch
Prototyping also helps the client see what they are paying for before the work disappears into a server. A short loop of feedback cycles, captured in writing, replaces guesswork with a paper trail that both sides can trust. Anyone who has argued about whether "the buttons should be bigger" after launch knows how valuable that trail becomes.
Documentation as ongoing maintenance
Anyone who has owned an old droid will tell you the wiring diagram is worth more than the droid itself. Without it, every repair becomes archaeology. Project Astromech forced the 2 Geeks team to write everything down as they went — pin assignments, fuse ratings, motor curves, controller firmware versions. That habit quietly transferred into client handovers.
A custom website that arrives without documentation is a future support ticket. Folder names that say nothing. CSS classes called .blue-text-big. No record of which plugin was patched or why. The cost of those small shortcuts shows up six months later when someone else tries to update the site and gives up. Owners end up paying for what should have been a five-minute fix.
What a clean handover should always contain:
- A short README explaining the file structure
- Login credentials stored in a shared password manager
- A change log of major updates since launch
- Contact details for every third-party service the site depends on
The lift that good documentation provides is felt hardest by small teams. A two-person accounting practice in Geelong shouldn't need to ring the original developer every time a staff member changes. A clear file map, a screenshot of the admin, and a brief update plan solve that problem for years. Documentation is the cheapest insurance policy a website will ever carry.
Hardware and software as one conversation
Droids break in interesting ways when the electronics fight the mechanics. A wheel that turns the wrong way under software control is a hardware bug, a software bug, and a wiring bug all at once. Resolving it means treating both sides as one system rather than two disciplines that happen to share a chassis. The same thinking applies to a website that bundles hosting, plugins, design, content, and SEO into one fragile pile.
The clearest example sits in remote control work. Programming a wireless controller to a moving droid involves latency, signal failure, fail-safes, and user ergonomics at once. The detailed notes from our build of the R2-D2 remote control system walk through how every input had to travel cleanly through several layers without losing meaning. A contact form on a tradie's site should behave the same way — predictable, fast, and impossible to misfire.
Australian SMBs often run stacks that include booking apps, accounting connectors, marketing automation, and a CRM, all sitting behind the same contact form. Treating those connections as one integrated system, instead of a list of plugins to install, is what keeps them stable. The droid build proved that integration done with intent always beats integration done with hope.
Showing clients what they will actually see
Builders sketch before they cut. Engineers diagram before they manufacture. Web designers should mock up before they code. Project Astromech ships every milestone with photographs, dimension notes, and short videos of the droid at each stage of assembly. That visual record gives collaborators something real to react to.
A flat feature list on a quote never tells a small business owner what their finished site will feel like. Wireframes, clickable prototypes, and a quick walkthrough video on the laptop during a morning catch-up — "brekkie" with the client in Sydney parlance — close that gap fast. Many Australian owners have told us that the prototype stage was the moment the project stopped feeling abstract and started feeling like something they could actually run.
Visual models also defuse the most common web project argument: "I thought it would look different." A reference image beats a thousand meetings. Clear previews convert uncertainty into feedback, and feedback into shipped work. The droid workshop treats that loop as sacred, and so does the studio.