DEV Community: Simangaliso Vilakazi

I built a Zapier integration for my solo SaaS. Here's every decision I made

Simangaliso Vilakazi — Mon, 06 Apr 2026 11:05:33 +0000

I am a full-stack software engineer in Durban, South Africa. I work full-time and build SaaS products after hours. PayChasers is one of them. It's a payment chasing tool for anyone who's owed money and tired of asking twice.

Today I submitted it to Zapier's partner program. Here's exactly how it went and what I would do differently.

What PayChasers does

PayChasers handles chasing payment reminders for invoices, rent, deposits, failed payments, and personal debts — anything where someone owes you money and you'd rather not send awkward reminders yourself.

You add a chase. You choose how to handle it. Send a follow-up manually when you're ready, or turn on Auto Chase and let PayChasers handle the escalation for you: friendly nudge, due today, overdue, firm. Email or WhatsApp. The tone sharpens as the payment ages. You stay in control of every message. Nothing goes out without your templates, your tone, your timing.

It works. But the product lives in isolation. If someone tracks invoices in Google Sheets, manages deals in HubSpot, or processes payments through Stripe, they have to manually create chases in PayChasers. That's friction. Friction kills adoption.

So I built a Zapier integration.

Why Zapier and not direct integrations

I considered building native integrations. A Stripe webhook listener, a Google Sheets sync, a HubSpot connector. Each one would take days. Each one adds a maintenance surface. Each one serves one app.

Zapier serves 7000+ apps with one integration.

I built one API surface and let Zapier be the bridge. A user who wants "Hubspot deal closes -> create a chase in PayChasers" can build that in 2 minutes without me writing a single line of HubSpot code.

The trade-off is control. I can't fine-tune each experience. But for a solo engineer, the leverage is hard to beat.

What the integration exposes

Triggers (things that happen in PayChasers)

New Chase - fires when a user creates a chase
Chase Overdue - fires when a chase passes its due date
Chase Paid - fires when a chase is marked as paid
Follow-up Sent - fires when an automated follow-up email goes out

Actions (things Zapier can do in PayChasers)

Create Chase - create a new chase with client details, amount, due date, currency, and chase type
Send Follow-up - trigger a follow-up on an existing chase
Mark as Paid - mark a chase as paid

Auth

API key authentication. Users generate a key in Settings, paste it into Zapier. Simple, no OAuth dance. The key is hashed with SHA-256 before storage. I never see the raw key after it's generated.

The API layer

I built a /api/v1/ REST API specifically for this. It's separate from the internal app routes. Endpoints:

