DEV Community: Swapnil Nakate

I Built a Social Media App Where Posts Self-Destruct (And Why That's the Future)

Swapnil Nakate — Mon, 20 Apr 2026 16:22:57 +0000

I Built a Social Media App Where Posts Self-Destruct (And Why That's the Future)

Social media is broken. And not in a "we need better moderation" way — it's broken at the fundamental mechanic level.

Every platform operates on the same assumption: content is permanent. You post something. It lives forever. The algorithm decides who sees it. You have no real control. And your feed becomes a graveyard of irrelevant posts from three years ago mixed with rage-bait engineered to keep you scrolling.

I wanted to build something different. So I built FlashFeed — a PWA social platform where every single post has a countdown timer, and when it hits zero, it's gone.

The Core Mechanic: Rescue or Perish

Here's how FlashFeed works:

You create a post. It gets a countdown timer based on your account tier (24 hours for free accounts, up to 720 hours for paid).
Every interaction — a like, a comment, a share, even a view — adds time to that post's timer.
If nobody engages, the post self-destructs.

That's it. That's the whole thing. And it changes everything.

post created → expires_at = now() + tier_hours
interaction  → Postgres trigger → expires_at = LEAST(expires_at + time_added, hard_cap)
pg_cron      → every 15 min → soft-delete expired posts

The database trigger fires on every interaction. If a post is getting love, it stays alive. If it's dead weight nobody cares about, it disappears cleanly.

Why This Solves Real Problems

Problem 1: The Permanence Paradox

On Twitter/X, Instagram, Facebook — everything you post is a permanent record. That creates a chilling effect. People over-edit, over-think, or don't post at all because a bad take from Tuesday will still be showing up in search results in 2031.

FlashFeed flips this. Posts are ephemeral by default. You post something. It lives for 24 hours unless people care enough to keep it alive. Low stakes = more authentic expression.

Problem 2: Algorithmic Burial

On every major platform, the algorithm decides your content's fate. A post from a creator you love might never reach you. A post you made two weeks ago might suddenly get surfaced to people who have no context.

FlashFeed has zero algorithmic feed manipulation in the MVP. Chronological order only. What's alive is visible. What's dead is gone. The community itself acts as the filter — not a black-box recommendation engine optimized for engagement metrics.

Problem 3: Engagement Bait

Current platforms reward content that triggers outrage, controversy, or addictive loops because those metrics drive time-on-platform. The incentive structure is misaligned.

FlashFeed's incentive is different: create content worth saving. If your post is valuable, people will interact to keep it alive. The platform naturally surfaces quality because quality gets rescued. Bad content dies quietly.

Problem 4: Feed Clutter

Your Twitter feed has posts from three years ago. Your Facebook feed is full of posts from people you barely know about things that happened months ago. There's no expiry date on irrelevance.

On FlashFeed, the feed is always fresh. Dead posts are gone. You're only seeing what's currently alive — content the community is actively keeping alive right now.

The Tech Stack (For the Devs in the Room)

I built this as a Next.js 16 PWA with a few interesting architectural choices:

Auth: Firebase for phone OTP + Google sign-in. Client gets a Firebase ID token, sends it to /api/auth/verify-otp. Server verifies with Firebase Admin SDK, creates/loads the user in Supabase, and sets an ff_user_id httpOnly cookie. No Supabase Auth — Supabase is purely database + Realtime.

The timer system: Postgres triggers + pg_cron. Every interaction fires a DB trigger that calls extend_post_timer(). A pg_cron job runs every 15 minutes to soft-delete expired free posts and archive expired paid posts. No application-layer polling. The database handles the expiry logic entirely.

Realtime: PostCards subscribe to Supabase Realtime. When someone likes a post, the timer ticks update live across all connected clients. You can watch your post get rescued in real-time.

Tiers:

Tier	Base Duration	Hard Cap
Free	24 hours	7 days
Spark	72 hours	14 days
Flame	168 hours	30 days
Eternal	720 hours	~10 years

Time added per interaction: like +15m, comment +1h, share +3h, view +2m. Paid tiers get 2x multiplier.

PWA: next-pwa with service worker for offline support. Installable on Android and iOS. The whole thing works on mobile without an app store.

What Makes This Better Than Existing Apps

Let me be direct about the comparison:

vs. Twitter/X: No algorithm. No permanent record. No rage-bait optimization. Just chronological posts that live or die by community engagement.

vs. Instagram: No image-only format. No curated perfection culture. Posts aren't permanent trophies — they're living things that need community support to survive.

vs. Snapchat: Snapchat's ephemeral mechanic is about privacy (disappearing after viewing). FlashFeed's is about quality (disappearing if nobody cares). Fundamentally different philosophy.

vs. Mastodon/Fediverse: FlashFeed doesn't try to replicate Twitter with better moderation. It rebuilds the incentive structure from scratch. It's not a federated Twitter — it's a different kind of social graph entirely.

The Psychological Shift

Here's the thing that surprised me most when thinking through this mechanic: it changes how you read posts, not just how you write them.

On Twitter, you scroll passively. Content is infinite. Your engagement doesn't matter — the algorithm will surface what it wants regardless.

On FlashFeed, when you see a post you like, you know that liking it actually keeps it alive. Your like is a vote. Your comment is a rescue. You become an active participant in curation, not a passive consumer.

That changes the psychology of the whole interaction. Suddenly engagement isn't hollow — it has stakes.

What's Next

The MVP is live. Features in the pipeline:

Post detail pages with full comment threads
User profile pages with active/archived post history
Notifications when your post is near expiry (so you can share it before it dies)
Topic-based feeds (you subscribed to topics during onboarding — this makes them useful)
Analytics for creators: see the rescue curve on your posts

The core mechanic is the innovation. Everything else is execution.

Try It / Follow Along

FlashFeed is live at flashfeed.social — install it as a PWA on your phone.

If you're a developer and want to dig into the timer mechanic, the Postgres trigger code is the most interesting part. Happy to share the extend_post_timer() function in the comments if there's interest.

What do you think about ephemeral-by-default social media? Is permanence a feature or a bug? Drop a comment — I'd genuinely love to hear the pushback.

Built with Next.js 16, Supabase, Firebase Auth, TypeScript, and Tailwind CSS 4. No VC funding. No algorithm team. Just a mechanic I think is worth exploring.

Developer Resume with No Experience: What Actually Works in 2026

Swapnil Nakate — Mon, 20 Apr 2026 16:16:25 +0000

Breaking into development without professional experience is harder than it was — but very doable. Here's what entry-level developer resumes that get callbacks actually look like.

"I have no professional experience" is the most common reason junior developers give for not applying to roles they're qualified for. But professional experience is not the only evidence that matters on a developer resume — it's just the most obvious one.

The developers breaking into their first role in 2026 have figured out how to build credibility without job titles. This article covers what that looks like and how to structure a resume that gets past ATS filters and impresses a human reader.

What replaces professional experience on an entry-level resume
Projects are the primary substitute for professional experience. A project is any piece of software you designed and built — it doesn't need to be used by anyone else. The important thing is that it demonstrates real problem-solving, not just tutorial reproduction.

A strong project for an entry-level resume answers four questions: what problem does it solve, how does it work technically, what was the hardest part to build, and where can I see the code and/or a live demo? Projects that answer those four questions carry significant weight.

Education is a secondary signal — but how you present it matters. If you have a Computer Science degree, list relevant coursework (Data Structures, Algorithms, Databases, Operating Systems) rather than just the degree. If you completed a bootcamp, list the stack you learned and any graduation project. If you're self-taught, list the structured resources you completed (freeCodeCamp certifications, The Odin Project, Coursera specialisations).

Verified quiz scores fill the credibility gap that self-taught developers often feel most acutely. When you haven't worked in professional environment, it can feel like there's no external signal validating your skills. A quiz score — "JavaScript: 79% accuracy, 3 attempts" — is that external signal. It's not a work sample, but it's more credible than "JavaScript: intermediate (self-assessed)."

How to structure an entry-level developer resume
The biggest mistake entry-level developers make is copying senior developer resume structures. A two-page resume with a sparse experience section and four lines of education is the wrong structure for someone with no professional experience. Here's what works better.

Lead with a summary that's honest and specific. "Recent bootcamp graduate with 6 months of hands-on React + Node.js development. Built 3 full-stack projects. Looking for an entry-level frontend or full-stack role where I can contribute from day one." Honest, specific, confident — not generic.

Put projects immediately after the summary. Don't bury them at the bottom where you'd normally put education. Projects are your experience section.

Use the same bullet point format as a professional experience entry. Project: eCommerce Storefront. Stack: React, Node.js, PostgreSQL. Bullets: "Built a product catalogue with server-side filtering handling 5,000+ SKUs," "Implemented JWT authentication with refresh token rotation," "Deployed to Vercel (frontend) + Railway (backend) with CI/CD via GitHub Actions." That structure reads like a job entry.

Keep it to one page. Entry-level resumes that run to two pages waste space and signal poor editing judgment.

The skills section for junior developers
List only skills you can be interviewed on. The skills section on an entry-level resume is particularly dangerous territory — it's tempting to list every technology you've ever touched. A recruiter who sees "Python, Java, C++, React, Angular, Vue, Docker, Kubernetes, AWS, GCP" on a junior resume knows immediately that at least 80% of it is surface-level exposure. It undermines everything else.

List 8-12 skills you're genuinely comfortable discussing in an interview. If you've built 3 React projects, React is on the list. If you watched a Docker tutorial but have never written a Dockerfile from scratch, Docker is not on the list.

Take the Skeelzy quiz for your core skills before finalising your resume. Your quiz scores will tell you objectively which skills to list with confidence and which ones need more work.

Original Post: https://skeelzy.com/blog/developer-resume-no-experience

React Quiz: 10 Questions That Reveal Your Real Skill Level

Swapnil Nakate — Tue, 31 Mar 2026 12:38:10 +0000

React is the most commonly listed framework on developer resumes and one of the most commonly tested in interviews. But the gap between developers who list "React" and developers who actually understand React at a senior level is enormous.

What separates them? Not whether they know the syntax. The difference is understanding why React behaves the way it does — the rendering model, the rules of hooks, when to optimise and when not to, how to think about state vs derived state.

The concepts that separate junior from senior React developers

Understanding the rendering model. React re-renders a component when state changes, when props change, or when a parent re-renders. Most developers know the first two. Many don't think carefully about the third — which is why they end up with unnecessary re-renders that hurt performance.

Understanding hooks correctly. The rules of hooks aren't arbitrary restrictions — they exist because hooks are implemented as a linked list tied to render order. If you understand that, you'll never write a conditional hook and you'll understand why hooks must be called at the top level.

Knowing when to optimise and when not to. React.memo, useMemo, useCallback — these are tools for specific situations, not defaults. Premature optimisation with these tools can actually make things worse by adding reference comparison overhead.

Understanding useEffect and its dependency array. This is where most bugs live. Missing dependencies cause stale closures. Unnecessary dependencies cause infinite loops. The cleanup function exists for a reason — omitting it causes memory leaks.

10 questions that test real React knowledge

Work through these before reading the explanations:

A parent component re-renders. Under what conditions does a child component re-render? (Hint: it's not just when props change.)
What happens if you call a hook inside a conditional? Why does React enforce this restriction?
You have a component rendering a list of 1000 items that is noticeably slow. What's the first thing you investigate before reaching for useMemo or React.memo?
What's the difference between useCallback and useMemo? When would you use each?
You have a useEffect with an empty dependency array that runs an async function. The async function updates state. What potential bug exists and how do you fix it?
What's the difference between controlled and uncontrolled components? When is an uncontrolled component appropriate?
React.memo wraps your component. A parent re-renders and passes a new object literal {} as a prop. Does the child re-render? Why?
What is a render cycle? What can cause an infinite render loop?
You're using useContext to subscribe to a context value. When does this component re-render?
What is the purpose of the key prop in a list? What happens if you use array index as the key?

Why these questions matter for interviews

These questions come up in React interviews because they test the mental model, not just the API. A developer who's memorised the docs can answer "what does useState do?" A developer who truly understands React can answer why useEffect runs twice in development with StrictMode, or why an effect with no dependencies still has access to the component's state via closure.

Senior React interviews often look like this: the interviewer gives you a component with a bug — usually a performance issue, an infinite loop, or a stale closure — and asks you to find and fix it. The fix is usually one line. But finding it requires the exact conceptual understanding that surface-level tutorials skip.

What your React quiz score means

The Skeelzy React quiz adapts to your performance — questions get harder as you score higher. A 90%+ accuracy score means you're operating at senior React level. A 60–75% score means you know React well enough to build with it but have gaps in the deeper concepts that interviewers probe.

Your score isn't just for your own feedback. When you add a verified React score to your Skeelzy resume, it tells recruiters exactly how your knowledge compares to the benchmark — no guessing, no inflated self-assessment.

The best time to take the quiz is before you start your job search, so you know what to brush up on.

Why Your Developer Resume Skills Section Is Lying (And How to Fix It)

Swapnil Nakate — Tue, 31 Mar 2026 10:17:03 +0000

Every developer resume looks the same. Somewhere near the bottom there's a skills section. It says React, TypeScript, Node.js, AWS, Docker. Maybe PostgreSQL. Maybe some soft skills like "problem-solving" or "team player."

The problem? Every other developer applying for the same role has the exact same list. And the recruiter reading your resume has no way of knowing whether you actually know React or whether you watched a YouTube tutorial three years ago and never touched it again.

In 2026, self-reported skills are the weakest signal on a resume. And the developers getting interviews are the ones who've replaced the list with proof.

Why the skills section stopped working

The skills section made sense when resumes were primarily read by human recruiters who would cross-reference what they saw against what came up in the interview. The skills section was a conversation starter.

That world is gone. Today, the first reader of your resume is an ATS (applicant tracking system). It scans for keywords. If your resume says React and the job description says React, you pass the first filter. The problem: everyone who wants the job also passes that filter.

When the hiring manager finally reads your resume, they're looking at a stack-ranked list of applicants who all say they know the same things. Your "React: Advanced" self-assessment doesn't help them. It's the same claim everyone else is making.

The result: developers with genuinely strong skills are rejected because their resume looks identical to candidates with much weaker skills. And developers with shallow knowledge pass because they know how to keyword-stuff.

The signal recruiters actually trust in 2026

Every resume advice article written in 2026 says the same thing: link to proof. Recruiters in 2026 expect to be one click away from verification. GitHub links show your code. Portfolio links show your work. But what about the skills themselves?

GitHub shows that you write code, not that you understand the underlying concepts well. A portfolio shows finished products — it doesn't show whether you understand why your React component was re-rendering 50 times or how you'd design a database schema from scratch.

What recruiters and hiring managers actually trust: demonstrated knowledge. Quiz scores, certification results, evidence that you were tested on a topic and passed. Not because certifications are always reliable, but because they represent an external party saying "this person met a standard" — as opposed to the candidate saying "I think I'm pretty good at this."

What verified skills look like on a resume

Skeelzy takes a different approach. Instead of asking you to self-report your skill level, it tests you. You take a 10-question adaptive quiz on a specific skill — React, TypeScript, SQL, AWS, whatever's relevant to the job you're applying for. Your score is recorded.

When you build your resume on Skeelzy, those scores appear as verified skill badges on your public resume page. A recruiter clicking through to your resume sees "React: 87% accuracy across 3 attempts" — not "React: Advanced (self-assessed)."

That's a fundamentally different signal. It doesn't just claim you know React. It shows your actual performance on questions about React. The recruiter can see the score, the number of attempts, and whether your accuracy improved over time. That's the kind of transparency that builds trust before the first interview.

How to shift from self-reported to verified

You don't need to scrap your existing resume. You need to add evidence to it.

Start with the skills that matter most for the roles you're targeting. If you're applying for React-heavy roles, take the React quiz. Take the TypeScript quiz. Take the Node.js quiz. If you're going for backend roles, SQL, System Design, and AWS are worth proving.

Take each quiz at least twice before adding the skill to your resume. Skeelzy tracks your accuracy across attempts — a second or third quiz showing improvement is more impressive than a single lucky first attempt.

Then build your Skeelzy resume. Your quiz scores auto-populate into the skills section as verified badges. Your public resume URL shows those badges to anyone who clicks through — recruiters, hiring managers, anyone you send it to.

The skills section transforms from a keyword list that looks like everyone else's into a skills breakdown that shows your actual proficiency. That's the resume that gets callbacks in 2026.

The bottom line

Listing skills doesn't prove skills. In a competitive job market where every developer claims the same stack, the candidates who can show verified knowledge have a concrete advantage.

Start with the skill you're most confident in. Take the quiz. See your score. Add it to your resume. The gap between "I know React" and "87% accuracy on React quiz" is the gap between hoping you get an interview and earning one.