For years, building the app wasn’t the hardest part for me. Finishing everything around it was: the marketing site, the copy, the screenshots, the positioning, the “what is this actually for?” narrative that has to exist somewhere outside Xcode.
The Hidden Tax of Indie Development
You build an iOS app. It works. It’s solid. Then you hit the wall of “everything that isn’t the app”:
- Marketing site
- Landing page copy
- Screenshots and layout
- Feature breakdowns
- “Why this app exists” messaging
None of this is technically hard. It’s just time-consuming, context-heavy, and easy to put off because it doesn’t feel like progress in the way shipping a feature does. It also feels like admin, which none of us want from our hobby projects.
The predictable outcome is that you delay it, ship something rushed, or quietly avoid shipping altogether because the last mile isn’t one task, it’s ten shallow tasks that all require a context switch.
This Used to Be a Real Barrier
Marketing sites used to mean a lot of overhead for a solo developer:
- Design effort
- Copywriting effort
- Frontend build time
- Ongoing maintenance
If you’re building products for a living, that overhead is normal and you staff for it. If you’re building evenings and weekends, it’s the bit that quietly drains momentum.
It also a different skill set entirely. Just because you can build an app does not mean you can build a website. Swift and native app development is a totally different beast.
So it either:
- Never gets done and your project dies
- Becomes a one-off static page that goes out of date the moment the product changes
- Requires a subscription to something like Wix or Squarespace. More upfront costs.
AI Changes the Equation Completely
The thing AI changes isn’t “you can generate a pretty landing page”. It’s that you can generate a first draft that is actually based on the product, which means you can stop treating the marketing site as a separate creative project.
I don’t “build” marketing sites in the traditional sense anymore. I generate them from the product context, and then I do what I’m good at: editing, refining, and making decisions.
The important part is the source of truth. If the app is stable and well described, the site becomes a projection of it rather than a separate thing you have to keep in your head.
The New Approach
The key shift for me is:
The app is the source of truth. The website is a projection of it.
1. Feed the AI the App Context
This is the part most “AI website generator” conversations skip. The model can only be as grounded as the input you give it, and vague prompts produce vague sites.
I feed it the same artefacts I already maintain as part of building the product:
- A short product spec (what it is, who it’s for, what it’s not)
- Feature list, written in plain language
- Screens and user flows (even if they’re rough)
- Design system rules (DesignKit tokens/components, tone rules, UI patterns)
- The constraints that matter to me (privacy-first, offline-first where possible, no nonsense accounts)
If you don’t have those written down, this approach still works, but you’ll feel the cost. AI doesn’t replace that thinking, it just makes it cheaper to express once it exists.
This is also where tools like Obsidian pay off. When your product documentation is structured, you can reuse it as context instead of rewriting a different explanation for every output.
2. Generate the Site Structure
Using that context, AI can produce:
- Landing page layout
- Feature sections
- Navigation structure
- Supporting pages (privacy, about, etc.)
The point isn’t novelty. It’s getting to a sensible structure quickly so you can spend your time on the parts that actually require judgment: what matters, what doesn’t, and what you’re willing to promise.
I still prefer boring, predictable sites. A home page, a features section, an FAQ if it’s justified, a privacy page, an about page. Anything else tends to be procrastination disguised as marketing.
3. Generate Copy That Actually Matches the Product
Because the AI has the product context, the copy gets closer to “truth” on the first pass:
- Feature descriptions are accurate
- Messaging aligns with intent
- Tone stays consistent
You’re not writing marketing copy from scratch, you’re refining it. That’s a meaningful difference because refinement is a constrained task, and constrained tasks are where AI is genuinely useful.
There’s still a hard boundary here: positioning is not something I outsource. A model can suggest angles, but deciding what the product stands for, and what it explicitly doesn’t stand for, is the job.
4. Build Using a Consistent Stack
For me, that’s:
- Next.js
- Tailwind
- Static export
- GitHub Pages
Simple, predictable, repeatable. Static matters because it keeps the site boring, cheap, and low maintenance, and it makes it easy to keep things aligned across multiple apps without reinventing the stack each time, with no backend and no unnecessary complexity.
I also keep the same constraints here as I do in the products: minimal tracking, no creepy analytics, no dark patterns. If I’m pushing privacy-first in the app, the marketing site shouldn’t be a surveillance device.
Hosting & Costs
This is the bit that used to quietly add friction: hosting, deployment, ongoing costs. It all adds up, especially when you’ve got multiple small projects.
I’ve intentionally made this boring.
Everything is hosted on GitHub Pages and deployed via GitHub Actions. For static sites, it’s basically perfect:
- No hosting bill
- No infrastructure to think about
- No runtime to maintain
- Just files, built and pushed
Once it’s set up, the workflow is exactly what you’d expect:
- Open a PR
- Let the action build the site
- Merge → deploy
That’s it. No dashboards, no “log into hosting provider and click deploy”, no drift between environments.
The only thing I actually pay for is a domain. That’s usually a few quid a year, point it at GitHub Pages, done. Basic DNS config, nothing fancy.
And even that setup is easier now. If you don’t want to think about CI config, AI will happily generate a working GitHub Actions file for you. It’s not magic, but it saves you half an hour of digging through docs.
The key point is this: the marketing site shouldn’t introduce ongoing cost or maintenance overhead. It’s a static projection of your app, not a product in its own right.
If hosting your site starts to feel like running a service, you’ve probably overcomplicated it.
5. Keep It in Sync
This is where it becomes a system rather than a one-off task.
Because the site is generated from the product context:
- New features → regenerate sections
- UI changes → update screenshots
- Product direction shifts → update copy quickly
In some cases, you can partially automate this. Even without full automation, the existence of a repeatable pipeline changes the psychology. Updating the site stops feeling like “a project I have to psych myself up for” and starts feeling like “run the workflow, review the output, merge”.
The site stops being a one-off asset and becomes part of the product lifecycle.
The Practical Payoff
This removes one of the last bits of friction in shipping apps, particularly for solo developers. The friction isn’t “I can’t code a website”, it’s “I don’t want to context switch into marketing mode for three days and still end up with something I’m not happy with”.
You no longer have to:
- Context switch into “marketing mode”
- Spend days writing copy
- Maintain a separate mental model of the product
Instead:
- The product drives the marketing
- AI handles the heavy lifting
- You focus on refinement and direction
The Bigger Shift
This fits a wider pattern in how I’m building now:
- Code is assisted
- UI is system-driven (DesignKit)
- Documentation is structured (Obsidian)
- Marketing is generated from context
Everything is connected, which means changes ripple cleanly instead of requiring a full mental reload. The speed is a byproduct of that connectedness, not the goal on its own.
The Reality Check
This doesn’t mean:
- You skip thinking about positioning
- You ignore messaging
- You ship whatever the AI gives you
If anything, your role becomes more important, because the model will happily produce plausible nonsense if you don’t apply taste:
- Editing
- Refining
- Deciding what actually matters
AI gives you speed. You still need taste, and you still need to be honest about what the product is today rather than what you hope it will become.
Where This Is Going
I’m pushing this further in a few directions:
- Using project files directly as input
- Generating consistent site structures across apps
- Building a repeatable pipeline for every new product
The goal is simple:
Shipping an app should automatically give you a marketing site.
We’re not fully there yet, mostly because screenshots and “what changed?” are still awkward to keep perfectly in sync. But the direction is clear: if you treat product documentation and design rules as first-class inputs, marketing stops being a separate discipline you have to bootstrap every time, and becomes another output of the system you’re already building.