navyasharma.org — a personal site and a workshop of tools

This website. It runs on a PHP framework I wrote from nothing — no Composer packages, no npm, no build step — because I wanted to know exactly what every part of it does, and because it has to run on plain shared hosting.

That is a self-imposed constraint rather than a claim that frameworks are bad. Writing the router, the PDO wrapper, the autoloader, the session auth and the templating layer by hand is the fastest way I know to stop treating any of them as magic.

Two things from one codebase

The site is what you are reading: projects, writing, poetry, research. None of it is hard-coded in a template — every word comes out of the database and is edited from an admin panel.

The tools host at /tools is a drop-in module system, and it is the part I actually use every day. Each tool is a self-contained folder with a manifest; the framework discovers it, decides whether it is public or private, and gives it a page. Some run entirely in the browser; some have their own database tables and server-side state.

Seven live here now: a calendar and tasks workspace, a personal finance ledger that tracks accounts, investments, debts and money loaned out, a physical-inventory tracker for finding which box a thing is in, a planner that drafts each day's schedule for me to approve, a multi-user driver for running DFT calculations across a lab of unreliable machines, an encrypted vault for files and passwords, and a word counter. Most are private. They exist because I wanted them, which is the only justification a personal tool needs.

The CRUD engine

Adding a whole new type of content — this page's Experience section, for instance — takes three small steps and no new controller: a table, a model that names it, and an entry in a configuration file describing the fields. The admin panel reads that description and generates the list, the form, the uploads, the auto-slugging and the delete confirmation.

It is a small idea and it has paid for itself repeatedly. The generic path is the one that gets exercised constantly, so it is the one that is actually correct.

Themes

The whole front end is driven by CSS custom properties, so a single attribute on the root element repaints everything. Four ship — Ink, Bone, Blueprint and Phosphor — and the choice is applied before first paint, so there is no flash of the wrong theme on reload. The admin panel and the tool chrome follow the same saved setting.

Written for machines too

The sitemap, the RSS feed and llms.txt are generated from the database rather than kept as static files, so publishing something puts it in all three with no second step to forget. Every page carries a schema.org graph with exactly one definition of the person it belongs to, which each page then references by id rather than restating.

Honest limits

• The Markdown renderer is deliberately tiny. Headings, emphasis, links, lists, code, images. It is not CommonMark and does not try to be.
• Content lives in one database. The code can be re-uploaded from anywhere; the database and the uploads folder cannot, which makes backups the whole of the disaster-recovery plan.
• Some tools are one user wide. The private ones assume that user is me, and would need real multi-tenancy before they were anything else.