DEV Community: Raffy

What If Your Android Phone Was Just Another n8n Node?

Raffy — Tue, 14 Jul 2026 06:24:19 +0000

We've been building automations with n8n for a while now, and one of the things we like about it is how APIs start to feel like building blocks.

Need data from a CRM? Add a node.

Need to update a spreadsheet? Add a node.

Need an AI model somewhere in the workflow? Add a node.

You connect a trigger, add a few steps, move some data around, and suddenly a process that used to require someone clicking through three different systems just happens on its own.

Then we needed to send an SMS.

And for some reason, that one step made the workflow feel more complicated than it should have been.

The Workflow Wasn't Complicated

Imagine a simple appointment workflow.

New Appointment
      ↓
Check Customer Details
      ↓
Prepare Confirmation
      ↓
Send SMS

Nothing particularly exciting.

The business already has an Android phone.

The phone already has a SIM card.

They already use that number to text customers.

But the automation couldn't use it.

The workflow could talk to cloud applications on the other side of the world, but it couldn't tell the Android phone sitting on the desk:

Send this message.

That bothered us more than it probably should have.

Not Every SMS Use Case Needs to Start With a Telecom Platform

There are good SMS providers out there, and they solve a much larger problem.

If you're sending at serious volume, operating across multiple countries, or building something where telecom infrastructure is a core part of the product, using a proper SMS provider makes complete sense.

But that wasn't the problem we kept thinking about.

We were thinking about smaller, more local workflows.

A clinic sending appointment reminders.

A school sending notifications.

A small CRM following up with a customer.

An internal operations tool alerting a staff member.

An n8n workflow that reaches a step where it simply needs to send a text message.

In many of these cases, the business already has a phone.

It already has a SIM.

It may even already have a mobile plan they use for exactly this kind of communication.

The missing piece isn't the ability to send an SMS.

The missing piece is giving the workflow access to that ability.

So We Started Thinking About the Phone Differently

What if the Android phone wasn't something outside the automation?

What if it was just another resource the workflow could use?

Something like this:

CRM
 ↓
n8n
 ↓
Send SMS
 ↓
Android Phone

From the workflow's point of view, we wanted the experience to be boring.

Give it a destination.

Give it a message.

Choose a device or SIM if necessary.

Send.

The messy part of talking to the Android device shouldn't have to live inside every CRM, ERP, or automation we build.

We wanted an API between the workflow and the phone.

That idea eventually became Relayion.

Who We Actually Built Relayion For

Relayion isn't meant to replace every SMS provider.

That's not the goal.

We're building it for developers and automation builders working on the smaller, awkward use cases that don't always fit neatly into a large communications platform.

The person building an internal tool.

The developer automating a local business.

The team connecting an existing CRM to n8n.

The indie developer building a small SaaS.

The self-hoster who already has the hardware and wants to make it useful.

Sometimes the requirement really is this simple:

When my workflow reaches this step, send an SMS using this Android device.

We think that should be easier.

The n8n Node Was an Obvious Next Step

Once we looked at Relayion from that perspective, building an n8n community node started to feel obvious.

We don't want someone building a workflow to think about Relayion's API every time they need to send a message.

Ideally, they add a node.

[ New Appointment ]
          ↓
[ Prepare Message ]
          ↓
[ Relayion: Send SMS ]

Configure the device.

Choose the SIM.

Map the phone number and message from previous nodes.

Run the workflow.

That's the developer experience we're working toward.

The API still matters, of course. Developers should be able to integrate Relayion directly into their own applications.

But n8n is where the idea really clicked for us.

Because Relayion itself is basically a bridge.

On one side, you have APIs and automated workflows.

On the other, you have an Android phone with a physical SIM card.

Relayion just lets the two talk.

Sometimes the Capability Already Exists

We think we have a habit in software development of looking for another cloud service whenever we need a new capability.

And often, that's exactly the right answer.

But sometimes the thing you need is already sitting on a desk.

It just doesn't have an API.

That's the problem we're trying to solve with Relayion.

We're still early, and we're currently working on making the n8n integration easier for automation builders.

If you use n8n and have ever needed to send SMS from a local Android device, we'd genuinely be interested in hearing about your workflow.

What were you trying to automate?

We're curious how many other people have reached the same annoying step in an otherwise perfectly good workflow.

Vibe Coders vs. Traditional Devs: Both Sides Are Right

Raffy — Fri, 03 Jul 2026 12:33:04 +0000

