The Data Model Behind My Personal Hub
A personal site is not just content. It is a data model.
A personal site is not just content.
It is a data model.
That is the shift that made my personal hub easier to turn into an API and MCP server.
If the site is only pages, every integration starts from rendered HTML.
If the site is structured data, every interface can reuse the same source of truth.
The homepage becomes one view.
The API becomes another view.
The MCP server becomes another view.
The data model is what keeps them aligned.
Profile
The profile entity answers:
Who is Orlando?
It includes:
- name
- handle
- role
- location
- tagline
- bio
- current focus
- skills
- links
This powers the /api/v1/me endpoint and the MCP get_orlando_bio tool.
The important thing is that the profile is not only written as prose.
It is structured enough for a tool to understand:
- what I do
- where I am based
- what I am focused on
- where to find me
- how to summarize me
That matters because profile context is often the first thing an AI assistant needs.
Project
The project entity answers:
What has Orlando built on his personal hub?
Fields include:
- title
- year
- slug
- description
- summary
- why it matters
- tags
- tech stack
- screenshot
- external link
- GitHub link
- status
The most important field is why_it_matters.
Most personal sites list what was built. Fewer explain why the project matters.
That field gives humans and agents the missing context:
- what problem the project addresses
- why it was worth building
- what kind of judgment it demonstrates
For agent-readable work, motivation matters as much as implementation.
Product
The product entity answers:
What has Orlando shipped for users?
Projects show capability.
Products show product judgment.
A product includes:
- title
- year
- slug
- tagline
- description
- summary
- metric
- audience
- comparison hook
- tags
- tech stack
- screenshot
- external link
- featured state
- status
The distinction between projects and products is important.
A project can be a case study.
A product is something positioned for users.
That means product data needs fields like tagline, metric, audience, and status. Those are not decorative. They explain traction, positioning, and market intent.
Note
The note entity answers:
What does Orlando think about?
Notes include:
- title
- category
- insight line
- excerpt
- description
- keywords
- published date
- slug
- content
- image
The insight_line field is doing important work.
It turns a note from "an article with a title" into "an idea with a thesis."
That helps the notes page.
It helps metadata.
It helps API consumers.
It helps agents decide whether the note is relevant to a user request.
Writing is not just content in this model. It is evidence of judgment.
Skill
Skills are part of the profile, but they also act like discovery tags.
Examples:
- TypeScript
- React
- Next.js
- Python
- AI / LLM integration
- Chrome Extensions
Skills answer:
What can Orlando work with?
For humans, this is scanning context.
For agents, this is matching context.
A recruiter assistant might ask:
Does this developer have experience with Next.js and AI products?
The skill list helps answer that directly.
Link
Links connect the personal hub to the rest of the internet.
Useful link fields include:
- personal site
- GitHub
- API docs
- external product links
- project links
Links seem simple, but they are part of the trust model.
A structured link tells a tool:
- where the canonical site lives
- where code might live
- how to contact me
- where a product can be tried
- which URL should be cited
When links are only embedded in prose, agents have to extract them.
When links are structured, agents can use them.
Status
Status fields explain lifecycle.
For projects, useful statuses are:
- active
- archive
For products, useful statuses are broader:
- active
- public beta
- in development
- pending review
- archive
Status matters because not all work should be interpreted the same way.
An archived experiment is not a current product.
An active product is not just a historical case study.
An in-development product should not be described as fully launched.
Agents need this context to avoid overstating things.
Tag
Tags answer:
What themes does this belong to?
Examples:
- AI
- productivity
- Chrome extension
- focus
- API
- systems design
Tags support:
- filtering
- search
- content grouping
- recommendation
- agent retrieval
The trick is to keep tags useful, not decorative.
If every item has ten vague tags, tags stop helping.
Good tags should reflect how someone would actually search or ask about the work.
Tech stack
The tech stack answers:
What was this built with?
Examples:
- Next.js
- TypeScript
- React
- Python
- Chrome Extension Manifest V3
- chrome.storage.local
- MCP
This field is especially useful for technical evaluation.
A human can scan it quickly.
An API consumer can filter or display it.
An agent can answer questions like:
Which projects demonstrate TypeScript experience?
That is the point of making tech stack structured instead of burying it in paragraphs.
The model behind the interfaces
Once the data model exists, the interfaces become easier to build.
The website renders the model into pages.
The API returns the model as JSON.
The MCP server wraps the model in agent-callable tools.
Same content.
Different readers.
That is the design principle behind the whole personal hub:
Model the work once. Expose it through the right interfaces.
That is what makes the personal hub future-proof.
Not the fact that it has an API.
The fact that the API, MCP server, and website all come from a structured understanding of the work.
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.