GET    /api/v1/me                   — verify auth
GET    /api/v1/chases               — list chases
POST   /api/v1/chases               — create a chase
POST   /api/v1/chases/:id/paid      — mark paid
POST   /api/v1/chases/:id/follow-up — send follow-up
GET    /api/v1/clients              — list clients
GET    /api/v1/triggers/*           — polling triggers for Zapier

The triggers use Zapier's polling model. Zapier hits the trigger endpoint every few minutes, and I return items sorted by most recent. Zapier deduplicates by ID.

I considered webhooks (Zapier's REST Hook model) but polling was simpler to implement and doesn't require me to manage subscription state. For a product at my scale, polling every few minutes is fine and I dont see any issues.

The embed strategy

Zapier offers a "Full Zapier Experience" embed. A JavaScript widget that lets users discover and build "Zaps" directly inside your app. I built the page for it but designed it with two states:

Before approval: An informational page explaining whats coming. no dead UI, no broken embed. Just a clear explanation of what Zapier automation enables and what it will look like.

After approval: Set one environment variable (NEXT_PUBLIC_ZAPIER_FZE_CLIENT_ID), ready to redeploy and the embed loads. Users can browse Zap templates and build automations without leaving PayChasers.

Zero code changes needed when the switch flips. One env var.

Ref-based signup attribution

This is the part I almost skipped and I am glad I didn't.

When someone clicks through from a Zap template to sign up, I wanted to know which template drove them. So the signup page accepts a ?ref= parameter:

/signup?ref=zapier-stripe → "Chase failed Stripe payments automatically."
/signup?ref=zapier-sheets → "Turn your spreadsheet into a payment chasing machine."
/signup?ref=zapier-hubspot → "Close the deal. Chase the payment. Automatically."
/signup?ref=zapier-forms → "From form submission to follow-up in seconds."
/signup?ref=zapier → "Automate your payment follow-ups."

Each ref swaps the hero headline and subtitle on the signup page. The person sees copy that matches their intent.

The ref is also stored on the user record in the database as signupRef. After 30 days of beinfg live I can run:

SELECT signupRef, COUNT(*) FROM "User"
WHERE signupRef IS NOT NULL
GROUP BY signupRef
ORDER BY count DESC;

That tells me which integration is driving signups, which use case resonates, and where to double down in listing copy. Without it, I would know signups are happening but not why.

One column. Massive signal.

The partner review process

Submitting to Zapier's partner program is straightforward but not instant. Here's how it went:

Build the integration on Zapier's developer platform
Submit for review. Their team assigns a reviewer.
Compliance check. The reviewer checked my homepage, terms of service, and privacy policy to confirm the country of operation. He couldn't find it. Fair, it wasn't there.
Fix and respond. I added "South Africa" to my Terms of Service, Privacy Policy, and Contact page within the hour. Updated the Governing Law clause to reference South African law.
Wait for Beta. After passing review, the integration moves to Beta in the Zapier app directory.

The compliance ask caught me off guard but makes sense. They're publishing your app in their directory, they need to know where you operate.

If you're building a Zapier integration, put your country and legal jurisdiction on your site before you submit. Save yourself a round trip.

What I would do differently

Start with the API earlier. The /api/v1/ layer is clean and useful beyond Zapier. It could serve a mobile app, a CLI, or any other client. I should have built it as a first-class citizen from day one instead of bolting it on for Zapier.

Don't overthink trigger architecture. I spent time debating polling vs webhooks. Polling is fine. Ship it. You can add webhooks later if scale demands it.

Add signup attribution from the start. The signupRef field took 10 minutes to add. It should have been there from the first signup form.

Put your legal jurisdiction on your site from day one. Not just for Zapier, for any partnership, integration, or compliance review. It took me an hour to fix. It should have been there from the start.

Current status

PayChasers has paying users across multiple countries. We are early, but the signal is real.

The integration has been submitted and is in review. The embed page is built and waiting. The attribution tracking is live. When the green light comes, it's one env var and a deploy.

If you're an indie hacker thinking about integrations, Zapier is high leverage. One integration surface, thousands of connections. Build the API, submit the integration, track your refs, and let the platform do the distribution.

I am Simangaliso, building PayChasers from South Africa. If you've ever sent a "just following up" email manually, PayChasers was built for you. paychasers.com

A Terminal-Inspired Portfolio of Shipped and Researched Products (2026)

Simangaliso Vilakazi — Fri, 02 Jan 2026 11:47:38 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

I am a full-stack software engineer based in South Africa, focused on building durable software that ships and lasts.
I care about clear system boundaries, low-maintenance architectures, and products that solve real problems without unnecessary complexity. Most of my work lives in production: SaaS tools, automation systems, payment flows, and community platforms.
This portfolio is meant to reflect how I actually work. Pragmatic, intentional, and biased toward execution.

Portfolio

You can also visit it at: https://smngvlkz.com

This portfolio is structured like internal system documentation rather than a traditional marketing site. It highlights:

Live and archived products I have shipped
Clear product intent, status, and scope
Ongoing research and exploratory work
SaaS, automation, payments, and platform work
Open-source and community contributions

AI Integration

Design principle:
AI is used only where it improves inspectability or reduces cognitive load. All core functionality remains deterministic and debuggable without AI.

This portfolio includes an interactive terminal (SYSTEM.QUERY) powered by Google Gemini 3 Flash.

Users can query the entire portfolio data directly:

Structured commands (handled locally for speed):

help - list available commands
list all - show all products and contributions
show activity - show GitHub & GitLab stats, streak, sessions
show [id] [field] - show specific data for any item in the portfolio
explain [id] - show full breakdown for any product or contribution
list fields - show queryable fields

Natural language queries (powered by Gemini) - examples:

"what tech does paychasers use?"
"compare the infrastructure of all products."
"which product uses blockchain?"
"what's the Cape Community Blog built with?"

The system prompt constrains Gemini to portfolio data only, with terminal-style output formatting. Common queries are handled locally without an API call. Complex or natural language queries fall back to Gemini.

This demonstrates practical AI integration: fast where possible, intelligent when needed, without over-engineering.

Live Activity Data (GitHub & GitLab)

SYSTEM.ACTIVITY pulls live data from GitHub and GitLab using authenticated API requests.

A server-side route aggregates commits, repositories, contribution streaks, and session metadata into a unified activity model. This model is used in two places:

Rendered as live system activity stats in the interface, including a 111-day contribution heatmap that visualizes real contributions with interactive tooltips (showing source breakdown: GitHub/GitLab commits, date, and day of week). Only days with actual contributions are inspectable on hover.
Exposed to SYSTEM.QUERY, allowing users to inspect and query the same data via the terminal.

This keeps activity up to date without manual updates and demonstrates real external API integration alongside AI-powered querying, with a single source of truth shared across UI and terminal

How I Built It

Framework: Next.js
Language: Typescript, JavaScript
Styling: Tailwind CSS
AI: Google Gemini 3 Flash
Deployment: Google Cloud Run (fully managed, container-based)

I used AI-assisted development to iterate on structure, copy clarity, and information hierarchy, while keeping the final implementation intentionally simple and deterministic.

The site favors static rendering, fast load times, and a small surface area for long-term maintainability. The terminal feature adds interactivity without compromising the minimal aesthetic.

What I'm Most Proud Of

The restraint in the design. Nothing exists without a reason
Clear labeling of product status (live, inactive, archived)
Showing real shipped work instead of demo projects
AI integration that fits the product's identity (terminal queries, not chatbot fluff)
A portfolio that reflects engineering maturity, not trend-chasing

This is not a highlight reel. It is a snapshot of how I build software today.