Forem: Nikola Mitrovic

How I turned an Android phone into an SMS API

Nikola Mitrovic — Sat, 14 Mar 2026 09:03:22 +0000

The story of SimGate (https://simgate.app)

SMS is still one of the most reliable ways to send notifications,
alerts, and verification codes.

But if you've ever looked at services like Twilio, you know the costs
can add up quickly --- especially for small projects, internal tools, or
experiments.

So I started wondering:

What if a regular Android phone could act as an SMS gateway?

Turns out... it can.

Recently I built a small system that turns an Android phone into a
programmable SMS API.

The idea

Every Android phone already has:

a SIM card
an SMS modem
an internet connection

So instead of paying for SMS infrastructure, the phone itself can send
messages.

The missing piece is just connecting that phone to a backend.

The architecture looks like this:

Your App
   │
   ▼
REST API
   │
   ▼
WebSocket connection
   │
   ▼
Android phone
   │
   ▼
Carrier SMS network

Your backend sends a request → the phone receives it → the phone sends
the SMS.

The architecture

The system has three main parts.

1. Backend API

The backend exposes a simple endpoint:

POST /send-sms

Example request:

{
  "to": "+381601234567",
  "message": "Hello from API"
}

The backend does not send SMS directly. Instead it forwards the message
to a connected device over WebSocket.

2. Persistent device connection

When the Android app starts, it opens a WebSocket connection to the
backend.

Example:

socket.emit("connectDevice", {
  deviceId: "abc123"
});

Now the backend knows that this specific phone is online.

Whenever a new SMS request arrives, the backend pushes the message to
that device.

3. Android SMS sender

The Android app receives the message and sends it using the native SMS
manager.

On Android this is surprisingly simple:

SmsManager smsManager = SmsManager.getDefault();
smsManager.sendTextMessage(phoneNumber, null, message, null, null);

That's it.

The phone sends the SMS through the carrier network just like any normal
message.

Why this is interesting

This approach has some interesting advantages.

No SMS provider required

You don't need Twilio, Nexmo, or other gateways.

The SIM card in the phone handles everything.

Extremely cheap

If you already have:

a spare Android phone
a SIM card with SMS included

Then your cost is basically zero.

Useful for internal tools

This setup works well for things like:

server alerts
IoT notifications
internal automation
dev experiments
sending messages in regions where SMS APIs are limited

Challenges I ran into

This was not completely trivial.

Some problems that needed solving:

Persistent connectivity

Phones disconnect from networks frequently.

Keeping a reliable WebSocket connection required retry logic and
heartbeat checks.

Device registration

Each phone needs a unique identity so the backend knows where to route
SMS messages.

I solved this by generating a device ID during registration and pairing
it with the API key.

Background restrictions

Android can aggressively kill background processes.

The app needs to run as a foreground service to stay alive reliably.

Example workflow

Once everything is connected, sending SMS looks like this.

Example request:

curl https://api.example.com/send-sms   -H "Authorization: Bearer API_KEY"   -H "Content-Type: application/json"   -d '{
        "to": "+381601234567",
        "message": "Server is back online"
      }'

The connected phone immediately sends the SMS.

Why I built this

Originally this started as an experiment to see if it was possible to
build a simple SMS gateway using commodity hardware.

After getting it working, I turned it into a small service called
SimGate that lets you connect a phone and send SMS through an API.

The idea is simple:

Phone + SIM → SMS API

If you're curious or want to try it:

https://simgate.app

I'd also love to hear how other people handle SMS in small projects or
internal tooling.

Are you using:

Twilio
self-hosted GSM modems
Android devices
something else entirely?

Automating Supplier Order Emails: Stop Copy-Pasting from Your Inbox

Nikola Mitrovic — Fri, 06 Mar 2026 10:05:46 +0000

The Problem

Most B2B operations still run on email. Your suppliers send order confirmations, shipping notices, and invoices to a shared inbox, and someone on your team manually copies data into your system. It's tedious, error-prone, and doesn't scale.

After building this automation three times across different companies, here's the approach that actually works in production.

Architecture Overview

You need three components:

Email receiver — captures inbound messages (IMAP polling or webhook)
Parser — extracts structured data from email body/attachments
Integrator — pushes parsed data to your database or ERP

