The website is live: thios.co
This isn't just a milestone post. I want to reflect on what it took to get here, why certain decisions were made, and what comes next.
What Launched
The launch includes three interconnected pieces:
Main Site (thios.co)
The primary website covers:
- Product information for each Thiosphere variant
- The philosophy behind the project
- Pricing and purchasing information
- Documentation and resources
The site is intentionally simple. No JavaScript frameworks for the main pages. Fast loading, accessible, functional on any device. The aesthetic deliberately echoes early 2000s open-source project sites — substance over flash.
Blog (blog.thios.co)
You're reading it. The blog documents:
- Build progress and lessons learned
- Design philosophy and decisions
- Technical deep-dives
- Community updates
The blog runs on a simple static site generator. Each post is a markdown file. No CMS complexity, no database for content. If the blog software disappeared tomorrow, all content would still exist as readable text files.
Store (store.thios.co)
The e-commerce piece where handbooks are sold. Stripe integration for payments. Digital delivery for PDF products. Eventually, physical products when we reach that phase.
The store is minimal — we sell a small number of products, so the interface is correspondingly simple.
Why Build a Website in 2024?
"Why not just use Gumroad/Substack/Notion/etc.?"
Fair question. Platform tools are mature. They handle hosting, payments, email, analytics. For many projects, they're the right choice.
I built a custom site because:
Control
Platforms change. Pricing changes. Terms of service change. Features get deprecated.
When you control the infrastructure, you control your destiny. If Stripe changes their terms, I can switch payment processors. If my hosting provider has problems, I can move elsewhere. The content and customer data belong to me.
For a project intended to exist for decades, this matters.
Open Source Alignment
The Thiosphere designs are open source. The website code should be too.
Every line of the site's code is available. Someone could fork the entire project — designs, documentation, and site — and run their own version. This is the point of open source: reduce single points of failure, enable community continuation.
Aesthetic Intent
The early 2000s open-source aesthetic isn't accidental. I wanted the site to feel like what it is: a technical project made by a small team, focused on function.
Achieving that aesthetic on Squarespace or Webflow would have been fighting the platform. Building custom gave freedom to express the visual philosophy directly.
Learning
I'm a generalist. Building the site taught me things:
- Modern PHP patterns (it's not just WordPress spaghetti anymore)
- Stripe integration mechanics
- Multi-language site architecture
- Email deliverability challenges
These skills transfer to other projects. The learning is part of the value.
Tech Stack Decisions
For the curious:
Backend: PHP 8.x with simple MVC patterns. No framework — just clean, organized PHP. The site is fast because there's almost no abstraction overhead.
Database: MySQL for user accounts and purchase records. Simple schema, simple queries. No ORM — just prepared statements.
Hosting: DreamHost shared hosting. Not glamorous, but reliable and affordable. The site is static-heavy, so shared hosting handles the load easily.
Payments: Stripe. Industry standard, good developer experience, trustworthy handling of customer payment data.
Blog: Markdown files processed at build time. No runtime database for content. Each post is a text file that would be readable even without the blog software.
Translations: 16 languages supported. Translation strings in PHP arrays, language detection via URL path. No translation management service — keeps things simple and doesn't require external dependencies.
The philosophy: use boring technology reliably. No cutting-edge frameworks that might not exist in five years. No complex infrastructure that requires constant attention. Simple, stable, maintainable.
What Took So Long
The site launched in December 2024. I'd been working on the project since early 2024. Why the gap?
Prototypes Came First
The site could have launched earlier with placeholder content. But what would it offer? Promises about products that didn't exist?
The prototypes had to work before the site could honestly describe them. Building working structures took priority over building a website about working structures.
Documentation Bottleneck
The handbook — the primary product — took longer than the prototypes.
Writing clear instructions is harder than building something yourself. Every step needs to be explicit. Every assumption needs to be stated. Edge cases need to be addressed. Photos need to be taken at the right moment in the build.
The handbook went through multiple complete rewrites as I discovered gaps in explanation.
Translation Complexity
Supporting 16 languages means every piece of visible text needs 16 versions. The initial site had hundreds of translation keys. Each key needed review by native speakers for critical pages.
This work happened in parallel with other development, but it constrained launch timing. Shipping with broken translations would have been worse than waiting.
Perfectionism Resistance
I had to actively resist perfectionism. The site could always be better. The documentation could always be clearer. The designs could always be refined.
At some point, you have to ship. "Perfect" never arrives. "Good enough to help people" is achievable.
What's Working
Early feedback suggests:
Loading speed: The site loads fast, even on slow connections. People notice this, especially after experiencing bloated modern websites.
Navigation clarity: Users find what they're looking for. The information architecture seems to match mental models.
Purchasing flow: Stripe checkout works smoothly. Digital delivery emails arrive. Downloads function.
Mobile experience: The responsive design works across devices. No complaints about mobile usability.
What Needs Work
Also from early feedback:
SEO: The site barely exists in search results. Content marketing, backlinks, and time will help. For now, most traffic comes from direct links.
Social proof: No testimonials from builders yet (the product just launched). Once builds happen, this content can be added.
Video content: Some people learn better from video than text. The current site is text-heavy. Video walkthroughs would help.
Community features: The Discord link exists, but community features aren't integrated into the site itself. Forums, build galleries, and discussion could enhance the experience.
These are known gaps, not surprises. They'll be addressed over time.
The Invitation
The website is live. The store is open. The handbook is ready.
If you've been following the project and waiting for launch — this is it. You can buy the handbook, start planning a build, and join the community.
If you're new here — welcome. Explore the site. Read the philosophy. Decide if this project resonates with you.
Website up. Store open. Let's build.
Visit the main site — explore products and philosophy.
Get the handbook — start your build.
Join the community — connect with other builders.