There is a fascinating, quiet tension happening in the software engineering community right now. If you listen closely to late-night developer chats, team syncs, or tech forums, you will notice that our industry has rapidly split into two distinct schools of thought regarding the rise of AI coding tools like Cursor, Claude Code, and Copilot.

On one side, you have the Traditional Developers. They argue that software engineering is a disciplined art form that cannot be replaced by text prompts. To them, unchecked AI coding is a recipe for buggy, unreadable spaghetti code, creating a technical debt nightmare for the future.

On the other side, you have the Vibe Coders. This is a fast-moving generation of builders, both technical and non-technical, who believe in shipping fast, prompting quickly, and adjusting on the fly. They do not see a need to obsess over syntax when the AI can translate their intent into a working application in minutes.

The reality is that both sides are entirely right.

If we stop arguing over who is ruling the current meta and actually look at the core truths each camp holds, we can see exactly where the future of software development is heading.

1. The Traditional Developer is Right: Guardrails Matter

The traditional development camp is fundamentally right about structure. Building a beautifully designed UI that works on a surface level is vastly different from building an enterprise-ready, scalable architecture.

When you prompt an AI to build a feature, its primary objective is to satisfy the literal words in your core prompt. This is the "as long as it works" mentality. Unless you are practicing strict, spec-driven development and explicitly dictating your architectural doctrines, security protocols, and API patterns, the AI will make assumptions for you.

Historically, those assumptions are optimized for speed and not long-term stability. Without deep technical oversight to catch anti-patterns, edge cases, and hidden security flaws, fast-shipped apps can rapidly break the moment they hit enterprise scale. The rigorous discipline, foundational knowledge, and deep intuition of seasoned developers remain irreplaceable safeguards.

2. The Vibe Coder is Right: Velocity Has Changed Forever

At the same time, the vibe coding camp is absolutely right about the shift in economic reality. The tools are here, they are incredibly powerful, and refusing to use them to ship faster is a losing strategy.

There is no shame in letting an AI abstract away the syntax. For non-technical visionaries, AI tools have democratized software creation, turning long-held dreams into working realities without the immediate friction of massive development costs. Even for reading code, an AI can parse a complex legacy repository and explain it instantly.

If this friction feels jarring to veteran engineers, it is worth taking a historical step back. Decades ago, legacy developers writing pure Assembly or COBOL likely looked at the emergence of modern frameworks, SDKs, and high-level languages and thought that our generation had it too easy and that we were not writing real code.

But the industry adapted. We stopped managing manual memory allocation because modern stacks handled it for us, and the world moved forward just fine. Today, the majority of the world does not need to understand the underlying machine code for their applications to run flawlessly. AI coding tools are simply the next logical layer of abstraction.

The Road Ahead: A Two-Stage Evolution

Instead of viewing this as a battle between humans and machines, we need to view it as an opportunity to adapt. The future of software is not about writing code. It is about shifting our roles as the technology matures.

Stage 1: The Shift to Solutions Architect

In the immediate future, within the next few years, raw coding will increasingly become automated. Traditional manual development will likely be reserved for highly specialized, mission-critical sectors like security, aerospace, and the creation of AI infrastructure itself.

For the rest of the commercial world, both traditional developers and non-technical builders must evolve into Solutions Architects.

The combination of a sharp human architect and an exceptional AI coding companion will inevitably produce safer, less buggy apps at a speed we have never seen before. Experienced developers naturally have a massive unfair advantage here because they understand software design patterns. However, anyone can step into this role if they dedicate themselves to learning foundational system design. Once an organization experiences this level of shipping velocity, there is no going back.

Stage 2: The Shift to Visionary CEO

Further down the line, probably ten years out and beyond, AI systems will become so advanced that they will no longer require humans in the loop for day-to-day execution or spec drafting. The AI will seamlessly manage every facet of product development, architecture, optimization, and scaling.

When that happens, the role shifts from Architect to Visionary.

The individuals who thrive will be those with the greatest ideas and a deep understanding of human needs. In this era, the AI will not just write the code. It will analyze your business idea, tell you what works, optimize the strategy, and execute the entire technical pipeline. If Stage 1 required you to be the Architect, Stage 2 requires you to be the CEO of your vision.

"Maybe So... But Not Today"

The underlying theme of this evolution is survival through adaptation. The worst thing any builder can do right now is dig their heels in and pretend the landscape is not shifting.

