Case Study 01 · Jan Tekieli · Personal trainer
From the first conversation to Google results in 13 days.
In a matter of days, Jan and I built more than a personal trainer website. We created the foundation for long-term Google visibility: listen first, make the direction tangible quickly, then align every iteration with clients and local SEO.

Jan is a personal trainer in Kraków with deep expertise and a very specific way of helping people who are often afraid to take the first step. What he lacked was a place online that told this story in his own voice while systematically building local visibility.
We did not start with technology
The first step was a straightforward interview. We discussed who Jan trains, what clients worry about, how the free consultation works, and what is genuinely different about his approach. We also reviewed his social channels, where his natural voice, photos, reviews, and first brand signals already existed.
Using this material, we created the first website direction in Lovable. We did not wait weeks for a complete brief or perfect wireframes. The goal was to have something working within days that Jan could see, judge, and correct.
The first version started the real conversation
Jan reviewed successive versions and said plainly what sounded like him and what did not. We corrected offer descriptions, training plans, consultations, pricing, working hours, and how the studio was presented. Even individual phrases changed when they felt too technical or unlike the way Jan speaks with clients.
Design was not a separate phase locked before implementation. It evolved together with the content. We first established a clear core: who Jan is, whom he helps, how he works, and how to take the first step. Then we progressively added the offer, client reviews, videos, FAQ, certificates, contact form, and further pages.
SEO designed as a system, not a one-time optimization
From the start, I worked across two horizons. The website needed to begin answering local searches quickly, while its structure also had to support growth over the following months. I analyzed search behavior, competitors, and local intent. Instead of trying to rank one generic page for the competitive phrase "personal trainer Kraków," I built dedicated pages for specific local searches, including Ruczaj, Kliny, Dębniki, Skotniki, Kobierzyn, and Borek Fałęcki. This allows Google to match the right page with someone looking for a trainer in their area.
I also added service pages for individual, duo, online, and hybrid training, plus content for beginners, women, men, and seniors. Jan planned the article topics using his expertise and everyday conversations with clients. I advised him on what mattered most: speaking the clients' language, naming their real problems, and answering the needs they bring to a trainer. This collaboration produced several valuable articles covering trainer costs, the first session, fear of the gym, and the time needed to see results.
The technical layer supported this strategy with unique titles and descriptions, canonicals, Polish-English hreflang, structured data, a sitemap, correct robots directives, and an llms.txt file that helps AI agents understand the website. We also prepared Search Console, internal linking, and a draft workflow that keeps unfinished articles out of the index.
Why Astro and Cloudflare
The first version was built with TanStack Start. It is a strong application framework, but as the project grew it became clear that Jan's website was primarily a content product. It needed to deliver dozens of offer pages, local landing pages, and articles quickly, rather than behave like a complex browser application. That is why we deliberately migrated the entire project to Astro.
Astro was designed specifically for content-driven websites. It produces lightweight HTML by default and lets us add interactive JavaScript only where needed. On Jan's site, those are isolated features such as the contact form and certificate gallery. Everything else reaches users and Google crawlers without the cost of an unnecessary client-side application. The result is a simpler architecture, faster delivery, and a strong SEO foundation.
We deployed the site to Cloudflare Workers. Beyond fast content delivery, this also let us solve less obvious problems: form delivery, seeking within testimonial videos, caching, and a controlled publishing process. Every change can be verified locally before production.
This choice also has a strong future behind it. On 16 January 2026, Cloudflare announced its acquisition of the company behind Astro. The framework team continues to develop Astro as open-source MIT-licensed software. Astro remains platform-agnostic, while both technologies now share an increasingly aligned direction around fast websites, server rendering, and Cloudflare Workers.
Jan does not need a traditional administration panel or a separate CMS. Content and site structure remain together in one versioned project. Carefully prepared rules and prompts let him describe a change to Codex, run the site locally, review the result, and verify a production build before publishing. Astro provides a simple, predictable foundation, while the AI agent becomes a safe operating layer for the project.
Before and after the migration
The migration was not a technology change for its own sake. Every decision simplified content delivery, strengthened SEO, or gave Jan more control over the website's continued development.
| Area | Before | After |
|---|---|---|
| Framework | TanStack Start | Astro |
| Rendering | Client application and SSR | Static HTML and islands |
| Hosting | Previous configuration | Cloudflare Workers |
| SEO structure | A few general pages | Services, client groups, local areas, and blog |
| Languages | Basic translations | Separate PL/EN URLs with hreflang |
| Performance | Initial result | 4 x 100 in PageSpeed |
| Management | Changes made by the contractor | Owner-led development with Codex |
JavaScript strategy: only where it creates value
In Astro, shipping no browser-side JavaScript is the starting point, not an optimization added at the end. The copy, navigation, offer, local pages, and articles arrive as complete HTML. Visitors can read immediately, and search crawlers do not need to run an application to see the content.
Interactivity is added selectively through the islands model. The contact form and certificate gallery receive their own client code only where needed, while the menu uses a small shared script. None of these features forces full-page hydration or downloads a framework for content that remains static.
- Content without JavaScript: the essential information is immediately available in HTML.
- Interactive islands: code is loaded for a specific feature instead of the entire website.
- No full-page hydration: the form, gallery, and menu do not turn the document into a heavy client application.
- Intent-based prefetch: hovering or focusing a link prepares the next page before the click.
This keeps the fluid feel associated with an application while preserving a lightweight, resilient, and easily indexable HTML document as the foundation.
After 13 days, we already had evidence that the direction worked
The snapshot below was captured on 14 July 2026, 13 days after launch. The mobile PageSpeed Insights test returned 100/100 for performance, accessibility, best practices, and SEO. At the same time, local phrases had started appearing on Google's first page.

Queries including personal trainer Kliny, Dębniki, Skotniki, Kobierzyn, Czerwone Maki, and Borek Fałęcki reached leading positions. A query about personal training costs in Kraków appeared on the second results page. Less than two weeks after launch, this was a strong signal that the information architecture, local content, and technical foundations were working together.
The most important result: Jan can keep building
We did not want to ship a project that would start aging the day it launched. I prepared rules and prompts for Jan to work with Claude Code and Codex. They explain how to run the site locally, make changes, verify the build, and what an agent must not do. Jan can now develop the offer and content himself within safe guardrails.
That changes the nature of the collaboration. I am not the bottleneck for every correction. My role was to create the direction, architecture, and working environment in which Jan's knowledge can regularly become new content and features. The website is not a finished brochure; it is a product its owner can continue operating.
Your next step
Have the expertise, but not the system that turns it into a working product?
Let us start with a conversation. We will define what should deliver an outcome now and how to create a foundation you can continue developing yourself.