Landing Page, Frontend SOP, and Where Projects Live
2026-03-14 — Stream of consciousness while building the Posts project
The CTA link in my posts needs to go somewhere real. Not just a LinkedIn profile — a landing page. A SvelteKit frontend on Tailscale that captures leads. Minimal friction: get an email address, maybe a name, nothing more at first. Keep it professional.
But that means I need:
- A landing page repo (SvelteKit)
- A way to receive and store contact info (backend? form service?)
- A URL on the cluster
- A design — found "impeccable" (open source frontend design tool). Want to fork/mirror to Forgejo and use it as a design agent.
Where does this live? pal-e-agency project? But that project is already about process/agency operating model. Adding a frontend repo bloats it. Maybe there's a separate project for frontend work? Or maybe this is just SOP — "how does an enterprise handle frontends?" — and each frontend lives with its parent project.
The real question: am I even making a post right now, or am I building infrastructure to make posts? Both. The landing page IS the CTA. Can't publish posts without it. But the landing page is also its own project with its own plan.
Frontend SOP for an enterprise — what does that look like? Fork impeccable to Forgejo, use it for design, deploy SvelteKit apps to cluster. This is repeatable. Every project that needs a frontend follows the same pattern. Maybe that's a convention, not a project.
I'm journaling, not posting. And that's fine. Organize thoughts first, build second.
Key threads to resolve:
- Landing page repo: where does it live (project-wise)?
- impeccable: fork to Forgejo, evaluate as design tooling
- Lead capture: minimal funnel (email only), where to store contacts
- Frontend SOP: convention for how frontends are built across projects
- pal-e-agency bloat risk: is pal-e-agency the right home for this?