DEV Community: Mike Davis

SMS-Activate Shut Down — Finding a Real Alternative for My CI/CD Pipeline

Mike Davis — Mon, 06 Apr 2026 15:12:18 +0000

After SMS-Activate closed in December 2025, I tested five SMS activate alternatives to automate phone verification in E2E tests. Code examples and honest results.

Last October, our QA pipeline broke at 2 AM. The reason? My personal phone number — the one hardcoded into 14 different Playwright specs — got rate-limited by Twilio's verification flow. Every test that touched 2FA went red. PagerDuty woke me up, and I spent the next hour manually rotating a number from a prepaid SIM I kept in my desk drawer.

I'd been meaning to set up a proper virtual number provider for months. We had an SMS-Activate account that one of our QA guys used for manual testing, but I never got around to integrating its API into the pipeline. Then, on December 29, SMS-Activate shut down entirely — and suddenly I had no choice but to find a real solution.

This post is about the five SMS-Activate alternatives I tested, what worked, what didn't, and the setup we ended up with.

The Problem Nobody Talks About

If you've ever built anything with phone-based auth, you know the pain. You need real phone numbers that:

accept OTP codes from services like Google, Telegram, or your own Twilio/Vonage setup
can be provisioned programmatically (no human in the loop)
don't get flagged as VoIP by strict verification systems
cost less than the mass of prepaid SIMs gathering dust in your office

Our stack is a Django REST backend + Next.js frontend, deployed via GitHub Actions. We run ~200 E2E tests per push to main, and about 30 of them involve SMS-based flows: sign-up, password reset, 2FA toggle, phone number change. Each one needs a unique, working phone number.

I spent roughly three weeks testing different SMS-Activate alternatives. Here's what I found.

What I Was Looking For

Before I get into specific services, here's the criteria I used. This isn't a generic "best tools" list — these are the things that mattered for our CI/CD context:

API-first. If I can't call it from a shell script or a pytest fixture, it doesn't exist for me. I need to request a number, poll for an incoming SMS, and release the number — all via HTTP.

Number freshness. Reused numbers are the #1 cause of failed verifications. If the number was already used to register a Google account last week, it'll get rejected. I need services that cycle through large pools.

Country coverage. We test geo-specific onboarding flows for US, DE, ID, and BR users. I need numbers from at least these four countries.

Cost at scale. At 30 tests × ~5 CI runs per day × 22 workdays, that's 3,300 numbers/month. Price per number matters a lot at this volume.

Speed. If SMS delivery takes more than 20 seconds, my test times out. I set a hard ceiling of 15s for OTP receipt.

My Testing Setup

Here's the simplified pytest fixture I ended up with. The actual implementation varies per provider, but the interface is the same:

# conftest.py
import httpx
import time

class SMSProvider:
    """Abstract base for virtual number providers."""

    def get_number(self, country: str, service: str) -> dict:
        raise NotImplementedError

    def wait_for_code(self, activation_id: str, timeout: int = 15) -> str:
        raise NotImplementedError

    def release(self, activation_id: str) -> None:
        raise NotImplementedError


@pytest.fixture
def phone_number(sms_provider):
    """Provision a temporary number, yield it, then release."""
    result = sms_provider.get_number(country="US", service="google")
    yield result["phone"], result["activation_id"]
    sms_provider.release(result["activation_id"])

With this abstraction, switching providers is a one-line config change. Which came in handy — because my first choice didn't work out.

The Five Services I Actually Tested

I originally tried seven, but two had APIs that returned 500s on the first call, so I'm not going to waste your time with those. Here are the five that at least functioned.

1. HeroSMS

Site: hero-sms.com

This ended up being our daily driver, so I'll go deeper here.

I found HeroSMS while digging through a Telegram group where people discuss automation tooling. The API is straightforward — REST with JSON responses, no OAuth dance, just an API key in the header.

What convinced me to keep testing it past the trial phase:

Number pool size. They claim 500K+ fresh numbers daily, and in practice, I've never hit a "no numbers available" wall, even for Google verifications from US numbers at peak hours. Over three months of daily CI runs, our success rate for OTP receipt sits at 94.7% — the remaining ~5% are timeouts on the service side (Google being slow), not HeroSMS failing to deliver.

Pricing at our volume. Numbers start at fractions of a cent. For our mix of US/DE/ID/BR numbers across Google, Telegram, and our own app, the average cost came out to ~$0.03/verification. At 3,300/month, that's under $100/month for the entire test suite. Before this, we were spending ~$40/month on prepaid SIMs and still running out.

API response time. Number provisioning takes 1–3 seconds. SMS delivery averages 4–8 seconds in my logs. Well within the 15-second budget.

Here's the wrapper I wrote:

class HeroSMSProvider(SMSProvider):
    BASE = "https://hero-sms.com/api"

    def __init__(self, api_key: str):
        self.client = httpx.Client(
            headers={"Authorization": f"Bearer {api_key}"},
            timeout=30,
        )

    def get_number(self, country: str, service: str) -> dict:
        resp = self.client.get(f"{self.BASE}/get-number", params={
            "country": country,
            "service": service,
        })
        resp.raise_for_status()
        data = resp.json()
        return {
            "phone": data["number"],
            "activation_id": data["id"],
        }

    def wait_for_code(self, activation_id: str, timeout: int = 15) -> str:
        deadline = time.monotonic() + timeout
        while time.monotonic() < deadline:
            resp = self.client.get(f"{self.BASE}/get-status", params={
                "id": activation_id,
            })
            data = resp.json()
            if data.get("code"):
                return data["code"]
            time.sleep(2)
        raise TimeoutError(f"No OTP received within {timeout}s")

    def release(self, activation_id: str) -> None:
        self.client.post(f"{self.BASE}/cancel", json={
            "id": activation_id,
        })

The catch: payments are crypto-only. We had to set up a company crypto wallet just for this, which was a minor bureaucratic headache. If your finance team is allergic to crypto, this might be a dealbreaker. For us, it was a 30-minute setup and then we forgot about it.

2. SMSPool

Site: smspool.net

SMSPool was my second choice and the one I recommend if you need non-VoIP numbers specifically. Some services (looking at you, Google Voice and Cash App) reject VoIP numbers outright. SMSPool has a pool of real-SIM-backed numbers that pass these checks.

The API is decent — not as fast as HeroSMS, but reliable. Average OTP delivery was 8–12 seconds in my tests. They accept Stripe payments, which made our finance team happier.

Where it fell short for us: number availability for Indonesian numbers was inconsistent. Some days we'd get them instantly, other days the queue would timeout. For US and DE numbers, no issues.

Good for: teams that primarily need US/EU non-VoIP numbers and want to pay with a regular credit card.

3. 5SIM

Site: 5sim.net

5SIM is the cheapest option I tested — numbers from $0.008. The coverage is wide (180+ countries), and for low-volume or manual testing, it's genuinely fine.

The problem showed up at scale. Out of 500 test runs over two weeks, about 12% of numbers failed to receive OTPs. That's significantly higher than what I saw with HeroSMS (5%) or SMSPool (7%). The failures were inconsistent — sometimes it was a US Google verification, sometimes a German Telegram code. Hard to debug, harder to trust in CI.

