Entering the third week of my startup adventure has been a deeply rewarding time of solidifying foundations. Things come together to form an official brand, I put together tools to help with financial discipline, and I finished off the week by practicing my own Documentation-as-a-Contract (DaaC) framework. We Have a Name: Wabe Labs While I have an idea that I truly believe in and know exactly the components I need to build, I have been feeling excited about this venture before starting. But one question that would keep entering my mind, "What do you tell people your business is called?" If you've been following along, you know that I value structure. My development usually revolves around a folder structure on my laptop (~/Develop/${company}/${project}), and for years I used drunkendev for my personal projects, my original (un)professional handle. For this, I wanted a mature placeholder so had been using new-biz. For creating individual project names, I looked back to a tool I wrote years ago that generated secure passwords by pulling random words from Lewis Carroll’s Alice in Wonderland texts. It would generate some quirky password combinations and is fondly remembered for making people laugh. I was using this method to define names, with the help of AI I would ask "Could you suggest some names for a core software engine using words from Lewis Carroll's Alice in Wonderland books?" From this method, I codenamed my central project project-wabe. From then on, when I queried Gemini Notebook for architectural advice, it referenced "wabe" in its responses "within wabe you..." After bouncing the concept off a group of former colleagues and receiving positive feedback, the choice was clear. In Through the Looking-Glass, wabe refers to the grass-plot surrounding a sundial, so called because it extends a long way before it, behind it, and on each side. For us, it represents the ideal architectural metaphor: defining the clear space and precise boundaries around modern software systems. You can read the full story on our Behind the Name page. Securing the Digital Real Estate With the name chosen, the immediate next step was securing the online footprint. Fortunately, wabelabs.com was available at retail pricing, so I secured it immediately after a quick name availability check in Australia. Once the business registration was finalised, I also purchased wabelabs.com.au to be used as a redirect back to our main site. Making it Official To make the brand official, I activated a sole-trader Australian Business Number (ABN) and registered the business name through ASIC. Having secured the name I thought "Should I update my license headers from Brett Anthony Ryan?" I did a bit of sleuthing and learned a valuable legal lesson. As a sole trader, the business name is an operational identifier rather than a separate legal entity (which only comes with full incorporation as a Pty Ltd). For now, my personal name remains the contracting entity for my licenses and agreements, making this step both an operational milestone and a reality check on pre-incorporation setup. While it's true this is a simple step, completing this registration was a psychological turning point. Before taking the leap, there was always a lingering question: "Am I really going to become a founder?" Securing the name was a concrete declaration of commitment: This is it, I'm doing it. It shifted my mindset from "I'm attempting it" to "I'm doing it". With the name established, I created the Wabe Labs LinkedIn page, published an elegant landing page on wabelabs.com, and launched the Behind the Name feature content. Financial Discipline from Day One As I prepared my personal taxes for the end of FY26, it prompted me to think about establishing financial operations for Wabe Labs. So I set to, and built a structured Google Sheets workbook tracking income, expenses, and a stacked ledger with standardised file-naming patterns for instant cross-referencing. Opening a dedicated business bank account completely separated my personal and business finances. I have since run this setup by my accountant for review; having clean, audit-ready records from week three will make tax compliance and financial reporting effortless down the line. Practicing Documentation-as-a-Contract In my previous post, I detailed our Documentation-as-a-Contract AI Advisor Network, our strategy for establishing boundaries, using AI as an architectural advisor rather than a code generator. For this past week I really put this philosophy to the test while architecting what will become the core functional component that makes up our offering. My exercise was to explore the best format for structured Mermaid diagrams for optimal AI context parsing. By loading Mermaid documentation alongside our project requirements into Gemini Notebook, I established a constrained, high-fidelity context window. Through my interactions I got the warm and fuzzies as I realised, everything I've been preaching about creating constrained context windows for AI's created a precise hyper-focussed interaction that gives a much higher quality output. I had the feedback-loop model proved to be working as I iterated on my documentation. What emerged was a project that ticked all the boxes I was after: API Contracts (API.md): a project wabe-api-contract houses the external view of the projects gRPC and Protobuf service definitions that are published to my maven repository with java bindings. Auto-generated by protoc-gen-doc. API Interface: Pure Java interfaces and records defining immutable domain schemas. Right now, this isn't auto-generated, but the other way around; it's all been defined in my README.md that I used to create the project, and I may lift the UML documents into this document. API Bridge: Performing the bindings between model representation and wire representation, no project will need to do this on its own. Keeping it out of interface meant that interface remains pure, and keeping it out of contracts means that contracts has no transient dependency on the java records and interfaces. Pulling this together felt extremely satisfying. In a world where so many are getting AI to generate code for them, I'm taking a completely different approach that may seem strange and less efficient, but I argue, that right now, I know exactly what my software is doing, how it's structured, and that structure came directly from me. I definitely used help, but the AI was helping me, not me instructing the AI. Where to Next? Now that my foundations are stable, I'm left to concentrate on the build of my core project Gyre: our feature execution engine. It's still funny thinking about it. All my career I've worked inside an established enterprise building with networks, VPN's with cloud providers wired in a hub-and-spoke architecture. Now, I'm starting with a clean slate, exploring how to build that brick and mortar foundation myself. As I think about how I might interact with Gyre running in my cloud environment, I think "Will I need to set-up an AWS Client VPN and Route 53?" Knowing that this can have a minimum cost of $100 a month, I'm looking for cheaper alternatives, and I think I might have discovered that with my current VPN provider, I might have a way with NordVPN's Meshnet to be able to provide this same capability for only a few dollars of additional AWS components.