Swifteq Apps

At Swifteq, we build apps for Zendesk that help customer support teams do more with less.

We’re an independent SaaS company doing over $40K MRR, built entirely inside the Zendesk ecosystem. Our apps are small, focused tools that fill specific gaps and make support operations smoother.

And like many developers who build on top of large platforms, I’ve learned a valuable lesson the hard way: the same platform that enables your business can one day compete with it.

That’s the nature of platform risk.

If you build on Shopify, Salesforce, Atlassian, Zendesk, or Intercom, this risk lives in the background. The platform is your distribution channel, your ecosystem, your playground, and sometimes, your biggest competitor.

It’s not personal. It’s just how ecosystems evolve.

The Inevitable Overlap

When you build an app that solves a real, painful problem for users, you’re often filling a gap that the platform hasn’t prioritized yet.

That’s your opportunity window.

At Swifteq, one of our apps fills exactly that kind of gap. Our Help Center Translate app helps Zendesk customers automatically translate help center articles into multiple languages. It’s a simple, effective way to make self-service content accessible across regions.

We built it because customers told us it was painful to handle translations manually. Zendesk provided the framework, but the process still required too much effort. So we created a plug-and-play solution that automated it.

The product gained traction quickly because it solved a clear, concrete problem.

Then, some time later, Zendesk introduced AI-powered translations as part of a broader product offering. Suddenly, there was overlap between our solution and the platform’s own.

And that moment, when your product’s differentiation starts to blur with the platform’s roadmap, is when every platform developer feels the same mix of emotions: pride, validation, anxiety, and uncertainty.

Because in a sense, you’ve built something so useful that the platform decided it should exist natively.

That’s validation.

But it also changes the playing field.

Understanding Platform Risk

Platform risk isn’t just the fear of being replaced. It’s the broader dependency on an environment you don’t control.

The platform owns the APIs.

The platform owns the distribution.

The platform controls what gets promoted or deprecated.

And as a technology partner, your business operates at their discretion.

That doesn’t mean you shouldn’t build on a platform, it means you should do it with eyes open.

Building within an ecosystem is still one of the fastest ways to get distribution, validation, and access to paying customers. It lowers barriers to entry, gives you access to shared infrastructure, and lets you plug into an established audience.

But it also comes with tradeoffs.

The platform can introduce features that overlap with your app. It can change APIs, pricing models, or policies. It can limit your visibility or restrict integrations.

And when that happens, the question becomes: what can you do about it?

Strategies to Manage Platform Risk

Over time, I’ve come to see platform risk as something you don’t avoid, but manage.

Here are the strategies that have helped me think through this challenge more clearly.

1. Go Multi-Platform

If all your products live in one ecosystem, your business is tied to the platform’s roadmap. Expanding to other ecosystems, even just one or two more, helps you diversify that dependency.

It’s harder technically. Each API is different. Documentation varies. Integrations behave differently.

But building for multiple platforms reduces the chance that a single change can impact your entire business. It also opens new markets and creates cross-platform learnings that make your apps more resilient overall.

2. Go Deep

When a platform adds a native version of a feature you offer, it’s tempting to think your product is finished. But in many cases, that’s not true.

Platforms usually build broad, generic implementations. You can still win by going deep - by offering a version that is more customizable, more advanced, or better suited to a specific use case.

If the platform builds 1x functionality, you can build the 10x version. Focus on quality, usability, and the edge cases that the platform doesn’t handle well.

Depth beats breadth, especially for independent developers.

3. Go Niche

Another powerful strategy is to specialize. Platforms serve the masses. You can serve the niches.

Maybe the platform’s version of a feature works well for large enterprises, but not for small startups. Or maybe it’s designed for general support workflows, not for SaaS, e-commerce, or fintech.

There’s almost always a segment that the default solution doesn’t fit perfectly. That’s where your opportunity lies.

Find that customer group, understand their specific needs, and build for them.

4. Build Your Own Go-To-Market

Relying entirely on the platform for growth is risky. If you depend on the platform’s sales team or marketplace to drive traffic, any change in their priorities can directly affect your business.

So, invest in your own marketing and growth channels. Build a brand that customers recognize independently of the platform.

