Prarthana Purohit

UI/UX Designer & Full-Stack Developer — I design products and then I build them.

Four live products below — a hardware-backed media verification system, a developer landing page for payment infrastructure, and two full-stack apps designed and built end to end. For each: the wireframe it starts from, the screen that shipped, the flow underneath, and the decisions that mattered. Everything links to running code — nothing here is a concept.

CASE 01

OpenVeil — making truth verifiable

Role: sole contributor — hardware to website Raspberry Pi · Rust · Nostr Live ↗

OpenVeilCam is hardware-linked, censorship-resistant image capture built on the Nostr protocol — for journalists, activists, and human-rights defenders whose authentic photos get dismissed as fake while platforms quietly delete the evidence. I built the whole thing alone: the Rust camera runtime on a Raspberry Pi, the cryptographic signing and publishing pipeline, and the website that has to explain it. The design brief for that site was brutal in its simplicity: a system about trust cannot ask you to take its word for anything — so the page shows real terminal output from the real device instead of marketing renders.

Wireframe — hero

structure
wordmark
about
github
H1 — three short claims, stacked
▶ demo video
about
architecture
architecture diagram — the one dark object on a light page

device → capture → sign → publish, drawn once, readable in 10 seconds

Shipped screen — openveil.world

openveil.world
OpenVeilAbout ProjectGitHub

Capture the Truth.
Cryptographically Sealed.

OpenVeilCam provides hardware-linked, censorship-resistant image capture built on the Nostr protocol. Because human rights start with undeniable facts.

▶ Watch Demo Video About Project Technical Architecture
1 Device identityHardware-linked secp256k1 keypair (Nostr)
2 Capture frameThe original image is the canonical source
3 Sign & publishECDSA attestation → Blossom + Nostr relays
Verifiable by anyoneNo central authority. No hidden trust.

“See it in action” — real terminal output, told as three tabs (click them)

prarthana@rpi: ~/OpenVeilCam
$ OpenVeilCam --init
INFO  Initialising hardware-linked DeviceIdentity…
INFO  salt loaded · keypair derived (secp256k1)
 npub stable across reboots — Nostr-compatible
HIGHLIGHTS • Deterministic device identity • Hardware-linked key generation • Secure salt persistence
$ OpenVeilCam capture
INFO  image pipeline initialised · capturing frame
INFO  high-resolution JPEG written — canonical source
 no metadata manipulation before attestation
HIGHLIGHTS • Canonical image used for signing • Verifiable chain of trust starts at the sensor • Deepfake swaps prevented by deterministic verification
$ OpenVeilCam publish
INFO  ECDSA signature computed for capture.jpg
INFO  uploading to Blossom · publishing NIP-94 event
 accepted  wss://relay.primal.net
 accepted  wss://nos.lol · wss://relay.snort.social
HIGHLIGHTS • ECDSA image attestation • Blossom media storage · NIP-94 metadata • Public verification via Nostr relays

Flow — from photon to proof

1Device boots 2Identity from hardware entropy 3Capture — canonical image 4Sign with device key (ECDSA) Media → Blossom / IPFS-compatible storage Hash + signature + metadata → Nostr relays (NIP-94) Anyone verifies, anywhere
Edge case !Metadata stripped / file recompressed Verification still works — attestation lives on relays, not inside the file
Terminal screenshots as hero images.

The audience is people who verify claims for a living. Polished product renders would work against the message, so the “See it in Action” section shows the actual Raspberry Pi terminal — my username and all — split into three tabs so the pipeline reads as a story: identity → capture → publish.

Warm cream, not crypto-dark.

Every decentralization project ships a black site with neon gradients. OpenVeil is about evidence and human rights, not speculation — so the page is warm paper with black type, and darkness is reserved for the two objects that earn it: the architecture diagram and the terminals. The contrast makes them the obvious focal points.

Explain in threes, always.

