Milestone, November 2, 2026: where The Bailey Perspective is headed and what it will take to get there. This one: See the first stranger fork Walkable City (target: Winter 2026–27).
We’re aiming for a milestone that will let us know the Walkable City engine is truly usable by people outside of our team: 100 GitHub stars and a fork that we didn’t create. We share this because the journey to that point is a concrete example of how a small studio can turn a product into a community asset.
Why it matters
The engine behind Client City is the core of many of our projects, and we released it as a single‑file Three.js template under the MIT licence on October 19, 2026. We believe that an open‑source project only becomes real when other people build on it. For us, reaching this milestone would mean that our code is not just a private tool but a foundation that others can adapt, extend, and learn from. For the businesses we serve, the engine’s openness translates into faster iteration and lower cost. If a small team can fork the project, tweak a building style, and deploy a new city layout in a fraction of the time it would take to build from scratch, then the value of our services is amplified. It also signals that we’re committed to transparency and collaboration, which can be reassuring for partners who need to trust that we’re not just shipping code that only we understand.
Where we are today
The repository is public, and the release page and demo are live on our website. We announced the launch on the three.js forum and LinkedIn, and a pull request has added the project to the awesome-threejs list. However, the code still needs polishing: the documentation is minimal, the demo could use a short walkthrough video, and we haven’t yet responded to every issue that has been opened. We also haven’t published any new building styles since the release, so the community has no fresh content to explore on a regular basis. The project’s visibility is limited to the initial announcements; we haven’t yet reached a wider audience of developers who might be interested in using or extending the engine.
What it takes to get there
First, we’ll answer every open issue promptly. Responding quickly builds trust and keeps contributors engaged. Next, we’ll create a short video walkthrough that shows a basic workflow: importing the template, adding a building style, and rendering a simple street. That video will serve as a low‑barrier entry point for new users. After that, we’ll submit the project to Show HN, which will expose it to a larger developer community and increase the likelihood of receiving forks. Finally, we’ll ship one new building style each month. By delivering fresh content regularly, we give people a reason to revisit the repository and keep the momentum going. The main risk is that our team’s bandwidth is limited. If we’re pulled into client work or other internal priorities, responding to issues or creating new styles could slip. We’ll mitigate this by allocating a fixed amount of time each week—say, two hours on issue triage and one hour on content creation—to keep the project moving forward.
One thing you can borrow
A clear, measurable target—like 100 stars and an external fork—helps a business owner focus on the specific actions that drive progress. By committing to a regular cadence of updates and quick issue resolution, you create a predictable path toward that goal.
We will report back here when it is reached. Until then, the Studio Log carries the week-to-week progress.