Monday morning I opened theapparchitect.com and realised the site was doing a bad job of answering the question every potential client actually types into Google: “how much does a custom app cost?” The content existed — buried in posts, scattered across pages. The structured data told search engines almost nothing actionable. By Sunday I had eleven commits across two sites, two new landing pages, a complete JSON-LD overhaul, and a scroll progress bar that required two attempts before it worked. Not glamorous custom app development, but the kind of week that quietly determines whether the site earns its keep.
The SEO Push: Buyer Intent, Schema, and Pages That Actually Answer Questions
The biggest gap I found was coverage of buyer-stage queries. Someone searching “app entwickeln lassen kosten” or “how much does custom app development cost” is not looking for a blog post from 2023 — they want a dedicated page that answers the question directly and signals, through structured data, that the answer is authoritative. So I built two new landing pages: /pricing in English and /preise in German. Each one has concrete price bands, a short explanation of what drives costs up or down, and a PriceSpecification block in the JSON-LD. Google can now pull those numbers into rich results without having to parse prose.
On the same morning I added a HowTo schema to the vendor-comparison post — the one explaining the agency vs. freelancer vs. solo-architect decision. That post already had the right content; it just wasn’t marked up in a way that structured-data parsers could consume cleanly. The HowTo type is a mild stretch for a comparison article, but the step-by-step nature of the decision (“first assess your budget, then assess your timeline, then decide on the model”) maps well enough that I’m comfortable defending it. What I am less comfortable with is that the real App Store rating I pulled in for the MobileApplication entity is hardcoded as a static value. I’ll need a build-time fetch from the App Store API to keep that accurate — right now it’s a number I typed by hand, which will drift. That goes on the list.
The breadcrumb and Open Graph work was fast in principle and annoying in practice. The BreadcrumbList JSON-LD was straightforward to add to the layout. The custom OG image generation — pulling the post title into a pre-rendered image at build time — took about ninety minutes longer than I expected because the font loading in Astro’s @vercel/og integration behaved differently in the production build than it did locally. The fonts were resolving fine in dev, then silently falling back to the system sans-serif in build. I tracked it down to an absolute path vs. relative path issue in the font fetch. Once I saw it, the fix was three lines. Getting there was not.
The FAQ blocks on the home page and contact page were a deliberate choice to target mid-funnel queries — things like “is a solo developer reliable for a serious project?” and “what happens if I need support after the app launches?” These are real questions I hear from prospects. Putting them on-page with FAQPage schema means they can surface directly in Google’s answer boxes. Whether they will is not guaranteed, but the cost of adding them was low and the potential upside is meaningful. I marked up six questions total. I’ll watch the Search Console impressions data over the next four weeks to see which ones, if any, get picked up.
Two Small Things That Mattered
The scroll progress bar sounds trivial. It very nearly wasn’t. The first implementation used Tailwind’s scale-x-0 utility class to start the bar at zero width, then updated it with an inline transform: scaleX() via JavaScript as the user scrolled. The problem: Tailwind’s utility and the inline style were both setting transform, and the inline style was overriding the initial Tailwind value in a way that left the bar invisible on load in some browsers. I spent about twenty minutes confused before I realised what was happening. The fix was to drop the Tailwind class entirely and manage the full transform property from JavaScript. The bar is now 4px tall with a subtle glow — visible without being intrusive. I’m happy with it.
The portfolio site (marcelrgberger.com) got two commits. One was entity-strengthening work: moving my name to the <h1> on the landing page and enriching the Person schema with a real portrait URL, a sameAs array pointing to my GitHub and LinkedIn profiles, and a knowsAbout list. The second was a routing change for app cards that only exist as App Store products — those now go through their own landing page first instead of linking directly to the App Store. That keeps sessions on my domain longer and gives me a place to add context before the handoff. It’s a small thing that affects both user experience and the crawl graph, so I’m glad I got to it.
What This Looks Like From the Outside
If you are a business owner thinking about having a custom app built, a week like this one might seem like distraction — time spent on the builder’s own site instead of client work. I think of it differently. A site that ranks well for cost and vendor-selection queries means the clients who find me have already read the honest pricing page, already understand the solo-vs-agency tradeoff, and arrive at the first call with realistic expectations. That is better for both sides. The conversations start in a different place.
If you are thinking about that first call, the contact page is here. No form to fill in — just a direct message.
The live site is at theapparchitect.com and the /services page has the current offer in plain language.