I still keep a 5SIM balance for ad-hoc manual testing when I need a number from an unusual country (say, Bangladesh or Peru). It's great for that. I wouldn't run my pipeline on it.

Good for: manual testing, exploratory work, tight budgets.

4. SMS-Man

Site: sms-man.com

SMS-Man has the broadest service catalog I've seen — 1,000+ supported services. If you need to verify some obscure Chinese app or a niche social network, they probably have it.

The API works, the Telegram bot is a nice touch for quick manual grabs, and the pricing is reasonable ($0.05+). But for my use case (automated CI), the speed wasn't there. Average OTP delivery was 10–15 seconds, and about 8% of requests hit my timeout ceiling. The free shared numbers are a cool idea for quick one-off tests but obviously not suitable for anything serious.

Good for: wide service coverage, manual testing via Telegram bot, migrating from SMS-Activate (similar workflow).

5. Veritel

Site: veritel.io

Veritel's selling point is that every number is backed by a physical SIM card connected to actual hardware. This means near-carrier-grade reliability — and their stats back it up. In my tests, OTP delivery success was 96%, the highest of any service I tried.

The trade-off is price. At ~$0.10+ per number, Veritel is roughly 3x more expensive than HeroSMS for our volume. At 3,300 numbers/month, that's ~$330 vs ~$100. We couldn't justify the difference given that HeroSMS was already clearing our success threshold.

I'd use Veritel for a specific scenario: if you're testing against a platform that's extremely aggressive about rejecting virtual numbers (think: banking apps, fintech verification), Veritel's physical SIM approach is worth the premium.

Good for: fintech/banking verification testing, platforms that reject VoIP aggressively.

What We Settled On

HeroSMS runs our daily CI. SMSPool is our fallback for the rare case when we need a guaranteed non-VoIP US number. 5SIM sits in my personal toolkit for ad-hoc exploration.

The total monthly cost went from "$40/month on SIMs that still didn't cover our test matrix" to "~$100/month with full automation and 95% success rates." More importantly, no one has been woken up at 2 AM because a hardcoded phone number got rate-limited.

Practical Tips If You're Setting This Up

Don't hardcode the provider. Use the abstraction pattern from my fixture above. You will switch providers at some point — make it painless.

Set a timeout and retry with a different number. Not every number works every time. My fixture has a retry wrapper that requests a new number if OTP doesn't arrive within 15 seconds. Two retries max, then fail the test.

Track success rates. I log every verification attempt with provider, country, service, time-to-OTP, and success/failure. This data is what told me HeroSMS was outperforming the others — gut feeling alone would've kept me on 5SIM because it's cheaper.

Use country-specific numbers for geo-tests. Don't just grab "any available number." If your test checks that a German user sees the German onboarding flow, use a DE number. It matters for some services' fraud detection.

# In your CI config (e.g., .github/workflows/e2e.yml)
env:
  SMS_PROVIDER: herosms
  SMS_API_KEY: ${{ secrets.HEROSMS_API_KEY }}
  SMS_FALLBACK_PROVIDER: smspool
  SMS_FALLBACK_API_KEY: ${{ secrets.SMSPOOL_API_KEY }}

Wrapping Up

The SMS-Activate shutdown caught a lot of people off guard, but honestly, the market for SMS-Activate alternatives in 2026 is more competitive and mature than what we had before. Services now compete on API reliability and delivery speed, not just price.

Virtual number services aren't glamorous tooling. Nobody's giving a conference talk about their SMS verification pipeline. But if you ship anything with phone-based auth — and in 2026, that's most of us — having a reliable, automated verification flow in your tests is the kind of infrastructure investment that pays for itself the first time it prevents a broken release.

If you've solved this differently — maybe with a mock layer, or a self-hosted SMS gateway — I'd be curious to hear about it. My approach works, but I'm sure there are better ones.

The code examples above are simplified for readability. In production, add proper error handling, rate limiting on your side, and secret management. Don't commit API keys to your repo — use your CI platform's secret store.

The Hidden Cost of Phone-Based Auth: What I Learned After 18 Months

Mike Davis — Wed, 01 Apr 2026 10:35:45 +0000

We added SMS verification to our app expecting it to be simple. 18 months later, I have opinions about carrier filtering, Twilio bills, and abuse bots.

Eighteen months ago, our PM walked into standup and said: "We need phone verification for sign-up. Users are creating fake accounts with disposable emails. Should be a weekend project, right?"

It was not a weekend project.

What followed was a year and a half of unexpected Twilio invoices, ghost messages eaten by carrier filters, an abuse wave that nearly bankrupted our SMS budget, and a slow realization that phone-based auth is one of those things that looks simple on a whiteboard and gets complicated the moment real humans in real countries try to use it.

This isn't a tutorial on how to implement 2FA. There are plenty of those. This is the stuff nobody warned me about.

The Twilio Bill That Made Finance Call Me

Our app is a B2B SaaS tool — think project management for small agencies. We launched phone verification for sign-up in March 2024. The plan was straightforward: user enters phone number, we send a 6-digit code via Twilio, user enters code, done.

I estimated the cost based on our existing user growth: ~800 new sign-ups per month, $0.0079 per SMS to US numbers. That's about $6.30/month. I told finance to expect $10–15/month with some buffer.

The first month's bill was $47.

Here's what I didn't account for:

Retries. Users don't always receive the first SMS. They click "resend." On average, each successful verification took 1.4 messages — some users hit resend 3–4 times. That's a 40% overhead on every estimate you'll ever make.

International numbers. We're US-based, but about 30% of our users aren't. Sending an SMS to India costs $0.0262. Germany is $0.0637. UAE is $0.0587. That "30% international" slice was eating 70% of the budget.

Failed deliveries you still pay for. Twilio charges you when the message is accepted by the carrier, not when the user receives it. If the carrier silently drops it — and they do, more often than you'd think — you still pay.

By month three, we were spending $120/month. By month eight, after a Product Hunt launch bumped sign-ups, we hit $340 in a single month. Not catastrophic, but a far cry from the "$10–15" I promised.

Carrier Filtering: The Silent Killer

The cost was annoying. The delivery failures were worse.

Around month four, our verification success rate dropped from ~92% to ~71% over two weeks. No code changes. No infrastructure issues. Support tickets flooded in: "I never received the code."

It took me three days to figure out what happened. The answer: carrier filtering.

Mobile carriers run spam filters on application-to-person (A2P) SMS traffic. If your messages look like they're coming from a bot — same content, high volume, short codes — carriers can silently drop them. No error code. No bounce notification. The message just vanishes.

What triggered it for us was a combination of factors:

Message template. Our OTP message was: Your verification code is: 482901. That's basically the platonic ideal of an A2P message. Every spam filter in the world is trained to recognize this pattern.

Volume spike. The Product Hunt traffic tripled our daily SMS volume overnight. Sudden spikes are a classic spam signal.

Shared short code. We were using Twilio's shared short code pool. Our messages were being sent from the same numbers that other Twilio customers used — some of whom were probably sending actual spam.

The fix involved three changes:

First, I switched to a dedicated Twilio Messaging Service with a registered A2P 10DLC campaign. This is Twilio's system for whitelisting your traffic with US carriers. The registration process took two weeks and cost $15 — but delivery rates jumped back to 91%.