SEO, content, LinkedIn, partnerships, direct outreach - they all compound over time. The goal is to create pull from customers who find you directly, not only through the platform’s directory.

The more you control your acquisition channels, the less vulnerable you are.

Seeing the Ecosystem as Dynamic

It’s easy to view platform competition as a static threat. Once overlap happens, it feels final.

But platforms evolve. Ecosystems shift. APIs open up, new technologies emerge, and new workflows appear.

What feels like a closed door today might open a new one tomorrow.

Sometimes the same feature that overlaps with your product also creates new integration points or unmet needs. For example, a platform might launch a feature that solves 80 percent of the problem, but introduces new complexities that specialized apps can address.

If you look at the system dynamically, as something constantly changing, new opportunities start to appear again.

That’s the mindset that helps me stay balanced when things feel uncertain.

Accepting the Tradeoffs

Building on top of a large platform is always a tradeoff between speed and control.

You get speed - access to an audience, APIs, a trusted brand, and lower technical barriers.

But you give up some control - over your future, your roadmap, and your independence.

The key is not to avoid those tradeoffs, but to understand them and plan around them.

At Swifteq, we still love building for Zendesk. It’s developer-friendly, powerful, and deeply integrated into how support teams operate. The community is strong, the documentation solid, and the opportunities are real.

But we’ve also learned to think more strategically about where we fit.

We’re diversifying.

We’re going deeper into certain workflows.

We’re exploring adjacent ecosystems.

And we’re building our own marketing engine.

Because platform partnerships are powerful, but they’re not permanent.

Ecosystems change.

Platforms evolve.

And the only way to thrive inside them is to evolve too.

Final Thoughts

Platform risk is not the enemy, it’s the cost of opportunity.

If you build on a platform, accept that things will change. The question isn’t whether overlap will happen, but how you’ll respond when it does.

Focus on what doesn’t change: your ability to serve customers, adapt fast, and keep solving meaningful problems.

If you keep doing that, there will always be space for you in any ecosystem, no matter how much it evolves.

Last month, my SaaS business crossed €40,000 in monthly recurring revenue. That is almost double what I was making in the same period last year.

For context, I run Swifteq, a small software company focused on building apps for customer support teams that use Zendesk. Our apps extend Zendesk with features like advanced search, help center management, translation, and automation. Some are free, others are paid, and they are all designed to help support teams work faster and deliver better service.

I bootstrapped the company, and today our apps are used by hundreds of teams around the world, from startups to large enterprises.

This post is about sharing what I have learned along the way, the mistakes, the tradeoffs, and the things I wish I had done sooner. Hopefully some of these lessons help you if you are building or thinking about building your own SaaS product.

1. Marketing is always fighting with product

I am a developer at heart. Writing code, fixing bugs, reviewing PRs, that is where I feel comfortable. Even now, with a full-time developer and part-time help, I find myself pulled back into technical work instead of spending the time I know I should on marketing and sales.

It is rarely about building big features anymore. The time sink is often in smaller but constant tasks: troubleshooting technical issues when customers email me, reviewing code from my team, testing new features, or recording walkthroughs for developers so they understand what needs to be refined. I know these are important, but the problem is that they eat away at the hours I should be spending finding new customers or optimizing existing marketing channels.

I have realized it is not just about delegation, it is about discipline. Customers are usually patient when issues arise. I need to train myself to step back, trust the team, and resist the urge to jump into every technical ticket. Otherwise, the urgent will always crowd out the important.

2. Free products open doors

One of the smartest decisions I made early on was to create free apps. I have three free Zendesk apps that are installed and actively used by thousands of customer support folks. These apps do not bring in direct revenue, but they have been one of my most effective marketing channels.

Why? Because they put me in front of teams in a way that feels helpful, not pushy. A support team installs a free app, they use it daily, and they build familiarity with my brand. Later, when they hit a limitation Zendesk does not solve and see one of my paid apps, I am already a known quantity. Trust is established before I ever ask for money.

For other founders: if you can build a genuinely useful free product, it can become one of your best distribution levers.

3. SEO is harder than it looks

I have put real time and money into SEO over the past year. Keyword research, optimized pages, blog posts, consultants, the works. And yet, the return so far has been underwhelming.

