cloudonaut Monthly - September 2026: 42% growth after dropping our entry-level plan

It’s embarrassing, but we made a classic mistake when designing the pricing model for our virus and malware scan API. The entry-level price was far too low. Find out how a simple trick led to 42% month-on-month growth, a lower churn rate and fewer support tickets. Additionally, find out how we replaced our newsletter provider, Kit, with a bespoke solution comprising SES, Lambda, Aurora DSQL and Step Functions. And if that’s not enough, we’ll also be sharing our struggles with tax compliance on the AWS Marketplace, as well as our thoughts on Aurora DSQL and a shift in the SaaS market.

We are Michael and Andreas, two brothers who run widdix, the software company behind bucketAV, attachmentAV, HyperEnv and marbot. For more than ten years, we have been writing about how to build on AWS. cloudonaut Monthly gives you insights into our day-to-day work at widdix. We share our insights into challenges and wins, from both a technical and a business perspective.

42% month-over-month growth after deprecating our smallest plan

It’s difficult to get the price right. And we’ve made a mistake. Again.

Here is the pricing model for our Virus and Malware Scan API offering. Can you spot the issue?

You’re absolutely right. A starting price of €9/month for a B2B solution is completely out of range.

Although we were quite happy with the number of sign-ups, revenue was rising slowly. The only things that increased were the number of support enquiries and the churn rate.

Therefore, we started a simple experiment at the end of July: remove the Small plan from our website. Also, we added two larger plans, XL and XXL, to make it pretty clear that our solution is solid and ready to handle huge workloads.

What happened? We no longer see sign-ups from prosumers, a.k.a. developers working on side projects. Instead, the only customers signing up are B2B clients, for whom protecting their business processes against viruses and malware is well worth €49 a month.

September has been a blast. Revenue in September grew by 42% compared to August. Even more important, the churn rate is down to 4.9% and still falling. Also, the number of support enquiries has decreased dramatically.

What was your biggest mistake when creating a pricing model? Or do you think our pricing model still isn’t quite right?

LLMs enable custom software solutions, example #1: Newsletter and CRM

Staying in touch with the cloudonaut crowd as well as our customers is important to us. So, newsletters are important communication channels. For years, we have been using Kit – formerly known as ConvertKit – to manage lists and send emails. Over time, we’ve increasingly realised that Kit doesn’t actually solve the problems we’re facing. We also came to the conclusion that, in our case, the service isn’t worth the money.

That is why we have always wanted to build a solution based on AWS services – a solution tailored precisely to our needs. However, we have always shied away from making the investment. But the situation has changed completely with LLMs in general and Claude Code in particular. Suddenly, it seemed entirely feasible to put together a few AWS services using a modular approach.

So that is what we did. We replaced Kit with our own serverless newsletter and CRM solution, built entirely from AWS building blocks.

• SES delivers the emails and reports bounces and complaints.
• Aurora DSQL stores the newsletter lists and contacts.
• API Gateway and Lambda serve the sign-up, confirmation and unsubscribe endpoints.
• Step Functions run our onboarding sequences, which are nothing more than a chain of tasks and waits.
• CloudFront and S3 distribute images, and the entire configuration lives in Git.

There is no web UI at all. We manage subscribers and send newsletters with a CLI from our terminal, which fits the way we work far better than clicking through a dashboard.

Kit charged us 590 USD per year. Our solution costs less than 1 USD per month, because every service we use is pay-per-use with no baseline costs. Building it took me 40 hours, plus roughly 25 USD worth of our Claude subscription.

I have written up the whole story in a separate blog post.

What sort of bespoke solutions have you developed for your business that wouldn’t have been possible without an LLM? Let me know. I’m collecting examples.

Tax compliance for AWS Marketplace sellers from the EU is hard

The majority of our revenue is made through the AWS Marketplace. This enables us to reach customers all over the world. The AWS Marketplace makes delivery and billing much easier for us. But there is one issue that continues to cause us headaches: tax compliance.

We run a company based in Germany. Consequently, we are subject to German and European tax law, which – to put it diplomatically – is not one of the AWS Marketplace’s strengths.

Challenge #1: when we sell to customers within the EU via the AWS Marketplace, AWS charges us VAT on the listing fee. We can deduct the listing fee we have paid from our VAT. To do this, we need to process the listing fee invoices from AWS. It sounds simple, but unfortunately the AWS Marketplace doesn’t issue a single monthly consolidated invoice; instead, it issues one invoice per transaction. For us, that amounts to hundreds of listing fee invoices. Far too many invoices to enter manually. We’ve built an automated system that scans all the PDFs and extracts the VAT shown on them. The data is reconciled with the billing event data feed, one of the data feeds that AWS Marketplace provides to sellers. A CSV file is then generated for accounting.

