DEV Community: Abhishek

WispShot is for sale Full Ownership,

Abhishek — Thu, 01 Oct 2026 18:45:23 +0000

I’m looking for one buyer to acquire WispShot.
WispShot is a macOS app built around the MacBook notch. It started with screenshots and screen recording, and I’ve expanded it with features like Shelf, Claude View, Calendar, Clipboard, Timer, Mac Status, Notes, and Screen Time.
This is not a source-code template or a license that I’ll sell multiple times.
The buyer will receive the complete product, including:

Full macOS app source code
Full website
Git repository
Supabase backend
Database setup
Product branding
Existing features and UI
Full ownership of WispShot after the sale I’m only planning to sell it once, so after the transfer the buyer becomes the sole owner of the product. This could be a good fit for someone who wants to continue building a macOS productivity/notch app without starting from zero. If you’re interested in acquiring WispShot, message me and I can share more details about the codebase, current features, backend, and transfer process.

DM me on X https://x.com/Iamabhisonkar

Added more features into WispShot.

Abhishek — Thu, 01 Oct 2026 18:24:00 +0000

I originally started it around screenshots and screen recording, but I’ve been experimenting with what else actually makes sense around the MacBook notch.
Since my last post, I’ve added:

Shelf
Claude View
Calendar
Clipboard
Timer
Mac Status
Notes
Screen Time The idea is slowly becoming clearer: use the notch as a small workspace for things you want to check, keep, or access without switching apps. Still figuring out what belongs in WispShot and what doesn’t. I don’t want to just keep adding features for the sake of it. Next I’m focusing more on making the existing features feel connected and actually useful. Curious which of these you’d use the most.

wispshot.vercel.app

I Built Wispshot: A Temporary Dock for Screenshots Inside the MacBook Notch or Desktop

Abhishek — Fri, 25 Sep 2026 17:45:45 +0000

I built Wispshot because I was tired of taking screenshots.

While coding, I constantly need to capture multiple screenshots and paste them into AI coding tools, documentation, chats, or other apps.

The workflow was always the same:

Take a screenshot.
Take another one.
Take another one.

And suddenly my Desktop is full of screenshots that I only needed for a few minutes.

So I built Wispshot.

Wispshot is a native macOS app that turns the MacBook notch into a temporary space for screenshots, screen recordings, and files.

Instead of sending everything straight to your Desktop, Wispshot temporarily holds it until you decide what to do with it.

You can capture multiple screenshots and keep them together in the notch.

When you need one, you can copy it, save it, open it, or delete it.

The part I care about most is the workflow.

I can take three screenshots while working, leave them there, and then paste them into my coding tool whenever I need them.

No Desktop clutter.

No Finder.

No temporary folder.

No cleanup afterward.

I also wanted the app to feel like part of macOS rather than another floating utility window.

When Wispshot is idle, it stays minimal around the notch.

Move the cursor toward it and it expands into the temporary workspace.

That idea became the foundation of the app:

Capture. Hold. Decide.

Wispshot is built natively for macOS using Swift, SwiftUI, and AppKit.

I'm currently working through the final distribution process, including Developer ID signing, notarization.

The project started from a very small personal annoyance, but I think there is something interesting about building tools around the tiny workflows we repeat every day.

Wispshot is my attempt to make temporary files actually feel temporary.

You can check it out at:

wispshot.vercel.app

I'd love to hear from other Mac users and developers.

What temporary files do you create during your workflow and then immediately have to clean up?

Why I Built a Waitlist Tool That Forces You to Validate Before You Code

Abhishek — Tue, 25 Aug 2026 13:18:44 +0000

I've lost count of how many side projects I've abandoned. Not because the code didn't work — because nobody wanted what I'd built. I'd spend two, three, sometimes four months architecting a schema, wiring up auth, polishing a dashboard nobody asked for, and then launch to a Product Hunt post with one upvote and zero signups. Silence is a special kind of expensive. It doesn't just cost you the hours. It costs you the conviction to try again.

At some point I stopped asking "how do I build faster" and started asking a different question: "how do I know if this is worth building at all, before I write a single line of backend code?" That question is the entire reason WaitlistTest exists.

This post is part build log, part argument for why validation-first is the only sane way to build software as a solo founder in 2026, and part honest look at what I got wrong along the way.

The pattern I kept repeating

If you've spent any time in indie hacker circles, you already know the shape of this story, because it's not just mine — it's almost everyone's first few attempts.

The guesswork phase. You get an idea. It feels obvious. You start designing the database schema before you've talked to a single potential user, because designing schemas is comfortable and talking to strangers is not.
The burnout cost. Weeks turn into months. You've sunk real opportunity cost — time you could have spent on literally anything else, including a version of the same idea validated properly.
Zero pre-warmed audience. You arrive at launch day with nobody waiting. No email list, no followers who care, no one hitting refresh on your Stripe dashboard.
The silent launch. You post to Product Hunt, Indie Hackers, X. You get a handful of polite comments. Maybe one sale, if you're lucky. Mostly crickets.