Part of it is the shifting landscape: Google algorithm updates, the flood of AI-generated content, and the challenge of breaking through in a crowded space. Part of it is technical. My site has been on Wix, and the Core Web Vitals are poor. I have good reason to believe that this has been holding me back, so I am in the process of migrating to WordPress for better speed and performance.

The takeaway: SEO is a long, slow game. Do not expect quick wins, and do not pour your whole strategy into it until you have proof it is moving the needle.

4. Partners are underrated

Another growth driver that does not get enough attention is partnerships. In my case, it is not about formal agreements or affiliate deals. It is about people in the Zendesk ecosystem: customer success managers, solution consultants, and implementation partners.

When a customer asks a Zendesk employee about a problem that Zendesk does not solve, it is in their best interest to suggest a solution that does. If they know my apps fill that gap, they recommend them. The same is true with partners and consultants who help companies implement Zendesk. It is not complicated, it is just about making their jobs easier.

If you are building on an existing platform or ecosystem, invest in those relationships. Educate people about what your product can do. Being top of mind when a customer problem comes up is incredibly powerful.

5. Price increases are scary but worth it

For a long time, I charged legacy customers far less than new ones. When I first launched one of my main apps, Help Center Manager, I priced it at around €30 per month. Over time, as the app matured and usage grew, I raised prices for new customers to €59 and eventually higher. But I left early adopters on the old plans.

That meant I had dozens of heavy users paying a fraction of the value they were getting. It also meant that growth was harder to sustain, because I did not have the margin to reinvest in support, security, or new features.

So in May, I rolled out a price increase for all existing monthly customers. I gave them plenty of notice, a cadence of three emails over two months, so there would not be surprises.

The reaction was mixed. My churn spiked in July and August. Some customers who had been with me for years left, saying they did not use the app enough to justify the new price. That part was painful.

But when the increases took effect in August, the impact was huge. My MRR jumped by more than €3,000. Suddenly I had budget to invest in SOC 2 compliance, better support, and more product improvements. The app felt healthier, the business felt stronger, and I was more motivated to keep improving it.

Lesson: if your prices do not reflect the value you deliver, you are holding yourself back. Raising prices will cause churn. It will sting. But if you have built something people rely on, the net effect is growth.

6. Attribution is messy and maybe overrated

One thing I have not done well is marketing attribution. I do not have a system that tells me exactly where customers came from. Was it the blog? The free app? A partner referral? An ad?

In reality, I do not think customers ever come from just one place. When I make a buying decision myself, it is rarely linear. I might see a talk at a conference, read a post months later, try out a free tool, get a recommendation from a colleague, and only then decide to buy. That was exactly my experience when I recently chose between two compliance automation vendors for SOC 2. I could not have pointed to a single channel that converted me, it was a mix of touchpoints over years.

That is why I am not convinced perfect attribution is worth chasing. It is messy by nature. Instead, I focus on making sure my brand shows up across multiple touchpoints: useful blog posts, free apps, recommendations from Zendesk employees, conference presence when possible. Customers need familiarity and trust before they buy.

7. Platforms give and take

Building on a platform like Zendesk has clear advantages. You get distribution through the marketplace, visibility when customers search for solutions, and the chance to partner with Zendesk employees and consultants. It is like having a built-in channel that puts you in front of people already in buying mode.

But it also comes with risk. If the platform itself struggles, your business struggles. If your relationship with the platform changes, you are exposed. And if the platform decides to build a feature that overlaps with yours, you might lose ground.

I have seen this firsthand. A couple of years ago, I launched a translation app that became popular. More recently, Zendesk released a competing translation feature as part of their AI offering. So far, I have not lost customers to it, but it is a reminder that platform risk is real. You are always somewhat at the mercy of the ecosystem you build on.

Final thought

Crossing €40k MRR, nearly double what I had one year ago, was not the result of one magic channel or a single growth hack. It was the result of compounding small bets: building free apps, nurturing partnerships, raising prices, experimenting with SEO, and making incremental improvements to distribution.

The hardest part now is not technical. It is focus. Spending less time inside the codebase, and more time working on the business itself.

If you are building your own SaaS, I hope some of these reflections help you. The journey is not linear. It is messy, uncomfortable, and full of tradeoffs. But with each decision, you build momentum, and that momentum is what gets you to milestones like this.