Second, I added slight variations to the message body. Instead of the same template every time, I rotate between a few versions and include the app name. Small thing, but it helps avoid pattern-based filtering.

Third — and this was the expensive one — I added Twilio Verify as a fallback. When our primary SMS channel fails, we fall back to Twilio's managed verification service, which handles carrier negotiation on their end. It costs more per message ($0.05 vs $0.0079), but the delivery rate is significantly higher.

The Abuse Wave

Month eleven. A Wednesday morning. I'm looking at our dashboard and notice something odd: 2,400 new accounts created in the last 6 hours. Our normal daily sign-up rate is about 40.

Someone was bot-registering accounts using virtual phone numbers.

The irony is not lost on me — I now use virtual numbers myself for testing (I wrote about that in my previous post about mocking 2FA). But being on the receiving end of it was educational.

Here's what the attack looked like:

Automated script hits our registration API
Provides a phone number from a virtual number pool (we later identified the numbers as VoIP-based, mostly from Southeast Asian providers)
Receives OTP via the virtual number service
Completes registration
Immediately uses the account to post spam in our public project boards

The attacker was spending maybe $0.02 per virtual number. We were spending $0.05–0.10 per verification attempt (including retries and Twilio Verify fallback). They were literally making us pay to get spammed.

We burned through $180 in Twilio credits in a single morning before I shut it down.

What We Did About It

Short-term: I added rate limiting by IP and by phone number prefix. More than 5 registrations from the same /24 IP block in an hour → CAPTCHA. More than 3 attempts with the same country code + first 4 digits → block for 30 minutes.

Medium-term: I integrated a phone number intelligence API (Twilio Lookup) to check whether a number is VoIP, landline, or mobile before sending the OTP. VoIP numbers get an extra verification step (email confirmation + CAPTCHA). This costs $0.005 per lookup but saved us far more in prevented abuse.

def check_number_type(phone: str) -> str:
    """Check if a phone number is mobile, landline, or VoIP."""
    resp = twilio_client.lookups.v2.phone_numbers(phone).fetch(
        fields="line_type_intelligence"
    )
    line_type = resp.line_type_intelligence.get("type", "unknown")
    return line_type  # "mobile", "landline", "voip", "unknown"

def should_require_extra_verification(phone: str) -> bool:
    number_type = check_number_type(phone)
    return number_type in ("voip", "unknown")

Long-term: We added passkey support as the primary auth method and made phone verification optional for users who set up a passkey. More on this below.

The Country Problem

I mentioned international SMS costs earlier, but there's a deeper issue: SMS doesn't work the same way everywhere.

India requires pre-registered DLT templates. If you're sending OTP messages to Indian numbers, you need to register your message template with the Telecom Regulatory Authority of India through a DLT portal. Twilio can handle this, but the registration takes 1–3 weeks and requires a local business entity or partner. We didn't know this until Indian users started reporting zero delivery.

China is effectively off-limits for most Western SMS providers. Carrier restrictions, content filtering, and regulatory requirements make it nearly impossible to reliably deliver A2P SMS from a US-based Twilio account. We ended up not supporting Chinese phone numbers for verification and offering email + TOTP as an alternative.

Brazil has specific regulations around SMS consent and a DNC (Do Not Call) registry that applies to certain types of SMS. We had to add explicit opt-in language to our verification flow for Brazilian numbers.

Several African countries have delivery rates below 60% through Twilio. We tested Vonage as a secondary provider for specific routes and saw marginally better results for Nigerian and Kenyan numbers, but it's still not great.

The lesson: if your user base is international, budget 2–3x what you'd estimate for US-only, and expect to spend significant engineering time on country-specific edge cases.

The Auth Method Comparison I Wish I'd Done Earlier

After 18 months of dealing with all of the above, I sat down and compared the actual cost and reliability of every auth method we could reasonably offer. Here's the real-world data from our app:

SMS OTP

Setup effort: Medium (Twilio integration, A2P registration, carrier troubleshooting)
Per-verification cost: $0.02–0.08 (varies wildly by country)
Delivery success: ~91% US, ~75–85% international
Abuse resistance: Low without additional checks (Lookup API, CAPTCHA)
User friction: Medium (wait for SMS, type code)

Email magic links