The tricky part isn't any single piece—it's handling the chaos of real-world supplier emails. One vendor sends PDFs, another uses plain text with inconsistent formatting, and a third embeds everything in HTML tables.

The Node.js Implementation

Here's a minimal example using imap-simple and some regex parsing. This listens for new emails, extracts order numbers and totals, then logs them:

const imaps = require('imap-simple');
const { simpleParser } = require('mailparser');

const config = {
  imap: {
    user: process.env.EMAIL_USER,
    password: process.env.EMAIL_PASSWORD,
    host: 'imap.gmail.com',
    port: 993,
    tls: true,
    tlsOptions: { rejectUnauthorized: false }
  }
};

async function processOrders() {
  const connection = await imaps.connect(config);
  await connection.openBox('INBOX');

  const searchCriteria = ['UNSEEN', ['FROM', 'orders@supplier.com']];
  const fetchOptions = { bodies: [''], markSeen: true };

  const messages = await connection.search(searchCriteria, fetchOptions);

  for (const item of messages) {
    const all = item.parts.find(part => part.which === '');
    const parsed = await simpleParser(all.body);

    // Extract order details (customize per supplier)
    const orderMatch = parsed.text.match(/Order #(\d+)/);
    const totalMatch = parsed.text.match(/Total: \$([\d,]+\.\d{2})/);

    if (orderMatch && totalMatch) {
      const order = {
        orderNumber: orderMatch[1],
        total: parseFloat(totalMatch[1].replace(',', '')),
        receivedAt: new Date()
      };

      console.log('Parsed order:', order);
      // await saveToDatabase(order);
    }
  }

  connection.end();
}

processOrders().catch(console.error);

What This Doesn't Handle

This snippet works for demos, but production needs:

Multi-vendor parsing logic — each supplier has different formats
PDF extraction — many orders come as attachments
Retry logic — emails sometimes arrive out of order or get corrupted
Schema validation — ensuring extracted data matches your database constraints
Monitoring — you need alerts when parsing fails

Building all of this from scratch takes weeks. You'll write custom parsers for each supplier, handle authentication edge cases, and spend weekends debugging why one vendor's emails suddenly changed format.

The Real Cost

Maintenance is the killer. Suppliers change their email templates without warning. Your regex breaks. Someone has to debug it at 9 PM because orders aren't flowing through.

The automation saves time compared to manual entry, but only if you account for the ongoing maintenance burden. If you're processing fewer than 50 orders per day, honestly, the manual approach might cost less in total engineering time.

Try ParseForce

If you'd rather skip the plumbing entirely, check out ParseForce — it handles inbound email parsing, schema validation, and webhook delivery out of the box. The architecture is solid for teams that want to focus on business logic instead of email infrastructure.

Parsing Incoming Emails into Structured JSON with Node and AI

Nikola Mitrovic — Tue, 03 Mar 2026 10:48:21 +0000

Email is still one of the most common “integration APIs” in business and that's why I made https://www.parseforce.io

Invoices. Shipping notices. Order confirmations. Supplier updates.

And in many cases… email is the only integration point you get.

The problem?

Emails are messy.

Layout changes
Forwarded threads
HTML formatting
Different senders, different structures
Slight wording tweaks that break everything

Yet inside those emails is structured data you actually need.

The Regex Trap

Most teams start with regex or template-based parsing.

It works at first:

const match = emailBody.match(/Total:\s*\$([0-9,\.]+)/);

Then one day:

“Total” becomes “Amount Due”

The currency moves

The supplier updates their template

Someone forwards the email

And your parser breaks.

You’re now maintaining parsing logic instead of building product.

A Different Approach

Instead of matching patterns, define the schema you want:

{
  "invoiceNumber": "string",
  "items": [],
  "total": "number",
  "currency": "string"
}

Then extract structured JSON that conforms to that schema.

Your workflow becomes:

Incoming email
↓
Extract structured data
↓
Validate
↓
Send to webhook

Now your backend only deals with clean JSON.

Making Email Feel Like Webhooks

The goal is simple:

Turn this:

email → chaos

Into this:

email → structured JSON → webhook

So your systems can treat email like any other API input.

A Practical Note

If you go this route:

Always store raw emails

Validate extracted fields

Handle low-confidence cases

Expect edge cases

Email isn’t going away.
But it doesn’t have to be painful.
More details about the tool.

I tried parsing emails with regex. It went exactly how you think.

Nikola Mitrovic — Mon, 02 Mar 2026 15:24:14 +0000

Recently I needed to process incoming emails automatically.

The idea sounded simple:

Email arrives → extract some fields → trigger a webhook

Things like:

order confirmations
invoice emails
shipping notifications
support messages

Nothing complicated.

Or so I thought.

Attempt #1 — Regex

Like most developers, I started with regex.

const price = email.match(/Total:\s\$(\d+)/)

For the first email it worked perfectly.

Then the next email came in and said:

Amount paid: $29

Then another one said:

Total price: USD 29

Then an HTML email arrived with nested tables, inline styles, and formatting from what looked like 2004 Outlook templates.

At this point my regex slowly evolved into something like this:

/(Total|Amount|Price).*?(\$|USD)?\s?(\d+(\.\d+)?)/

Which is usually the moment you realize the approach is already doomed.

Attempt #2 — Parsing the HTML

Okay fine.

Let's parse the HTML instead.

That led to code like this:

const dom = new JSDOM(emailHtml)

Which sometimes worked.

Except email HTML is a special kind of chaos.

You get:

tables inside tables
inline styles everywhere
different layouts for every sender

And suddenly you're maintaining custom parsers for every email format.

The real problem

Emails aren't structured data.

They're written for humans, not machines.

And every sender formats them differently.

Trying to enforce rigid parsing rules becomes fragile very quickly.

The obvious solution (in hindsight)

Instead of trying to force strict parsing rules…

Why not let AI interpret the email and extract the fields you want?

Example email:

Subject: Order confirmation
Customer: John Smith
Product: T-shirt
Total: $39

Structured output:

{
  "customer": "John Smith",
  "product": "T-shirt",
  "total": 39
}

Now your backend receives clean structured data instead of raw email text.

So I built a small tool

Mostly because I kept running into this problem again and again.

It's called ParseForce.

The flow is simple:

Incoming email → AI parsing → structured JSON → webhook

You:

Get a unique inbox
Send emails to it
Define the schema you want
Receive structured JSON in your webhook

That's it.

Some things it works well for

So far I've been using it for:

parsing order confirmation emails
extracting invoice data
processing lead emails
triggering automation workflows

Basically anything where an email contains data you want your system to understand.

If you're curious

You can check it out here:

👉 https://parseforce.io

I'm also curious how others deal with this problem.

Are you using regex, templates, or something else entirely?

node #webdev #saas #automation #ai

How I’m Building an AI Try-On Tool for Clothing Brands (Behind the Scenes)

Nikola Mitrovic — Wed, 10 Dec 2025 20:03:32 +0000

Over the past few months, I’ve been working closely with a few small clothing brands, and one problem kept coming up in every conversation:

“We can get new inventory fast… but product photos slow everything down.”

That fascinated me. Most boutiques spend:
days coordinating photoshoots
money on models + photographers
time editing everything
and meanwhile, new items sit in inventory waiting for photos
One boutique owner told me:
“I can add products to Shopify the same day I get them, but photos take 2–3 weeks. I lose sales every time.”
That sentence is basically what kicked off this whole project.

🧪 Early experiments
I started by playing with background removal tools, virtual studios, early AI generation models, pose-transfer models
Results were… okay-ish. Cool tech, but nothing you’d confidently publish on a real store.

What I really wanted was something like:
Upload garment → get realistic model photo → done
No photoshoot, no scheduling, no waiting.

⚙️ The tech stack I’m using
Right now the project is built with:
Next.js (frontend)
Supabase (auth + storage)
Fal.ai (AI inference endpoints)
Vercel (hosting)

The flow looks like this: User uploads a garment image -> It runs through preprocessing (crop, contour detection, smoothing) -> Sent to an AI model for realistic try-on -> Post-processing improves lighting + consistency -> delivered as a final product photo

Still improving it — realism is the hardest part but now it's more realistic than others that I played with.

🎯 The goal
I’m trying to answer one simple question:
“Can small clothing brands get store-ready model photos without photoshoots?”
I’m not sure yet, but early tests have been promising enough to keep building.
Some brands loved it:
“This saves me days.”
Some weren’t ready:
“I still prefer real models.”
Understanding that gap is part of this whole journey.

🚀 Launching soon on Product Hunt
I’m planning to launch the project on Product Hunt soon (next week).
If you like AI + e-commerce + build-in-public stuff, I’ll share the link when it goes live.
Would love any thoughts, feedback, or questions — especially from developers working with:
generative models
computer vision
e-commerce automation
apparel tech
Happy to nerd out on the technical side if anyone’s interested.

https://www.fitsnapai.app

Results:

Interested in SMS over API using your own SIM card?

Nikola Mitrovic — Sat, 13 Sep 2025 15:06:32 +0000

How I Send SMS From My React App Using My Own Phone and SIM Card

Nikola Mitrovic ・ Sep 13 '25

#react #webdev #sms #api

How I Send SMS From My React App Using My Own Phone and SIM Card

Nikola Mitrovic — Sat, 13 Sep 2025 13:07:48 +0000

Most tutorials on “sending SMS from your app” point you to services like Twilio, where you pay per message. That’s fine for small projects, but once you start sending a lot of texts, those charges add up quickly.

I wanted something different: a way to send SMS without paying a third-party provider — just using my own Android phone and SIM card. That’s why I built SimGate.

In this post I’ll show you how I wired up my phone to send an SMS directly from a simple React app with just one API call.

The idea
Install an app on your Android phone.
The app connects to SimGate and exposes an API endpoint.
Your frontend or backend makes a POST request with the phone number + message.
Your phone’s SIM card sends the SMS.
No middleman. No per-SMS fee. Just your device and your mobile plan.
Setting up the phone
Install the SimGate Android app.
Log in and register the device.
The app generates an API key you’ll use in your code.
That’s it — your phone is now ready to act as a mini SMS gateway.

3.Sending an SMS:

Here’s the simplest possible curl example:

curl -X POST https://api.simgate.app/v1/sms/send \
  -H "Content-Type: application/json" \
  -H "x-api-key: <YOUR_API_KEY>" \
  -d '{
    "deviceId": "<YOUR_DEVICE_ID>",
    "to": "+15551234567",
    "message": "SMS from curl"
  }'