I did this loop at least three times before it clicked that the problem wasn't my code quality or my marketing copy. The problem was sequencing. I was validating after building, when the entire point of validation is to happen before you sink cost into something nobody wants.

The reframe: treat your idea like a hypothesis, not a foregone conclusion

The mental shift that actually changed how I build software was treating every new idea as an unproven hypothesis rather than a plan I was already committed to. A hypothesis needs a test. A test needs a control and a way to read the result. That's it. That's the whole insight, and it's not novel — scientists have known this for centuries, and lean startup methodology has been preaching it for over a decade. What was missing, at least for me, was tooling that made the test itself trivially fast to set up, so that "I should validate this" didn't become its own procrastination excuse.

So the workflow I landed on looks like this:

Spin up a landing page in minutes, not days. If setting up the test takes as long as a small MVP, you haven't saved yourself anything.
Send cold traffic to it. A hundred visits from X, Reddit, or Indie Hackers — free distribution, no ad spend required at this stage.
Read the signal honestly. If a meaningful chunk of visitors opt in, that's a green light. If almost nobody does, that's information too, and it's a lot cheaper to receive now than after three months of development.
Only then, write code. With actual buyers already waiting, launch day stops being a guess and starts being a formality.

This is the loop WaitlistTest is built around. Not just "collect emails" — a lot of tools do that — but a structured way to compare hooks, read a real conversion number, and make a go/no-go call on a timeline instead of an open-ended vibe check.

What actually differentiates a waitlist tool from a landing page builder

When I started building this, my first instinct was to compete on the same axis every other tool competes on: prettier templates, more embed options, cleaner CNAME setup. Those things matter, and I built them, but they're not what makes the product different. Here's the differentiator I kept coming back to:

A landing page builder tells you how many people gave you an email address. A validation tool tells you whether your idea is worth pursuing.

Those sound similar. They are not the same. The gap between them is entirely in what happens after signups start rolling in — whether the tool helps you interpret the number, compare it to a baseline, and make a decision, or whether it just hands you a CSV and wishes you luck.

Concretely, that meant building:

A/B hook testing, so you're not guessing whether "Zero Stripe Fees" beats "Built for Freelancers" as a value proposition — you split traffic and let the data answer.
A 14-day checkpoint structure, so an idea doesn't quietly languish forever. You commit to a decision window: keep going, or archive it and move to the next hypothesis.
A portfolio view, because most serial builders aren't testing one idea at a time. They're running several small bets in parallel, and they need to see all of them side by side rather than juggling separate dashboards or spreadsheets.
Referral loops, because a waitlist that only grows from cold outreach undersells what an eager early audience can do for you organically if you give them a reason to share.

None of these are complicated features individually. Collectively, they turn the product from "a form" into something closer to a lightweight research instrument.

The part nobody tells you: the tool doesn't remove the fear, it just gives you a faster no

I want to be honest about something, because I think a lot of validation-first advice oversells the emotional ease of this approach. Getting a waitlist live in two minutes doesn't make it comfortable to post it publicly and watch the number stay near zero. That still stings. What it changes is the cost of that sting. Three months of silent development followed by silence at launch is a gut punch that costs you a season of your life. A waitlist page that gets 3% signups from a hundred cold visitors over four days is a much smaller, cheaper punch — and it arrives early enough that you can shrug, rewrite the hook, or kill the idea entirely and move to the next one without having burned real time on infrastructure nobody needed.

The tool doesn't remove the emotional work of hearing "no." It just makes "no" arrive faster and cost less, which — over a career of building multiple things — compounds into a massive time advantage over people who only ever validate the expensive way.

Where I've landed on pricing, and why

I priced this as a free-to-start tool deliberately, because the entire premise is "test before you commit financially," and it would be a little hypocritical to gate the validation step itself behind a paywall. The free tier gets you one live waitlist page and unlimited signups, which is enough to run a real first test. Paid tiers exist for people running multiple concurrent bets, who need custom domains, white-labeling for client work, or higher email-broadcast volume — that's a different use case (agencies, serial founders) than someone testing their very first idea.

What I'd tell someone starting their first validation test

If you're reading this because you have an idea sitting in a notes app right now, here's the version of this advice I wish someone had given me three failed projects ago:

Don't design your database before you have a landing page. The schema can wait. The hook cannot.
Pick one core promise and test that, not five features. Complexity in your pitch is often a sign you don't actually know what the product does yet.
Give yourself a real deadline to read the result. Two weeks is usually enough. Open-ended "let's see how it goes" is how ideas die slowly instead of quickly.
Treat a low conversion number as data, not a verdict on your worth as a builder. It's telling you about the hook and the audience, not about you.
Where this goes from here

I'm still actively building this — adding deeper CRM-style lead pipelines, more integrations, better analytics on which traffic sources convert best. If you're a solo founder or indie hacker who's ever built something in the dark for months only to launch to silence, I'd genuinely like to hear how you currently validate ideas before committing to them, because I think the tooling in this space is still early and there's a lot left to figure out.

If you want to see the actual workflow, I've got it live at waitlisttest.com — there's a free tier if you want to run your own test on whatever idea is sitting in your notes app right now.