Taply
Digital business card platform. NFC, QR, analytics, and teams.
Co-Founder & Backend Engineer
Visit Taply →01 IDEA
Taply started with a small question. Why does everyone still hand out paper business cards? 88% of paper cards are thrown away within a week. The people you actually want to remember you never look at the card again. We wanted to make the card live. Scan a QR or tap an NFC tag and the recipient lands on your real-time profile, your current role, your latest work, a one-tap way to save you to their phone.
02 FRAMING
I co-founded the company and built the backend in Django 5.1 and DRF. The profile system is the heart of the product. Eleven section types (about, links, social, gallery, testimonials, products, services, contact, schedule, files, video), four layout variants, drag-and-drop ordering, live theme customization, and version history with rollback. Every profile is cached in Redis so a tap resolves in under 100ms regardless of traffic. Every save is appended to a versioned history that the user can rewind to.
03 BUILD
The NFC and QR sharing layer was the first thing we shipped. We picked the cheapest NFC chips that still supported NDEF rewrites, so a user can rewrite the same physical card after a role change without buying a new one. vCard save is a single tap. We ship the vCard payload from a dedicated endpoint with the right MIME type, so iOS and Android both handle it without downloads.
04 DEPLOY
The real-time analytics engine tracks views, NFC taps, QR scans, and vCard saves, plus a leads inbox that captures visitor contact requests. The console was built for sales teams: per-rep branding, bulk CSV onboarding, per-rep analytics. The team console is what closed Taply's first paying enterprise customer, a 250-rep sales org whose procurement team needed role-based controls and reporting. Stripe handles billing across Free, Pro, Business, and Enterprise tiers. Subscription state lives in our Postgres, and webhook idempotency is critical because Stripe retries on any 5xx.
05 WHAT'S NEXT
Deployment went from a single EC2 to a small fleet behind an ALB, with Redis as the shared session cache, Postgres with read-replicas, and S3 for media. The product surface is small, but every layer underneath does real work, and the same patterns (Redis caching at the edge, DRF for the orchestration layer, Postgres as the source of truth) recur across UnThink, DrishtiAI, and the Algocode backend.
medium · 10 min read · linux · networking · docker · internals
medium · 9 min read · linux · networking · namespaces · veth
medium · 8 min read · linux · networking · bridge · gateway
medium · 9 min read · linux · networking · nat · iptables
medium · 7 min read · postgresql · database · sql · crud
medium · 8 min read · postgresql · sql · joins
medium · 8 min read · postgresql · sql · aggregations
medium · 8 min read · redis · high-availability · cache · distributed
medium · 10 min read · redis · aws · cluster · high-availability
native · 10 min read · linux · networking · docker · internals
For the architecture deep-dive: three-layer build, isolation strategy, deployment topology. Read the case studys: Taply, and UnThink on /work.