Sending it from react is quite simple:

async function sendSms() {
  const res = await fetch("https://api.simgate.app/v1/sms/send", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-api-key": "<YOUR_API_KEY>",
    },
    body: JSON.stringify({
      deviceId: "<YOUR_DEVICE_ID>",
      to: "+15551234567",
      message: "Hello from my React app",
    }),
  });

  const data = await res.json();
  console.log("SMS response:", data);
}

As long as your phone has connection SMS is shipped!

https://www.simgate.app

Why I’m building SimGate: An SMS API without per-message fees

Nikola Mitrovic — Mon, 28 Jul 2025 20:46:36 +0000

I’m a full-stack developer who’s always looking for simple, affordable tools, especially when building for side projects or indie SaaS ideas.

Recently, I ran into a familiar problem:
Sending SMS through APIs like Twilio gets expensive fast.
Even basic features like 2FA or delivery alerts can become unsustainable when you're paying per message, especially on low-margin or small-scale projects.

That’s when I decided to build SimGate — a lightweight developer tool that lets you send SMS through your own Android phone and SIM card, using a clean API, without per-message fees.

Who is SimGate for?

Indie devs building internal tools or MVPs
Solo SaaS founders with <1k users
Local delivery apps, clinics, or automations that need recurring SMS
IoT/sensor projects that send alerts
Anyone who’s tired of “$0.something per SMS” adding up over time

How does it work?
SimGate connects to your phone via a mobile gateway app. Once paired, you can:

Send SMS using a secure API
Avoid cloud provider markups
Pay a flat monthly subscription instead of per message (free plan will be available as well)

This way, your phone becomes your own private SMS gateway.
I’m keeping the first version lean — just enough to get real use cases working.

Want to try it?
I’ve opened up a waitlist to gather early interest and invite a few testers as soon as the MVP is live.

If this solves a problem for you — or just sounds interesting — you can join here:
👉 https://www.simgate.app

Thanks for reading — and if you’ve ever struggled with SMS pricing or built your own DIY solution, I’d love to hear your story in the comments!

Nik
dev@simgate.app