Challenge #2: when we sell to German customers, the AWS Marketplace does charge the customer VAT, but we are required to pay this VAT to the tax authorities. We must therefore issue what are known as ‘on-deemed supply invoices’ and send them to the AWS Marketplace. Only then will we receive from the AWS Marketplace the VAT that was previously charged to the customer. Although only two invoices need to be issued per month, these must itemise all transactions from customers in Germany. Our automation system retrieves data from the tax item data feed and the billing event data feed and uses this to generate the invoices in PDF format.

Challenge #3: when we sell to customers within the EU outside Germany, the reverse charge mechanism applies. AWS shows the VAT on the invoice. We do not have to pay the VAT, but we do have to submit a monthly return for each country in the EU. Given the number of countries and transactions involved, this is yet another task that we have had to automate. Here, too, our automation pulls the transactions from the tax item data feed and generates one invoice per jurisdiction.

We spent quite some time sorting things out together with the experts from the AWS Marketplace and our tax consultant.

Are you interested in the details of how European companies can achieve and automate tax compliance on the AWS Marketplace? If 10 people express an interest, I’ll write a blog post. I promise!

Aurora DSQL might become our go-to database service on AWS

AWS announced Aurora DSQL during re:Invent in December 2024. Until now, we had never used the “serverless distributed SQL database” in a real-world project. When building our own newsletter and CRM solution, we decided to go with Aurora DSQL to get some experience with the database system.

Here is what we’ve learned about DSQL so far:

• DSQL is a mixture of DynamoDB and RDS
• DSQL is charged by a pay-per-use pricing model similar to other serverless services like DynamoDB
• DSQL is PostgreSQL-compatible, which simplifies database access (tooling, query language, …)
• DSQL supports single-region or multi-region deployments
• DSQL is a distributed database providing ACID (Atomicity, Consistency, Isolation and Durability) guarantees for transactions
• DSQL uses optimistic concurrency control (OCC) instead of traditional locking
• DSQL is pay-per-use, which is typically a good fit for low-usage workloads

Over the course of 2026, Aurora DSQL introduced sequences and identity columns as well as foreign key constraints. In theory, that should even allow us to migrate from RDS for PostgreSQL to Aurora DSQL in some scenarios. We will give that a try soon.

A bold prediction: Aurora DSQL might replace DynamoDB as our go-to database option on AWS for new projects.

Are you using Aurora DSQL already? Do you think Aurora DSQL can replace DynamoDB as a serverless database? Drop me a line – I’d love to hear what your thoughts are.

Change in the SaaS market? Do European buyers prefer European suppliers?

We have noticed an increase in the following types of enquiries in the attachmentAV inbox:

1. Is data processed within the EU and never transferred to the US?
2. Is your company based in the EU and does personnel outside the EU have access to your systems?
3. How do you ensure GDPR compliance?
4. Do you offer a DPA (Data Processing Agreement)?

This made us wonder, is this a shift in the SaaS market? Are European buyers increasingly looking for suppliers from Europe? Therefore, we took a closer look at the market landscape for virus and malware scan APIs, focusing on this aspect. Competitors from the US are indeed reporting a decline in new customers from the EU. ¹

All this leaves us wondering whether this trend will also affect our choice of cloud provider. Will our customers demand in the future that we source our infrastructure from a European cloud provider? Will customers be happy with data processing in the AWS European Sovereign Cloud or do we need to look for an European cloud provider? It seems we should find answers to this questions and be prepared for this eventuality.

What is your view of the SaaS market? Does the provider’s place of business become a decisive factor in the purchasing decision?

What’s next in October

Here is what we are up to in October.

#1, we are working on improving our contractual documents, such as the Terms of Service, Privacy Policy and DPA for attachmentAV. This involves legal issues such as liability risks, but also aims to speed up the sales process. Working with a specialist lawyer for SaaS is very exciting for us.

#2, we want to overcome a major hurdle to the further development of our virus and malware scan API: the Amazon API Gateway. The 60-second request timeout limit and the 10 MB request size are very restrictive for our use case. Furthermore, the usage plans do not allow us to offer flexible pricing models. We therefore plan to replace the API Gateway with our own solution.

#3, we are reactivating the cloudonaut blog, newsletter and podcast. The first step has been taken. Please send us your feedback – it helps us improve and stay motivated!