Setup effort: Low (you already have an email provider)
Per-verification cost: ~$0.001 (practically free with any transactional email service)
Delivery success: ~97% (spam folders are the main failure mode)
Abuse resistance: Medium (disposable email services exist, but they're easier to block)
User friction: Medium-High (switch to email app, find message, click link, switch back)

TOTP (authenticator app)

Setup effort: Low (pyotp + QR code generation)
Per-verification cost: $0.00 (runs locally on user's device)
Delivery success: 100% (no network dependency)
Abuse resistance: High (requires a real device with an authenticator app)
User friction: High for setup, Low for subsequent use

Passkeys / WebAuthn

Setup effort: High (browser API, credential storage, fallback flows)
Per-verification cost: $0.00
Delivery success: 100% (local biometric/PIN)
Abuse resistance: Very High (tied to physical device)
User friction: Very Low once set up (fingerprint/face)

Looking at this table, SMS is the worst option on almost every metric except one: user familiarity. Everyone knows how to receive a text message. Not everyone knows what an authenticator app is. Passkeys are amazing technically, but try explaining them to a non-technical user who just wants to sign up for a project management tool.

That familiarity is worth a lot. It's the reason SMS verification isn't going anywhere despite being expensive, unreliable, and abuse-prone. People understand it.

Where We Landed

Today, our auth flow looks like this:

Primary: Email magic link for registration (cheap, reliable, good enough for initial sign-up)
Optional upgrade: Passkey enrollment after first login (we nudge users with a dismissible banner)
Phone verification: Required only for specific actions (inviting team members, accessing billing, exporting data) — not for basic sign-up
TOTP: Available as an alternative to phone verification for users who prefer it

This reduced our Twilio bill from $340/month at peak to about $80/month, because we're only sending SMS for high-value actions, not every single registration. The abuse problem essentially disappeared because bots can't use email magic links to get to the phone-gated features without maintaining a persistent session.

Things I'd Do Differently

Start with email-first auth, add phone later. We went straight to phone verification because it felt more "secure." It is, marginally — but the operational cost is 10–50x higher than email, and the security improvement is negligible for most apps that aren't handling financial transactions.

Budget for international SMS from day one. If you have any international users, multiply your US-only SMS cost estimate by 3x. If you have users in India, China, or parts of Africa, multiply by 5x and add a line item for "country-specific compliance headaches."

Implement phone type checking before sending. The $0.005 Twilio Lookup call pays for itself many times over by filtering VoIP numbers, catching typos (landline numbers), and preventing abuse.

Run your verification flow through real E2E tests. I wrote about this in my previous post — mocking your OTP layer hides bugs that only show up when real carriers are involved. I'm currently setting up a nightly test suite that uses actual virtual numbers to test our verification flow end-to-end. Still iterating on which providers work best for this — will share the results once I have enough data.

Phone-based auth is one of those features that's deceptively simple. The happy path takes a day to build. Everything else takes months. If you're about to add SMS verification to your app, I hope this saves you some of the surprises I ran into.

If you've been through this — especially the carrier filtering and international delivery issues — I'd genuinely like to hear how you handled it. My solutions work, but they're held together with more duct tape than I'd like to admit.

Why I Stopped Mocking 2FA in Tests (And What I Do Instead)

Mike Davis — Wed, 01 Apr 2026 10:31:47 +0000

I mocked OTP verification for two years. Then a bug hit production that my test suite should have caught. Here's what went wrong and how I fixed the approach.

I'll start with the bug that changed my mind.

Last summer, we pushed a release that broke the phone number change flow in our app. A user would enter their new number, receive an OTP, type it in — and get a 400 error. The code was correct in every way except one: someone refactored the verification endpoint and accidentally changed the OTP field name from otp_code to verification_code in the request body. The frontend still sent otp_code. The backend no longer recognized it.

Our test suite had 100% coverage on this flow. Every test passed. Green across the board.

Why? Because we were mocking the entire OTP layer.

The Mock That Lies

Here's roughly what our test setup looked like:

# conftest.py — the old way
@pytest.fixture
def mock_otp(monkeypatch):
    """Skip OTP verification entirely in tests."""
    monkeypatch.setenv("SKIP_OTP_VERIFICATION", "true")

# In the actual verification view:
def verify_otp(request):
    if os.environ.get("SKIP_OTP_VERIFICATION"):
        return Response({"status": "verified"}, status=200)

    otp_code = request.data.get("otp_code")
    # ... actual verification logic

You see the problem. When SKIP_OTP_VERIFICATION is set, the function returns early. It never reads request.data. It never checks field names. It never calls the downstream SMS provider. The entire code path that actually matters — the one users hit in production — is invisible to the test suite.

We weren't testing our verification flow. We were testing a shortcut.

"But Everyone Does This"

I know, I know. Mocking external dependencies is Testing 101. And to be fair, there are legitimate reasons people mock OTP:

Speed. Waiting for a real SMS adds 5–15 seconds per test. If you have 30 verification tests, that's up to 7 extra minutes per CI run.

Cost. Services like Twilio charge per SMS. At $0.0079/message for US numbers, 30 tests × 5 CI runs/day × 22 days = $25/month just for tests. Not huge, but it adds up.

Flakiness. Real SMS delivery is non-deterministic. Networks hiccup. Carrier filtering eats messages. Timeouts happen. Nobody wants a red build because Vodafone's gateway in Frankfurt had a bad morning.

These are valid concerns. I'm not going to pretend otherwise. But there's a spectrum between "mock everything" and "mock nothing," and I was way too far on the wrong end.

What the Mock Was Actually Hiding

After the otp_code → verification_code incident, I did an audit. I went through every test that involved OTP and asked: "What production behavior is this test actually exercising?"

The answer was depressing. Here's what our mocks were hiding:

Field name mismatches. The bug that started this whole thing. Mock returns early, never reads the request body, never catches field renames.

Timing issues. Our OTP codes expire after 5 minutes. We had a bug where the expiry check used datetime.now() instead of datetime.utcnow(), causing failures for users in certain timezones. The mock bypassed the expiry check entirely.

Rate limiting. We rate-limit OTP requests to 3 per phone number per hour. A refactor accidentally reset the counter on every request instead of incrementing it. No test caught it — the mock never touched the rate limiter.

Error handling. What happens when the SMS provider returns a 503? When the phone number format is invalid? When the country code doesn't match the number? All of these paths were invisible because the mock replaced the entire function.

I counted seven distinct bugs in the previous six months that our tests should have caught but didn't, all because of the OTP mock.

The Middle Ground: Mock the Network, Not the Logic

My first instinct was to rip out all mocks and hit a real SMS provider in every test. That's the other extreme, and it's not great either — you get slow, flaky, expensive tests that fail for reasons unrelated to your code.

Instead, I landed on a layered approach:

Layer 1: Mock at the HTTP boundary (unit/integration tests)

Instead of skipping verification logic, I mock the HTTP call to the SMS provider. The key difference: all of our code still runs. Field parsing, validation, rate limiting, expiry checks — everything executes normally. Only the final httpx.post() to Twilio (or whoever) gets intercepted.

# conftest.py — the new way
import respx

@pytest.fixture
def mock_sms_provider():
    """Mock the external SMS API, but run all our verification logic."""
    with respx.mock:
        # Mock the "send OTP" endpoint
        respx.post("https://api.twilio.com/2010-04-01/Accounts/*/Messages.json").mock(
            return_value=httpx.Response(200, json={
                "sid": "SM_test_123",
                "status": "queued",
            })
        )
        yield

@pytest.fixture
def known_otp(mock_sms_provider, monkeypatch):
    """Fix the OTP value so tests can 'enter' it, but keep all logic."""
    monkeypatch.setattr("myapp.auth.otp.generate_code", lambda: "482901")
    return "482901"

Now the test actually sends a request with the correct field names, our view parses request.data, validates the format, checks the rate limiter, calls generate_code() (which returns a fixed value), and stores the OTP in Redis with a TTL. The only thing that doesn't happen is a real HTTP call to Twilio.

The verification side works symmetrically — the test submits the known OTP value, and our code runs the full check: look up the stored code, compare, check expiry, invalidate after use.

This approach caught three of the seven bugs I mentioned within the first week of switching.

Layer 2: Real SMS in a nightly E2E suite

For the full end-to-end confidence, I run a smaller test suite once per night that actually sends and receives real SMS messages. This suite covers the critical paths: sign-up, password reset, phone change, 2FA enable/disable.

I won't go deep into the provider setup here — that's a whole separate post I'm working on — but the key idea is:

@pytest.fixture
def real_phone_number(sms_provider):
    """Get a real temporary number from an external provider."""
    result = sms_provider.get_number(country="US", service="myapp")
    yield result
    sms_provider.release(result["id"])

def test_full_signup_with_real_otp(page, real_phone_number):
    """E2E: complete signup with actual SMS delivery."""
    phone, activation = real_phone_number

    page.goto("/signup")
    page.fill("[name=phone]", phone)
    page.click("button[type=submit]")

    # Wait for real OTP from the provider
    otp = sms_provider.wait_for_code(activation["id"], timeout=20)

    page.fill("[name=otp]", otp)
    page.click("button#verify")

    expect(page.locator(".welcome-message")).to_be_visible()

This runs against staging, uses real phone numbers, and receives real OTP codes. It's slow (~45 seconds per test) and costs a few cents per run. But it runs once a day, covers 8 critical paths, and has caught two carrier-related delivery issues that no amount of mocking would have revealed.

The Split in Practice

Here's how it breaks down in our CI:

# .github/workflows/ci.yml
jobs:
  unit-and-integration:
    # Runs on every push — fast, mocked at HTTP boundary
    runs-on: ubuntu-latest
    steps:
      - run: pytest tests/ -m "not e2e" --timeout=30

  nightly-e2e:
    # Runs once per day — slow, real SMS
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - run: pytest tests/e2e/ -m "e2e" --timeout=120

The daily CI takes ~4 minutes. The nightly E2E takes ~12 minutes. Both are stable — the nightly suite has had 3 flaky failures in the last two months, all due to SMS delivery timeouts on the provider side, not our code.

The Refactoring Trick That Made This Possible

One thing that made the transition easier: I extracted all OTP logic into a single module. Before, verification code was scattered across three views, two serializers, and a middleware. Mocking was the only sane option because there was no single seam to intercept.

After refactoring:

myapp/
  auth/
    otp.py          # generate, store, verify, expire — all OTP logic lives here
    providers/
      base.py       # abstract SMS provider interface
      twilio.py     # production provider
      mock.py       # test provider (for Layer 1)

The otp.py module exposes four functions: generate_code(), send_code(phone, code), verify_code(phone, code), and check_rate_limit(phone). Every view calls these functions instead of implementing its own OTP handling. This means I have exactly one place to mock (send_code's HTTP call) and one place to fix when something breaks.

If your OTP logic is spread across your codebase, start here. The mock cleanup becomes trivial once the logic is consolidated.

What I Wish Someone Had Told Me

Mocking isn't the problem — mocking at the wrong layer is. There's a massive difference between "skip this entire feature in tests" and "intercept the external HTTP call but run everything else." The first gives you false confidence. The second gives you real coverage with controlled dependencies.

The SKIP_* env var pattern is a code smell. If your production code has if TEST_MODE: return early, you're not testing your production code. You're testing a fork of it that only exists in CI. Treat any such pattern as tech debt.

You don't need real SMS for every test. Layer 1 (mock at HTTP boundary) catches 90% of bugs. Layer 2 (real SMS) catches the remaining carrier/delivery edge cases. Running real SMS on every push is overkill and will make your team hate the test suite.

Track what your mocks hide. After every production bug, ask: "Would our test suite have caught this?" If the answer is "no, because the mock bypasses that code path," you have a mock problem. I keep a running doc of these incidents — it's been the best argument for investing in better test infrastructure.

Next up, I'm going to write about the practical side of integrating real SMS providers into a CI/CD pipeline — which services work, which ones don't, and the pytest fixtures that tie it all together. If you've dealt with this problem, I'd love to hear how you approached it.

All code examples are simplified. In reality, you'll want proper async handling, retry logic, and secret management. But the architecture holds.

SMS Activate Alternatives: Top 10 Virtual Number Services in 2026

Mike Davis — Sat, 07 Feb 2026 15:36:06 +0000

If you've ever built a registration flow, tested two-factor authentication, or simply needed a throwaway number for a sign-up, chances are you've heard of SMS-Activate. For nearly a decade, it was one of the go-to platforms for developers, QA engineers, and marketers who needed temporary phone numbers to receive verification codes.

That era ended on December 29, 2025, when SMS-Activate officially shut down. The announcement caught many users off guard — some still had active balances, open API integrations, and automation scripts tied to the platform. The hunt for reliable SMS activate alternatives began immediately.

Why Developers Need Virtual Number Services

Before diving into the list, let's clarify why these services matter beyond just "getting a code":

QA & Testing — You can't test SMS-based auth flows with a single personal number. Virtual numbers let you simulate hundreds of sign-ups across different countries without buying a drawer full of SIM cards.
Privacy — Signing up for third-party APIs, SaaS trials, or beta programs shouldn't require exposing your real phone number.
Geo-targeting — Need to test how your app handles a user from Indonesia vs. Germany? Virtual numbers from specific countries let you do exactly that.
CI/CD Pipelines — Many services offer APIs that plug directly into automated testing workflows, making OTP verification part of your test suite rather than a manual bottleneck.

With that context, here are the 10 best SMS activate alternatives worth your attention in 2026, ranked by overall value for developer workflows.

1. 🏆 HeroSMS

🔗 https://hero-sms.com

HeroSMS takes the top spot as the strongest all-around SMS activate alternative available right now. The platform provides temporary phone numbers from 180+ countries for 700+ services and applications, making it one of the broadest offerings on the market.

What stands out:

Massive daily volume — The platform adds over 500,000 new numbers daily, which means fresh, unused numbers are consistently available even for high-demand services like Telegram, WhatsApp, and Google.
Pricing starts extremely low — Numbers begin at fractions of a cent (e.g., $0.01 for TikTok/Douyin, $0.0125 for Tinder, $0.015 for WeChat). This makes it viable for bulk testing scenarios.
Crypto-only payments — HeroSMS operates on cryptocurrency top-ups, which adds a layer of anonymity. For developers in regions with limited access to international payment methods, this is a practical advantage.
API available — The platform provides an API for developers building registration software or automated testing tools.
Wholesale pricing — A five-tier discount system based on top-up volume, making it cost-effective for teams and agencies running high-volume operations.
Partner integrations — HeroSMS numbers can be purchased through automation tools like Telegram Expert, GoogleReger, and InstaReg.

How it works: Register → top up via crypto → select your service and country → purchase a number → receive the OTP code directly in your dashboard. The whole flow takes under a minute.

Best for: Developers and teams who need high-volume, low-cost virtual numbers across a wide range of countries and services with API access.

2. SMSPool

🔗 https://smspool.net

SMSPool has built a solid reputation as a versatile SMS activate alternative, especially among users who need non-VoIP phone numbers. Non-VoIP numbers are tied to physical SIM cards, which means they're accepted by services that reject virtual/VoIP numbers (looking at you, Google).

Key features:

Accepts both crypto and Visa/Mastercard (via Stripe)
Comprehensive API for automation
Offers SIM card rentals for up to 30 days
Customizable pricing per service based on available number pools
Free tier available (limited countries)

Watch out for: High demand can sometimes result in reused numbers. Support response times may take up to 24 hours.

Best for: Developers who specifically need non-VoIP numbers for services with strict verification policies.

3. 5SIM

🔗 https://5sim.net

5SIM is one of the most recognizable names in the virtual number space, offering numbers from 180+ countries with pricing starting at $0.008 per number. It's been around for years, and the platform is heavily automated.

Key features:

Extremely low entry price
Wide country and service coverage
Instant number delivery via automation
Active community and frequent number replenishment

Watch out for: Mixed reviews on reliability — some users report numbers that don't receive codes, and customer support experiences vary. Always test with a small balance first.

Best for: Budget-conscious developers and those who need numbers from less common countries.

4. SMS-Man

🔗 https://sms-man.com

SMS-Man positions itself as a direct successor to the gap left by SMS-Activate. The platform supports 1,000+ services and offers numbers from a wide selection of countries. Pricing starts at $0.05, and the interface is clean and straightforward.

Key features:

One-time use and rental number options (up to 3 months)
Telegram bot for quick number requests
Free numbers available for testing (public, shared)
Multiple payment methods
Dedicated blog with tutorials and use-case guides

Watch out for: Stock can run out for popular service-country combinations. The Telegram bot helps increase your chances of snagging a number during peak times.

Best for: Users migrating from SMS-Activate who want a familiar workflow and broad service compatibility.

5. TextVerified

🔗 https://textverified.com

TextVerified focuses specifically on non-VoIP numbers, primarily from the United States. If your use case revolves around US-based verifications (Cash App, Google Voice, Venmo, etc.), this is a strong SMS activate alternative.

Key features:

Non-VoIP numbers tied to physical SIM cards
High acceptance rate on strict platforms
API integration available
Voice verification support (not just SMS)
Bulk discounts for scaling

Watch out for: Limited to US numbers primarily. Pricing is higher than VoIP-based alternatives, but you're paying for acceptance rate.

Best for: Developers who need US-specific non-VoIP numbers with high success rates for strict platforms.

6. SMSPVA

🔗 https://smspva.com

SMSPVA has been in the game for a long time, offering both real SIM-based and virtual numbers from 60+ countries. The platform provides both temporary and rental modes with a REST API for integration.

Key features:

Dual offering: real SIM numbers + virtual numbers
REST API with JSON responses
SMS typically received in 1–3 seconds
Real SIM numbers boast a 99% delivery success rate
Rental numbers available for days, weeks, or months

Watch out for: The interface can feel a bit dated. Prices for real SIM numbers are naturally higher than VoIP alternatives.

Best for: Users who need the reliability of real SIM cards combined with the convenience of an online platform.

7. OnlineSIM

🔗 https://onlinesim.io

OnlineSIM provides a clean, user-friendly interface with both short-term and long-term rental options. With numbers from 90+ countries and over one million unique numbers in their pool, it's a reliable mid-range option.

Key features:

Short-term and long-term rental plans
90+ countries available
New numbers added daily
Free trial numbers available before committing
Simple, intuitive interface

Watch out for: Smaller country coverage compared to HeroSMS or 5SIM. However, number quality tends to be more consistent.

Best for: Users who value a clean UX and want the option to test numbers before buying.

8. Blacktel

🔗 https://blacktel.io

Blacktel is different from most services on this list — it functions more like a virtual phone, not just an SMS receiver. You get a dedicated number that can make calls, send SMS, and receive messages. It also offers eSIMs.

Key features:

Full virtual phone functionality (calls + SMS + MMS)
Dedicated numbers (not shared)
Mobile apps for Android and iOS
Crypto payments accepted
eSIM support for data connectivity
Free first number on registration

Watch out for: Pricing structure is subscription-based, which is different from the pay-per-use model of most competitors. Numbers need to stay active, or you lose access.

Best for: Users who need a persistent virtual number for ongoing use rather than one-time verifications.

9. PVAPins

🔗 https://pvapins.com

PVAPins markets itself heavily as an SMS activate alternative with a focus on OTP reliability and API stability. The platform supports major services like WhatsApp, Gmail, Telegram, TikTok, and more.

Key features:

High OTP success rate
Supports 200+ countries
Multiple payment options (Crypto, Binance Pay, Payeer, GCash, Skrill, Payoneer)
Clean API documentation
Responsive support team

Watch out for: The platform is relatively newer, so the track record isn't as established as some competitors.

Best for: Developers who prioritize API stability and need flexible global payment options.

10. Veritel

🔗 https://veritel.io

Veritel takes a unique approach — all their numbers are backed by physical SIM cards connected to proprietary hardware. This means you get the reliability of a real carrier number with the convenience of a virtual interface.

Key features:

Physical SIM-backed numbers (not VoIP)
180+ countries, 350+ services
95% deliverability rate with automatic refunds on failure
One-time use per service (number never reassigned for the same service)
Pay-as-you-go, zero subscription
Private messages — never shared after receipt

Watch out for: Higher prices compared to pure VoIP services, but the trade-off is significantly higher acceptance rates.

Best for: Developers who need carrier-grade reliability without wanting to manage physical SIM cards.

Quick Comparison Table

Service	Countries	Services	Starting Price	API	Payment Methods
HeroSMS	180+	700+	~$0.01	✅	Crypto
SMSPool	100+	500+	~$0.01	✅	Crypto, Stripe
5SIM	180+	500+	$0.008	✅	Multiple
SMS-Man	100+	1,000+	$0.05	✅	Multiple
TextVerified	US-focused	80+	~$0.50	✅	Stripe
SMSPVA	60+	300+	$0.05	✅	Multiple
OnlineSIM	90+	500+	~$0.02	✅	Multiple
Blacktel	50+	100+	€0.40/mo	✅	Crypto, Cards
PVAPins	200+	300+	~$0.05	✅	Crypto, Payeer, Skrill
Veritel	180+	350+	~$0.10	✅	Multiple

How to Choose the Right SMS Activate Alternative

Picking the right service depends on your specific use case:

High-volume testing or bulk registrations? Go with HeroSMS — the combination of 500K+ daily numbers, rock-bottom pricing, and API access makes it the most scalable option.

Need non-VoIP numbers for strict platforms? TextVerified (US-focused) or Veritel (global) are your best bets since they use physical SIM-backed numbers.

On a tight budget? 5SIM offers the lowest entry point at $0.008 per number.

Need a persistent number? Blacktel gives you a full virtual phone experience with dedicated numbers, or look at SMSPVA for long-term SIM rentals.

API-first workflow? Most services on this list offer APIs, but SMSPool, HeroSMS, and PVAPins are frequently praised by developers for their API documentation and reliability.

Final Thoughts

The shutdown of SMS-Activate created a real gap in the market, but 2026 has no shortage of capable SMS activate alternatives. The space has actually matured — services now compete on number quality, delivery speed, API stability, and geographic coverage rather than just price.

If you're migrating from SMS-Activate, the transition to any of these platforms should be straightforward. Most follow a similar flow: register, top up, select service and country, get your number, receive the code. The main variables are pricing, number quality, and how well the API plays with your existing automation.

Start with a small test balance on whichever service fits your use case, verify it works for your target platforms, and then scale up. The days of depending on a single provider are over — having two or three SMS activate alternatives in your toolkit is just good operational hygiene.

What SMS verification service are you using after the SMS-Activate shutdown? Drop your experience in the comments — especially if you've tested any of these with tricky platforms like Google or WhatsApp.

My Favorite Websites & Tools for Everyday Development

Mike Davis — Thu, 05 Feb 2026 08:52:39 +0000

Every developer has their secret toolkit — those bookmarked gems that make daily work faster and less frustrating. After years of collecting, testing, and abandoning hundreds of tools, here's my curated list of the ones that actually stuck.

No fluff. Just tools I genuinely use.

📚 Documentation & Learning

DevDocs.io

Multiple API documentations in one fast, searchable, offline-capable interface. I have it open in a pinned tab at all times. Covers everything from JavaScript to Redis to Docker.

Pro tip: Press / to focus search, enable only the docs you need to reduce noise.

MDN Web Docs

The definitive source for HTML, CSS, and JavaScript. If Stack Overflow gives you the answer, MDN explains why it works.

Can I Use

Before using that shiny new CSS property or JS API, check browser support here. Saved me from countless "works on my machine" moments.

web.dev

Google's resource for modern web development best practices. Especially useful for performance optimization and Core Web Vitals.

🎮 Online Sandboxes & Playgrounds

CodeSandbox

Full-fledged development environment in the browser. Perfect for prototyping React/Vue/Angular apps or sharing reproducible bug reports.

StackBlitz

Similar to CodeSandbox but runs Node.js natively in the browser. Boots instantly. I use it for quick Node/Express experiments.

CodePen

The classic. Best for HTML/CSS/JS snippets and front-end experiments. Great community for inspiration too.

Replit

Supports 50+ languages. Need to quickly test a Python script, Go function, or Rust snippet? This is the place.

TypeScript Playground

Official TS playground with great error explanations. Essential for understanding how TypeScript compiles to JavaScript.

Regex101

Write, test, and debug regex with real-time explanations. The "explanation" panel has taught me more about regex than any tutorial.

🤖 AI Assistants & Coding Helpers

Claude

My go-to for complex coding questions, debugging, code reviews, and explaining unfamiliar codebases. Particularly strong at understanding context and nuance.

GitHub Copilot

AI pair programmer right in your IDE. Autocompletes functions, writes tests, and occasionally reads your mind. Worth every penny.

Phind

AI search engine optimized for developers. Gives direct answers with sources instead of making you click through 10 links.

Perplexity

Another AI-powered search. Great for researching technical topics when you need cited sources.

🔌 API Development & Testing

Postman

The industry standard for API testing. Collections, environments, automated tests — it does everything. The free tier is generous.

Insomnia

Lighter alternative to Postman. Cleaner UI, great for REST and GraphQL. I switch between both depending on the project.

Hoppscotch

Open-source, runs entirely in the browser. No installation needed. Perfect for quick API tests.

HTTPie

Beautiful command-line HTTP client. Also has a web version. When curl feels too cryptic, HTTPie is there.

# Instead of curl with all its flags:
http POST api.example.com/users name=John email=john@example.com

Webhook.site

Generates a unique URL that captures all incoming requests. Invaluable for debugging webhooks and OAuth callbacks.

JSON Placeholder

Free fake API for testing and prototyping. When you need dummy data and don't want to spin up a backend.

🎨 Design & CSS Tools

Tailwind CSS Cheat Sheet

All Tailwind classes on one searchable page. Faster than digging through docs.

Coolors

Color palette generator. Press spacebar to generate new palettes. Export to various formats.

Realtime Colors

Visualize your color palette on a real website template. Helps catch bad color combinations before coding.

Google Fonts

Free, fast, and huge library. Filter by properties to find the perfect typeface.

Fontsource

Self-host Google Fonts via npm. Better performance, no external requests, GDPR-friendly.

CSS Grid Generator

Visual grid builder. Draw your layout, copy the CSS.

Flexbox Froggy & Grid Garden

Learn Flexbox and Grid through games. Fun way to solidify fundamentals.

Neumorphism.io

Generate soft UI shadows. Because getting neumorphic shadows right manually is tedious.

Clippy

CSS clip-path generator. Create complex shapes visually.

🛠️ Generators & Utilities

readme.so

Drag-and-drop README generator. Produces clean, professional READMEs in minutes.

gitignore.io

Generate .gitignore files for any tech stack. Just type your languages/frameworks.

Transform Tools

Convert anything to anything: JSON to TypeScript, SVG to React, HTML to JSX, and dozens more.

Mockaroo

Generate realistic test data in CSV, JSON, SQL, and more. Customizable fields and data types.

Lorem Picsum

Random placeholder images. Just use https://picsum.photos/400/300 for a 400x300 image.

Favicon.io

Generate favicons from text, images, or emojis. Outputs all the sizes you need.

Squoosh

Image compression by Google. Compare different formats and quality settings side by side.

SVGOMG

Optimize SVG files. Dramatically reduces file size while keeping quality.

🔍 Performance & Testing

PageSpeed Insights

Google's official performance testing tool. Core Web Vitals, suggestions, and metrics.

Lighthouse

Built into Chrome DevTools, but also available as CLI. Audits performance, accessibility, SEO, and best practices.

WebPageTest

Advanced performance testing from multiple locations and devices. Film strip view shows exactly what users see during load.

BrowserStack

Test on real devices and browsers. Essential when you don't own 50 different phones.

Responsively

Free app that shows your site on multiple screen sizes simultaneously. Huge time-saver for responsive development.

📊 Cheat Sheets & References

OverAPI

Cheat sheets for almost every language. Clean, printable format.

Cheatography

User-contributed cheat sheets on everything from Vim to Docker to Excel.

Devhints

Beautiful, well-organized cheat sheets. My favorite for quick syntax lookups.

QuickRef.me

Another excellent cheat sheet collection with clean design.

Git Explorer

Don't know the right Git command? Describe what you want to do, get the command.

🔐 Security

Have I Been Pwned

Check if your email was in a data breach. Also has an API for password checking.

Security Headers

Scan your site's HTTP security headers. Quick way to spot misconfigurations.

SSL Labs

Deep analysis of your SSL configuration. Grades your setup and suggests improvements.

💡 Bonus: Browser Extensions

Wappalyzer — Identify technologies used on any website
JSON Viewer — Pretty-print JSON in the browser
ColorZilla — Pick colors from any webpage
WhatFont — Identify fonts on any site
Vimium — Navigate the web with Vim keybindings

My Typical Day

To give you an idea of how these fit together:

Morning: Check DevDocs for API reference while coding
Debugging: Test endpoints in Hoppscotch, ask Claude when stuck
Styling: Generate palette in Coolors, reference Tailwind cheat sheet
PR Review: Use Transform Tools to convert JSON schemas
Before deploy: Run Lighthouse audit, compress images with Squoosh

Your Turn

This list reflects my workflow — yours might be completely different. The best toolkit is the one you actually use.

What are your daily essentials? I'm always looking to add new tools to the collection. Drop your favorites in the comments!

Found a new tool here? Give this post a ❤️ and follow for more practical dev content!

Git Commands I Wish I Knew Earlier

Mike Davis — Thu, 05 Feb 2026 08:16:47 +0000

When I started using Git, I knew exactly five commands: clone, add, commit, push, pull. And honestly? That was enough — until my first serious merge conflict, lost changes, and a Friday evening panic attack.

Over the years, I've collected a set of commands that I genuinely wish someone had shown me on day one. Here they are.

🗃️ git stash — Your Temporary Pocket

The situation: You're deep into coding a feature when your teammate asks you to urgently review their PR. Your changes aren't ready to commit, but you need a clean working directory.

The old me: Would create a commit with the message "WIP temp don't push" (spoiler: I pushed it).

The enlightened me:

# Save all your changes to the stash
git stash

# Do your other work...

# Bring your changes back
git stash pop

Stash Pro Tips

# Stash with a descriptive message (you'll thank yourself later)
git stash save "halfway through login refactor"

# View all your stashes
git stash list

# Apply a specific stash without removing it from the list
git stash apply stash@{2}

# Stash only specific files
git stash push -m "navbar changes" src/components/Navbar.jsx

# Stash including untracked files
git stash -u

🔍 git bisect — Find the Bug with Binary Search

The situation: Something broke. The tests were passing a week ago, now they're failing. Somewhere in 80 commits hides the culprit.

The old me: Would manually checkout commits one by one, losing half a day.

The enlightened me:

# Start the bisect session
git bisect start

# Mark the current (broken) commit as bad
git bisect bad

# Mark a known good commit (e.g., from last week)
git bisect good a1b2c3d

# Git will now checkout the middle commit
# Test it, then tell Git:
git bisect good  # if this commit works
# or
git bisect bad   # if this commit is broken

# Repeat until Git finds the exact commit that introduced the bug
# When done:
git bisect reset

Git uses binary search, so even with 1000 commits, you'll find the bug in about 10 steps. Magic.

Fully Automated Bisect

If you have a test script that returns 0 for success and non-zero for failure:

git bisect start HEAD a1b2c3d
git bisect run npm test

Git will find the broken commit completely automatically. Go grab a coffee.

✨ Interactive Rebase — Rewrite History Like a Pro

The situation: Your branch has 15 commits including "fix typo", "fix typo again", "actually fix typo this time", and "forgot a semicolon". You want to merge, but your tech lead will not be pleased.

The enlightened me:

# Rebase the last 5 commits interactively
git rebase -i HEAD~5

This opens an editor with something like:

pick a1b2c3d Add user authentication
pick b2c3d4e Fix typo in auth
pick c3d4e5f Fix typo again
pick d4e5f6g Add logout feature
pick e5f6g7h Forgot semicolon

Now you can:

pick a1b2c3d Add user authentication
squash b2c3d4e Fix typo in auth
squash c3d4e5f Fix typo again
pick d4e5f6g Add logout feature
fixup e5f6g7h Forgot semicolon

squash (s): Merge commit with previous, combine messages
fixup (f): Merge commit with previous, discard this message
reword (r): Keep commit, but edit the message
drop (d): Delete the commit entirely
edit (e): Pause to amend the commit

⚠️ Warning: Never rebase commits that have been pushed to a shared branch. You'll create a parallel universe that your teammates won't appreciate.

🔧 Useful Aliases That Save Keystrokes

Add these to your ~/.gitconfig:

[alias]
    # Shorter status
    s = status -sb

    # Pretty log graph
    lg = log --oneline --graph --decorate --all

    # Undo the last commit but keep changes
    undo = reset --soft HEAD~1

    # Amend without editing message
    oops = commit --amend --no-edit

    # Show what you did today
    today = log --since='midnight' --author='Your Name' --oneline

    # Delete all merged branches
    cleanup = "!git branch --merged | grep -v '\\*\\|main\\|master' | xargs -n 1 git branch -d"

    # Quick commit with message
    cm = commit -m

    # Create and switch to new branch
    cob = checkout -b

Now instead of git status --short --branch you just type git s.

🚀 More Commands Worth Knowing

git commit --amend

Forgot to add a file? Typo in the commit message?

# Add forgotten file to the last commit
git add forgotten-file.js
git commit --amend --no-edit

# Or just fix the message
git commit --amend -m "Better commit message"

git reflog — Your Safety Net

Accidentally deleted a branch? Reset too hard? reflog remembers everything:

git reflog

# You'll see something like:
# a1b2c3d HEAD@{0}: reset: moving to HEAD~3
# b2c3d4e HEAD@{1}: commit: Add feature
# ...

# Recover by:
git checkout b2c3d4e
# or
git reset --hard b2c3d4e

git cherry-pick

Need one specific commit from another branch?

git cherry-pick a1b2c3d

git log with Search

Find who wrote that questionable line:

# Search commit messages
git log --grep="bug fix"

# Search code changes
git log -S "functionName"

# Show commits that touched a specific file
git log --follow -p -- path/to/file.js

git clean

Remove all untracked files (be careful!):

# Dry run first — see what would be deleted
git clean -n

# Actually delete untracked files
git clean -f

# Delete untracked files AND directories
git clean -fd

📋 Quick Reference Cheat Sheet

Command	What It Does
`git stash`	Save changes temporarily
`git stash pop`	Restore stashed changes
`git bisect`	Binary search for bugs
`git rebase -i HEAD~n`	Interactive rebase last n commits
`git commit --amend`	Modify the last commit
`git reflog`	View history of all HEAD changes
`git cherry-pick <hash>`	Copy a specific commit
`git log -S "text"`	Find commits changing specific text
`git clean -fd`	Remove untracked files and dirs

Final Thoughts

Git has a steep learning curve, but mastering these commands transformed my workflow. I went from fearing Git to actually enjoying version control (most of the time).

My advice: pick one command from this list and start using it this week. Once it becomes muscle memory, add another.

What Git commands do you wish you'd learned earlier? Drop them in the comments!

If this helped you, consider following for more practical dev tips. Happy coding! 🚀

5 VS Code Extensions That Actually Speed Up My Workflow

Mike Davis — Wed, 04 Feb 2026 18:39:42 +0000

Let's be honest — there are thousands of VS Code extensions out there, and most "top extensions" lists include the same obvious picks.

Today I want to share 5 extensions that genuinely changed how I code. These aren't just "nice to have" — they save me real time every single day.

1. Error Lens

What it does: Displays errors and warnings inline, right next to your code.
Instead of hovering over red squiggles or checking the Problems panel, you see the error message immediately.

const user = { name: "Alex" };
console.log(user.age); // Error: Property 'age' does not exist on type...

The error appears right there on the same line. No extra clicks.
Why I love it: I catch typos and type errors instantly. It feels like having a second pair of eyes.

🔗 Error Lens on Marketplace

2. Auto Rename Tag

What it does: When you rename an HTML/JSX opening tag, it automatically renames the closing tag.

Before:

<div>Content</div>
<!-- You change "div" to "section"... -->
<!-- Now you have to manually find and change </div> too -->

After (with extension):

<section>Content</section>
<!-- Both tags update simultaneously -->

Why I love it: Sounds small, but in React/Vue components with nested elements, this saves dozens of manual edits per day.

🔗 Auto Rename Tag on Marketplace

3. GitLens

What it does: Shows who changed each line of code, when, and why — right inside the editor.
Hover over any line and see:

The commit message
The author
How long ago it was changed

// You see a weird piece of code and wonder "why is this here?"
// GitLens shows: "Fixed edge case for empty arrays" — John, 3 months ago

Why I love it: Perfect for understanding legacy code or figuring out why something was written a certain way. No need to open GitHub or run git blame manually.

🔗 GitLens on Marketplace

4. Prettier

What it does: Automatically formats your code on save.
Tabs vs spaces? Semicolons or not? Single or double quotes? Prettier handles it all with zero effort.

Before save:

const data={name:"test",value:42,active:true}

After save:

const data = {
  name: "test",
  value: 42,
  active: true,
};

Why I love it: I stopped thinking about formatting entirely. Just write code, hit save, done.
Pro tip: Add a .prettierrc file to your project so the whole team uses the same style:

{
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2
}

🔗 Prettier on Marketplace

5. Todo Tree

What it does: Finds all TODO, FIXME, BUG comments in your codebase and displays them in a sidebar tree.

// TODO: Add error handling here
// FIXME: This breaks on mobile
// BUG: Returns null for empty input

All these comments are collected in one place. Click on any item — jump straight to that line.
Why I love it: I actually remember to fix things now. Before this extension, my TODOs just disappeared into the void.

🔗 Todo Tree on Marketplace

Bonus Tip

Don't install 50 extensions at once. Add them one by one, use each for a week, and keep only what actually helps.
A cluttered VS Code is a slow VS Code.

What extensions do you use daily? Drop them in the comments — I'm always looking for new tools to try!