Sunday, July 20th. I opened theapparchitect.com at around seven in the morning with a specific feeling — the kind where you know a page isn’t quite working but haven’t yet sat down to fix it properly. By two in the afternoon I had pushed nineteen commits and completely restructured the site. Everything from the homepage hero to the footer internal-link cluster got touched. The primary question I was trying to answer: what should happen when a small business owner lands on this site and wants to take the next step toward custom app development?
The answer I kept arriving at was: they should be able to book a call. Not fill out a form and wait. Not dig through a pricing table. Book a call.
Rebuilding the Funnel Around One Action
The old site had several competing calls to action. A contact link here, a services overview there, a pricing anchor somewhere else. I had been adding pages iteratively over months and the result was a funnel with too many exits. Visitors with real intent — the kind who have already decided they want a custom app and are evaluating who to hire — were being asked to make too many micro-decisions before getting to an actual conversation.
The rebuild consolidated everything down to a single CTA: book a free consultation. The homepage now opens with a lighter hero that gets out of the way quickly, links directly to the Cal.com booking embed, and doesn’t ask the visitor to scroll past three sections before they find a way to reach me. I also added a DSGVO consent gate in front of the Cal.com embed itself, which is the correct approach once you embed a third-party scheduler that loads external scripts. That took a second pass — my first implementation fired the embed immediately on page load before consent was recorded, which is exactly wrong under current German data protection rules. I caught it, rewrote it, now it gates properly.
I’m genuinely happy with how the booking flow reads now. I’m less happy that it took me this long to simplify it. The lesson, which I keep relearning: adding a new section is fast; stepping back and removing competing paths is the slower, harder work.
The Pricing Architecture and Why the Numbers Moved
The pricing page went through a significant rewrite this week. Not just cosmetically — the underlying model changed. I moved to a cleaner three-tier structure: MVP builds starting from EUR 15,000, production apps from EUR 45,000, and a full-service tier for more complex engagements. Those numbers are now the single source of truth. They live on theapparchitect.com. They are reflected in the JSON-LD structured data. They are in the LLM-readable files I maintain for search and AI crawlers. And they are no longer duplicated on my GitHub profile README.
That last point matters. I had stale pricing in at least three places simultaneously — the website, the structured data, and the GitHub profile. They didn’t agree with each other. When I updated one, I forgot the others. A potential client who looked at both would see different numbers, which is not confidence-inspiring for someone you’re asking to trust you with a five-figure project. So I made a deliberate architectural decision about information ownership: prices live in one place. Everything else links to that place or stays silent on the topic. I updated the GitHub README to drop pricing entirely and point readers to theapparchitect.com instead.
The structured data cleanup was also overdue. The OfferCatalog schema had been referencing an older two-tier model that no longer matched what was on the page. Search engines were indexing one structure; visitors were reading another. I aligned the JSON-LD @graph to the live three-tier model, merged the core entity definitions into a single graph declaration, and added a ProfilePage schema that had been missing entirely.
SEO Surface Area: New Landing Pages and a Footer Link Cluster
The other major block of work this week was expanding the site’s coverage of high-intent search queries. The existing pages did a reasonable job of explaining what I do, but they were thin on the specific phrases people type when they’re actively looking to hire: “iOS app developer Germany,” “Flutter developer freelance,” “custom app cost,” and the German equivalents.
I built out a second wave of landing pages covering service types, no-code comparisons, and a handful of regional/local variants. Each one is a proper page, not a thin stub — with a concrete explanation of what’s on offer, who it’s for, and what the next step is. I also added a footer link cluster pointing to these pages from every route on the site, which helps both crawlers and human visitors find them without those pages being buried.
I want to be honest about one thing here: building this many landing pages in a single session is not the way I’d do it on a client project. On a client project I’d stage this work, run it through a proper review cycle, and ship it in measured batches with tracking in place before each batch. On my own site I moved faster because I have full context and can iterate quickly. That’s a privilege of building something you completely own. It’s also a mild risk — I’ve now got a lot of new pages that need a few weeks of data before I can tell which ones are actually pulling their weight.
Side Notes
Seaworthy. I quietly renamed BoatCare to Seaworthy on marcelrgberger.com this week. It’s still in TestFlight beta. The name change had been sitting on my list for a while and this felt like the right moment to make the public record match reality.
Sommelio and DokuAI on Android. I corrected the platform labels on both sites — both apps are live on iOS and Android, and a couple of older cards still said iOS only. Small fix, but the kind of inaccuracy that reads as carelessness if a potential client checks your portfolio carefully.
Analytics alignment. I renamed the booking tracking event from a custom name I’d been using internally to the standard GA4 generate_lead event. This means the booking conversions now show up correctly in GA4’s default reports without any custom configuration. It’s the kind of small thing that’s annoying to discover later when you’re trying to read your funnel data.
If You’re Thinking About a Custom App
A restructured booking funnel on a personal site might not sound directly relevant to your situation. But the thinking behind it — one clear next action, pricing that’s honest and consistent, structured data that reflects reality — is the same thinking I apply to client projects. If you’re at the stage of evaluating whether a custom app is the right investment for your business, the clearest next step is a conversation. No form, no waiting.
Book a free consultation at theapparchitect.com/contact.
The full services overview, with the current pricing tiers, is at /services/.