LinkedIn · Writing · Repositories
manifest · architecture · processes · pipeline · galaxy · principles · writing · telemetry · console · root · connect
~/danish.os › read manifest
I build full-stack systems, and I care about the parts most profiles skip — the API contract, the migration, the deploy, the failure state. A screen is easy to demo. A system has to keep working after the demo is over. That's the part I actually enjoy.
| What I build | Web applications end to end — React interfaces over Django / DRF and FastAPI services, backed by PostgreSQL or MongoDB, shipped in containers. |
| How I think | In systems and contracts. I want to see the whole path a request takes before I trust any single piece of it. |
| What's different | Deployment, data integrity, and failure handling are part of my build — not something to hand off afterwards. |
| Where I'm based | India, working across the stack and the time zones it touches. |
~/danish.os › trace request --follow
Watch one request make the whole trip — interface to data and back, with the platform it all runs on underneath. Then open any layer for the full toolset.
▸ Inspect Interface Layer — what people see and touch
| Tool | Role |
|---|---|
| React | Component-driven UIs |
| JavaScript | The language the client speaks |
| Redux | Predictable shared state |
| Tailwind CSS | Utility-first styling |
| ShadCN | Accessible component primitives |
| Framer Motion | Motion and micro-interactions |
| Figma | Design before build |
▸ Inspect API Layer — contracts between systems
| Tool | Role |
|---|---|
| Python | Primary backend language |
| Django | Batteries-included application framework |
| Django REST Framework | Structured, versioned REST APIs |
| FastAPI | Typed, high-throughput services |
| WebSockets | Realtime, bidirectional channels |
▸ Inspect Data Layer — persistence and integrity
| Tool | Role |
|---|---|
| PostgreSQL | Relational source of truth |
| MongoDB | Document data where it fits |
| Django ORM | Models, migrations, query safety |
| Database design | Schemas that stay correct under load |
▸ Inspect Infrastructure Layer — ship, run, observe
| Tool | Role |
|---|---|
| AWS | Cloud hosting and services |
| Docker | Reproducible environments |
| Kubernetes | Orchestration at scale |
| Git | Version control and CI triggers |
| System design | How the pieces fit and fail |
~/danish.os › process.list --running
| PID | Process | State |
|---|---|---|
| 001 | A full-stack operations tool — FastAPI services with a React front end | running |
| 002 | Deeper system design, API contracts, and scaling data | running |
| 003 | Reliable APIs, deployment systems, and product engineering | running |
These lines are driven by profile-data.yml — edit the file, not the table.
~/danish.os › watch pipeline
How I ship, in three sentences: small changes, merged often, deployed the same way every time. The pipeline is code too — versioned, reviewed, and boring on purpose. If a failure can happen, I'd rather it happen loudly in CI than quietly in production.
~/danish.os › scan orbit
Placeholder satellites — real repositories dock here via
featured_projectsinprofile-data.yml. The build logs below follow the same rule: structure now, real names and results when they're true.
▸ Open build.log[01] — Realtime operations dashboard (replace)
- Problem — Teams were tracking work across spreadsheets and messages, with no single source of truth.
- Approach — A service-backed dashboard with WebSocket updates and an append-only activity log, so every change has an actor and a timestamp.
- Stack — React · Redux · FastAPI · PostgreSQL · Docker
- Architecture note — State lives server-side and streams to clients; the UI never guesses what's true.
- Result — measurable result — to be filled in
- Links — repository · demo
▸ Open build.log[02] — Content / API platform (replace)
- Problem — A product needed a clean, versioned API that a web client and third parties could both depend on.
- Approach — Django + DRF with explicit serializers, permissions, and a versioned URL scheme designed around real workflows rather than raw tables.
- Stack — Django · Django REST Framework · PostgreSQL · Redis-ready
- Architecture note — The API contract came first; the database schema followed the workflow, not the other way around.
- Result — measurable result — to be filled in
- Links — repository · demo
▸ Open build.log[03] — Full-stack product build (replace)
- Problem — An idea that needed to become a usable product across interface, API, and deployment.
- Approach — React + Tailwind on the front, a typed backend, containerised and shipped to the cloud with a repeatable pipeline.
- Stack — React · Tailwind · FastAPI · Docker · AWS
- Architecture note — Deployment was part of the build from day one, so "it works on my machine" never became a stage.
- Result — measurable result — to be filled in
- Links — repository · demo
~/danish.os › cat principles.md
- Clarity before cleverness. Code is read far more often than it's written — optimise for the next person, who is usually future me.
- Deployment is part of the build. If it isn't shippable, it isn't finished; the pipeline is a first-class feature, not an afterthought.
- Design APIs around workflows. A good contract mirrors how the system is actually used, not how the tables happen to be laid out.
- Make failure loud. A system that fails silently can't be trusted — surface errors where someone will see and act on them.
- The data model is the real architecture. Get the shape of the data right first; most other decisions negotiate with it.
- Prefer small, reversible steps. Many little changes you can undo beat one big change you have to defend.
~/danish.os › fetch notebook --latest
More on Medium →
~/danish.os › stat --system --github
If a card above fails to load, nothing below it breaks.
~/danish.os › open console --replay
▸ View hidden system notes — what the dashboards don't show
Debugging philosophy — Reproduce it before you fix it. A bug you can't reproduce isn't fixed, it's just hiding. Read the error message twice; it's usually telling the truth.
Favourite kind of problem — The ones at the seams: where the frontend's assumptions meet the backend's reality, where a schema meets real data, where "works locally" meets "works deployed."
Human side — I like understanding how things work more than I like being told. I learn by building the thing and taking it apart.
This week's note
Design the API around the workflow, not around the database table.
~/danish.os › sudo -i
▸ Request root access
$ sudo inspect danish-os
password: ********
access granted — welcome to ring 0
▸ /root/engineering.notes
- Problems I keep coming back to — allocation and ordering problems: which unit goes to which order, what happens when two things claim the same resource, and how a queue should behave when the world changes under it.
- What I care about when building — that the failure states are designed, not discovered. Happy paths write themselves; the sad paths are the work.
- One human detail — I'll take a whiteboard argument about schema design over most forms of entertainment.
▸ /root/message.txt
You clicked through two layers of a fake filesystem to read a hidden note. That's exactly the kind of curiosity this whole page is betting on. Systems reward the people who look one level deeper — so do careers. Say hi: the connection port is right below.
~/danish.os › open connection
If you're building something across the stack — or debating how a system should be shaped — I'm glad to talk. Best ways in:
- Collaborate or hire — start on LinkedIn
- Read the thinking — technical writing on Medium
- See the code — GitHub repositories
`DANISH.OS v1.3.0 · last refresh 2026-07-27`