How I built this website
In my twenty-five years of writing JavaScript, I have watched the ecosystem evolve from simple form validation scripts to complex application architectures that rival desktop software. If there is one lesson that a quarter of a century in this industry teaches you, it is that dogmatism is the enemy of delivery. There is no single perfect tool for every problem.
That is why, when building this project, I chose a polyglot approach. Rather than forcing a single framework to handle disparate requirements, I selected the best tool for each specific domain. The content site is built with Astro and hosted on Cloudflare Workers. The meetings application uses Next.js on Vercel. The admin dashboard is powered by SvelteKit, also on Vercel. The mobile app is built with React Native and Expo.
Here is the reasoning behind these choices.
The Content Site: Astro on Cloudflare Workers
For the public-facing content site, my primary requirements were performance, search engine optimisation, and a content-focused development experience.
I chose Astro because it represents a return to sanity for content websites. After years of shipping heavy JavaScript bundles just to render static text, Astro allows us to ship zero JavaScript by default. It adopts an ‘island architecture’, meaning we only hydrate the interactive components while the rest of the page remains pure HTML and CSS.
Hosting this on Cloudflare Workers was a strategic decision for speed. Workers allow the site to run on the edge, serving content from locations physically closer to the user. The combination of Astro’s static output and Cloudflare’s global network results in near-instant page loads.
From an experienced developer’s perspective, this stack feels robust. It avoids the fragility of complex client-side hydration for pages that never needed it in the first place. It honours the fundamental grain of the web.
Another decisive factor was Astro’s handling of content through Content Collections. In the early days, managing Markdown often felt like a fragile exercise in string parsing, prone to runtime errors. Astro brings type safety to this domain by validating frontmatter against a defined schema at build time. If a date is malformed or a required field is missing, the build fails immediately. Combined with first-class support for MDX, which allows me to embed interactive components directly within my prose, it offers an authoring experience that is both robust and flexible.
The Meetings Application: Next.js on Vercel
The meetings application is a different beast entirely. It is highly interactive, stateful, and requires a rich ecosystem of existing libraries to handle functionality like real time video conferencing and authentication.
For this, I chose Next.js. While I appreciate the simplicity of other frameworks, the React ecosystem is undeniable when building complex applications. Next.js provides the necessary structure: server-side rendering, routing, and API handling out of the box. It is the industrial-grade choice, with plugins for the packages I required.
Hosting on Vercel is the natural pairing for Next.js. It removes the friction from the deployment pipeline, allowing for seamless preview environments and serverless scaling.
Why would a veteran choose React here? Because for mission-critical, complex interactive software, you want the tool with the largest community and the most solved problems. You do not want to be reinventing a date-picker when you should be focusing on business logic.
The Admin App: SvelteKit on Vercel
For the admin dashboard, I had more freedom. This is a tool used for data management, requiring many forms, data tables, and rapid user interactions.
I chose SvelteKit. Svelte’s reactivity model is intuitive and requires significantly less boilerplate code than React. In an admin context, where you are constantly binding form inputs to state, Svelte feels magical. It gets out of your way.
Hosting on Vercel ensures it benefits from the same reliable infrastructure as the meetings app.
The choice of SvelteKit here is also a nod to developer happiness. After twenty-five years, you want to enjoy the code you write. Svelte brings a joy to development that reminds me of why I started coding. It is fast, efficient, and lacks the complexity that has accrued in older frameworks.
The Mobile App: React Native on Expo
Finally, for the mobile experience I turned to React Native, orchestrated by Expo.
In the past, cross-platform mobile development was a compromise—a web view wrapped in a native shell. React Native changed that paradigm by rendering to genuine native UI components. It offers the performance users expect with the developer experience I prefer.
Using Expo was a choice for sanity. It handles the native build pipelines and device permissions, allowing me to focus on the application logic rather than Xcode configurations or Gradle scripts. Furthermore, it allows for significant code reuse with the web platform, particularly for business logic and state management. It is the efficient choice for a solo developer shipping to multiple platforms.
Conclusion
It might seem inconsistent to use four different frameworks for one project. However, this separation of concerns allows each part of the system to excel. We do not burden the blog with the weight of a React app, and we do not constrain the complex meeting logic with the limitations of a static site generator.