Platform vs Custom

This page is a technical comparison between:

using static.bio as a hosted platform, and
building/hosting your own "link-in-bio" page.

This is not a value judgment. It's a set of tradeoffs framed around the constraints static.bio optimizes for.

Summary table

Concern	static.bio (hosted)	Custom build (self-hosted)
Time to ship	Minutes	Hours to days
No-JS public page	Guaranteed by contract	Up to you (easy to regress)
Third-party-free surface	Guaranteed by contract	Up to you
Theme system	Shared base + themed CSS, curated	You build it
Custom domain	Supported	Supported
Click tracking	Optional, server-side redirect	You build it
Static export	Planned	Trivial (if you already do it)
Auditing	Built-in verify workflow	Up to you
Maintenance	Handled by static.bio	You own it
Portability	Planned via export	Full control
Cost	One-time (Lifetime) / free tier	Hosting + your time

What static.bio gives you (concretely)

1) A constrained public surface

Public profiles are static HTML + CSS, with:

no JS execution
no third-party scripts/resources
a stable DOM contract (themes style the same skeleton)

These constraints eliminate whole categories of performance and tracking issues without relying on discipline.

2) A theme system that scales

Instead of shipping all theme CSS to every page, static.bio ships:

base.<hash>.css (shared component primitives)
theme-<id>.<hash>.css (selected theme only)

Both are fingerprinted and immutable-cacheable. This keeps pages small even as the theme catalog grows.

3) An auditable story

If you care about constraints, you usually care about verifying them.

static.bio is designed to be checked from the outside:

scripts: none
third-party hosts: none (except user-provided images if allowed)
bytes and requests: measurable with curl
headers: inspectable

4) Optional click tracking without scripts

If enabled, click tracking uses a server-side redirect endpoint.

No scripts, no pixels, no third-party analytics required.

What you might prefer custom for

1) Full design freedom

If you want custom layout, interactive widgets, embeds, animations, or content beyond an index of links, a custom site gives you infinite flexibility.

static.bio's public surface is intentionally constrained.

2) Custom functionality

Examples:

complex analytics and attribution
experiments/A-B tests
integrations that require client-side JS
content blocks that require dynamic rendering

These are out of scope for static.bio public pages by contract.

3) Absolute control over hosting and data

If you want full ownership of infra, logs, and storage, self-hosting is the cleanest path.

static.bio optimizes for "hosted convenience without compromising the public surface."

Portability stance

Portability matters if you're a developer.

static.bio's intended stance:

public pages are a deterministic render of stored data
exporting a profile to a self-hostable artifact is feasible (and planned)
themes and constraints should remain compatible with export

When static export ships, this page should describe exactly what is exported (HTML/CSS/assets) and what is not (analytics backend, dashboard).

Known tradeoffs

Hosted means you trust the platform. The goal is to make that trust verifiable via audit commands and clear contracts.
Constraints can feel limiting. If you want a personal site, build a personal site; static.bio is an index page with taste.
Self-hosting isn't "free." It's cheap in dollars and expensive in attention, maintenance, and regression risk.

Contract tests (comparison-relevant)

These are properties static.bio can guarantee and regression-test:

public HTML contains 0 <script> tags
public resources are same-origin (no third-party scripts/CDNs)
CSS files are fingerprinted and immutable-cacheable
theme output is deterministic for identical inputs

A custom build can achieve all of these, but you must maintain them yourself.

How to verify

See: Verify (curl cookbook) for copy/paste checks that demonstrate the constraints in practice.