Skip to content
All notes

The Future of Personal Websites Is APIs

Your website should not only be visited. It should be callable.

Product thinking3 min read
Contents

Your website should be callable, not only visited. That is the shift I think personal websites are moving toward.

For years, the default personal website looked like this:

  • homepage
  • about page
  • projects
  • writing
  • contact

That is still useful, but it is no longer enough. The next version of the personal website is a structured hub that people, software, and AI agents can all understand.

The old personal website

The old personal website was designed around a human visitor.

Someone clicks a link, lands on the homepage, scans the page, opens a project, maybe reads a post, maybe contacts you.

That flow still matters.

Humans need trust signals:

  • clear positioning
  • good writing
  • strong visual hierarchy
  • proof of work
  • contact paths

But the human browser is no longer the only discovery interface.

People increasingly discover work through mediated systems:

  • AI assistants
  • AI search
  • recruiter tools
  • coding agents
  • social previews
  • search indexes
  • internal databases
  • custom scripts
  • browser agents

Those systems do not experience your site like a person does. They need structure.

The new personal website

The new personal website still has pages.

But underneath the pages, it also has:

  • structured data
  • public API endpoints
  • MCP tools
  • docs
  • examples
  • machine-readable identity

The homepage is one interface, the API is another, the MCP server is a third. They all point at the same underlying work, and that is the future-proofing move.

Why HTML is not enough

HTML is excellent for rendering documents. But if a tool wants to answer:

What products has this person shipped?

or:

Which projects use TypeScript?

or:

Summarize this person's work for a recruiter.

HTML forces the tool to infer structure from presentation. Sometimes that works and sometimes it guesses. Structured data removes the guessing.

Instead of scraping cards and headings, a tool can ask for:

GET /api/v1/products
GET /api/v1/projects?tag=typescript
GET /api/v1/me

That is a better contract.

Personal websites as identity APIs

A personal website is already a form of identity.

It tells the world:

  • who you are
  • what you do
  • what you have built
  • what you believe
  • where to contact you

The API version of that is a machine-readable identity layer that lets software understand the same things:

  • profile
  • skills
  • projects
  • products
  • notes
  • links
  • status
  • tags
  • tech stacks

This strengthens the human site rather than replacing it.

Why MCP belongs here

An API makes the site readable by software. MCP makes it usable by AI agents.

Software usually knows what endpoint it wants. Agents often start with a natural-language task.

For example:

Find Orlando's strongest projects for an AI engineering role.

That is a workflow, not a simple endpoint.

An MCP server can expose tools like:

get_projects
get_products
get_notes
get_orlando_bio

The agent can choose the right tools, gather context, and produce a useful answer. That is why MCP fits the future personal website: it turns a site from something an agent can scrape into something an agent can query.

The builder advantage

For builders, this is a quiet advantage. Most personal sites say:

Here is my work.

An agent-readable personal hub can answer:

What work matters here, and why?

That is a different level of usefulness. It shows:

  • systems thinking
  • structured data design
  • API design
  • AI-native interface thinking
  • product judgment
  • distribution awareness

The personal hub becomes proof of how you think, not just what you have made.

The future shape

I think the future personal website looks more like this:

/             human homepage
/about        human profile
/work         human project browsing
/notes        human writing
/api          developer documentation
/api/v1/*     structured public data
/api/mcp      agent-readable tool surface

That does not mean every person needs a complex backend. It means more personal sites will expose structured public context: JSON files for some people, REST endpoints for others, MCP servers for others. The principle is the same. Make your work readable beyond the page.

A website that participates

The personal website used to be a destination. Now it can also be an interface. A destination waits for visitors; an interface participates in workflows.

A recruiter tool can summarize your work. An assistant can answer questions about your products. A search system can understand your writing. A coding agent can inspect your public projects. A future app can consume your profile as structured data. That is a more useful website.

The thesis

The future of personal websites is better structure: queryable work, callable identity, and agent-readable context. Build the page for people, and expose the same work as something software can ask for.

A tiny vote of confidence

Was this note worth your time?

 

Notes from the build

Get more AI engineering insights

Follow the work: AI tools, browser products, product decisions, and honest lessons from the build.

By subscribing, you agree to receive Orlando's emails. No spam. Unsubscribe anytime.

The Future of Personal Websites Is APIs | Orlando Ascanio