But as we look at the current state of play, we still drastically need the discipline, rigor, and protective eye of experienced software engineers. AI is a spectacular co-pilot, but humans are still flying the plane.

It brings to mind that fantastic scene in Top Gun Maverick, where a high-ranking admiral looks at Maverick and tells him that his breed of pilots is heading for extinction. The admiral says that the end is inevitable and that his kind is headed for extinction.

Maverick just looks back, smiles, and says: "Maybe so, sir. But not today."

We might be moving toward a radically different future, but right now, the world still needs engineers who know how to build things that last. Let us embrace the tools, master the architecture, and build what is next.

How Losing Everything as an IT Professional Led to Building an Android SaaS With a Greater Sense of Purpose

Raffy — Thu, 25 Jun 2026 01:35:54 +0000

For a long time, I did what every ambitious engineer is told to do. I climbed the corporate ladder. I made it to the height of my career, managed engineering teams, and dealt with the heavy stress that comes with enterprise infrastructure.

But eventually, corporate inertia and office politics catch up with you. After a complex, challenging corporate exit, I found myself at a major crossroads. It was a stressful time that tested my spirit, but it ultimately brought me down to a place of radical humility.

In that space, I realized I wanted to build things with a greater purpose. When everything else felt uncertain, getting back to writing code became my sanctuary. It is where I find my peace. I teamed up with some incredible colleagues, and together, we started building a new suite of software under a shared vision. We wanted to help small businesses get access to enterprise-grade tools without the enterprise price tag.

Our roadmap is to build full SaaS applications for small-and-medium enterprises, especially around autonomous AI customer service. But as we began mapping out the features, we hit a massive roadblock that forced us to build the foundation first.

That foundational project is Relayion.

The Core Problem with Modern Developer SMS

We were looking into how local businesses handle customer communication. Everyone talks about connecting apps to Facebook Messenger or WhatsApp, but for local businesses like a neighborhood medical clinic or an automotive shop, traditional SMS is still the absolute lifeblood. They need it for automated appointment reminders, quick customer inquiries, and sending secure one-time passwords.

The problem is that if a developer wants to build a system that handles autonomous, two-way customer service over SMS, using traditional cloud providers is a trap.

The costs scale instantly because they charge heavy fees for every single outbound and inbound message. On top of that, you face a bureaucratic nightmare of carrier regulations and endless registration forms just to get approved to send a basic automated text.

The ironic part is that businesses are already actively using their physical phones with local SIM cards and unlimited text plans to talk to their clients and run ads. They already own the hardware and pay for the service. We just needed a way to bridge that existing hardware to the web systems that can actually automate, streamline, and scale those processes.

Our Approach to the Architecture

We decided to build an infrastructure that lets any web server, app, or AI agent send and receive texts natively through a physical Android device. We did not want to build an overnight, fly-by-night tool. Our engineering team spent months refining this mechanism to make sure it handles messages with extreme care and reliability.

Our system is engineered for instant responsiveness. The moment your server hits our endpoint, the message routes to the phone safely. We built a robust cloud buffer in front of the hardware. If your phone temporarily loses cellular signal or the network drops out for a minute, our cloud holds onto the messages securely and flushes them to the device the exact millisecond it is stable. You do not get dropped messages or lost data, which is exactly how a reliable engine should work.

On the flip side, when a customer replies to that text, the phone captures the incoming SMS and instantly relays a webhook back to your system or AI model for a seamless, two-way loop.

We wanted to make this incredibly lightweight for developers to deploy. Once our Android application is running on your device, sending a programmatic text from Node.js, Python, or a no-code workflow tool like n8n looks exactly like a standard three-line API curl request.

Building in Public and Moving Forward

Relayion isn't perfect, and as engineers, we know software is an evolving canvas. But our team strives every day to bring it closer to perfection.

This journey has taught me radical humility. I have fully accepted that I am exactly where God wants me to be, and I have surrendered the steering wheel to Him. Continuing down this path, sharing our engineering milestones, and building software that genuinely helps people is where our focus is.

We built Relayion to give indie hackers, small business owners, and developers the kind of affordable, robust infrastructure they usually get priced out of. Whether you are building an AI chatbot, automating a local clinic, or just messing around with a weekend project, we would love for you to try it out.

You can check out our platform and setup guides at relayion.com. Drop a comment below if you have ever tried building an SMS gateway or ran into these carrier pricing walls. Our team would love to swap notes with you.