Device identity → capture → sign & publish. That trio appears in the hero diagram, the tabbed demo, and the feature list — the same mental model at three zoom levels. Seven deep technical features (Rust runtime, ZKP compatibility, enclave support) exist on the page, but only after the simple version has landed.

CASE 02

ngx-l402.org — selling infrastructure you can’t see

Role: website design Audience: backend engineers Live ↗ Code ↗

An nginx module has no screens. The whole product is a config file, an HTTP 402, and money arriving in your node. So the site treats code blocks as the hero images and proves the product with a live payment demo instead of promises. Warm paper, one blue, and a page that reads like very good documentation — because for engineers, docs are the marketing.

Wireframe

structure
logo
H1 — one clear claim
CTA
ghost
code block = hero
live demo widget

no stock art anywhere — the config is the picture

Shipped screen

ngx-l402.org
⚡ ngx-l402DemoCashuWhyQuickstart

01 · Overview

Accept Lightning payments in front of any HTTP API.

An open-source nginx module that puts an L402 paywall on any upstream — two lines of config, eight payment backends, non-custodial.

Quickstart → View on GitHub
/etc/nginx/conf.d/api.confcopy
# put a paywall on any upstream — no API rewrite
location /v1/ {
  l402                     on;
  l402_amount_msat_default 1000000;  # 1,000 sats
  proxy_pass               http://upstream;
}

The live demo — designed state by state (press “Request” to walk the flow)

try it live
https://demo.ngx-l402.org/protected

Awaiting request — the endpoint is protected by an L402 paywall.

Flow — the demo people actually complete

1Request !402 + invoice ⚡ WebLN one-click Open in wallet Paste proof by hand 3Retry with proof 🔓 Unlocked
Edge case !Gateway unreachable Error shows the exact fix — a one-line docker run
One accent, everywhere.

Blue only ever marks something you can click. When color means action, nobody hunts for the buttons.

Errors that hand you the fix.

Every failure state in the demo teaches recovery — down to naming the missing CORS header. The unhappy paths took longer to design than the happy one.

Code stays dark in both themes.

The site has full light and dark modes, but the terminal never changes costume. Light mode just gets a window into it.

CASE 03

DevConnect — matchmaking for developers

Role: design → code, full stack, solo React · Node/Express · MongoDB Live ↗

A network for developers built on a matchmaking loop instead of an endless feed: you see one person at a time and choose — Connect or Ignore. Mutual interest becomes a connection, connections unlock chat. I designed and built all of it: auth, the card deck, requests, real-time chat, a profile editor with live preview, and a two-tier premium model.

Wireframe — the one-card loop

structure
devconnect
av
photo
connect
ignore

one card, two verbs, zero scroll — the decision is the interface

Browse — try the deck: Connect or Ignore

/ · browse
DevConnectConnectionsRequests
A

Aarav Mehta

Male · 27 years

Backend dev. Building things that scale.

Requests & Chat

/requests · /chat
DevConnectConnectionsRequests

Incoming Requests

K

Kunal K

Male, 30 · "Hey there!"

AcceptReject

Connections

R

Rebekah M

Female, 28 · connected

Chat
R

Rebekah M

● online
hii 👋
Hey! Saw your profile, let's connect!
2:41 PM
Type a message…Send

Flow — from stranger to conversation (every step is consent)

1Sign up / log in 2Edit profile — with live card preview 3Browse — one card at a time Connect — sends a request Ignore — card leaves, no notification 4They Accept / Reject Connection → chat unlocks
Upgrade path $Silver — chat, blue tick, visibility boost, 3 months $Gold — unlimited chat, high visibility, priority support, 6 months
One card, not a grid.

Early sketches had a browsable grid of developers. It turned people into thumbnails. One full-width card forces you to actually read a person before deciding — and it made the mobile and desktop layouts nearly identical for free.

The profile editor shows the card you’ll be.

The edit form sits next to a live preview of your own card, updating as you type. You’re never styling abstract fields — you’re looking at exactly what strangers will judge in three seconds. Completion went up because vanity is a great motivator.

Chat only after mutual yes.

Messaging is gated behind an accepted request — no cold DMs by design. It’s more code (requests, accept/reject states, gating) but it’s the difference between a network and an inbox full of “hi.” Building the API myself meant I could enforce it server-side, not just hide a button.

CASE 04

MindfulHub — a wellness ecosystem in five doors

Role: design → code, full stack, solo React · AI mood suggestions Live ↗

A mental-wellness platform that goes past mood tracking: journaling, a five-point mood check-in with AI-powered suggestions, professional counselor profiles with appointment booking, community testimonials, and structured feedback. The design problem was scope — six features could easily become a maze. My answer was a hub: one calm purple dashboard where every feature is a door with a plain-language sentence on it, and every room has one big “Back to Dashboard” button. You always know where you are and how to get home.

Wireframe — hub & spokes

structure
“welcome back, friend”
logout
journal
mood
stories
counselors
feedback
“your wellness journey starts here” — reassurance strip

cards say what you’ll do, not what the feature is called

Shipped screens — pick a mood, then ask the AI

/dashboard

Welcome back, Friend ✨

Logout
📖

My Journal

Write your thoughts, feelings, and experiences.

💗

Mood Tracker

Track emotions, get AI suggestions.

Testimonials

Read and share community stories.

🧑‍⚕️

Find a Counselor

Book professional support.

/mood

Mood Tracker 💭

← Back to Dashboard

How are you feeling today?

What happened today? How did it make you feel?
Major emotion you felt ▾

Flow — a check-in, and where it can lead

1Log in 2Dashboard hub 3Rate your day — 5 emoji + words 4Describe it + pick the major emotion ✨ Ask for AI suggestions — opt-in Just save the entry Saved — history grows
Needs more than an app Counselor profiles — specialization, rating, credentials, availability Book Appointment
Emoji + words, never emoji alone.

The mood scale pairs each face with its label — Very Sad through Very Happy — because a 😐 means different things to different people on different days. It also keeps the scale usable with a screen reader, which matters more here than in most apps.

AI is a button you press, not a thing that happens.

“Get AI Suggestions to Improve Mood” is deliberately its own hot-pink action, visually separate from the calm purple “Save.” On your lowest day, unsolicited advice from software is the last thing you want — so the AI waits to be asked. Opt-in was the design; the color contrast is what enforces it.

A path to real humans.

An app should know its limits. Counselor cards carry what actually builds trust — specialization, credentials, years of experience, rating, availability — and end in one verb: Book Appointment. The most important flow in a wellness app is the one that leads out of it.

HOW I WORK

The same loop, every project

Nothing exotic — the value is that I run the whole loop myself, from paper to deployed product. What ships is what was designed, because the same person did both.

1✏️ Paper sketches 2Grayscale wireframes 3Hi-fi mockups 4Build it — React / APIs 5Use it myself for a week Cut & refine
Every product gets its own skin.

Forest green for DevConnect, calm purple for MindfulHub, warm cream for OpenVeil and ngx-l402 — each palette comes from what the product is for, and each app commits to one identity instead of borrowing a trend. Range matters more to me than a house style.

Match the design language to the audience.

Engineers get terminals and config files as hero images. People having a hard day get soft cards and plain sentences. Same designer, opposite vocabularies — the audience picks the language, not my taste.

Designing in code keeps me honest.

I never draw something I can’t build, and I never blame a developer for what shipped. When I work with a team, handoff is a conversation instead of a PDF thrown over a wall — I speak both dialects.

Figmapen & paper HTML/CSSReact Node/ExpressMongoDB RustRaspberry Pi NostrGitVercel
WORK WITH ME

Available for contract work — design, build, or both

Landing pages and product sites, full app design (flows → wireframes → hi-fi mockups), or design-and-build where I hand you a deployed product instead of a picture of one. Remote, async-friendly. The fastest way to evaluate me: open any of the four links below — they’re all live.

prarthana@openveil.world

openveil.world  ·  ngx-l402.org  ·  DevConnect  ·  MindfulHub