Mantle (heymantle.com) is a SaaS product that sits on top of Shopify's App Billing for managing your app's payments and general sales/marketing flow. It's something I've eyeballed off and on between when I was working on Shoplift and our own platform Raptify. It helps manage all of your Shopify payments, your contacts, set up tiers and discounts and usage tracking and all that good stuff, sounds great right? This all takes significant time to set up…

So… Why Didn't We Use It?

Initially we shot it down because of requirements (and we ended up building out before Mantle was even a thing), but with Raptify we were much more aligned: we needed stronger usage-based billing, we wanted to pull all feature sets from billing information, and I had zero sales-pipeline requirements beyond "put money in my bank account". Wonderful, the gaps are not a problem, and the benefits are great… or so I thought.

So we heavily developed with Mantle in mind, wiring up to their tooling, manually loading our plan data, testing, validating. Things were going sort of well minus one major roadblock.

I had no good way to keep our 6 environments synced plan wise (staging + hotfix + production + 3 engineers having their own), this basically meant we were chasing a lot of bugs that boiled down to poor plan configuration in Mantle. Surely we have a way to keep this synced in Mantle right?

Nope, well – what about their API? Nope, couldn't do what we needed.

This missing functionality was going to be a deal-breaker for us, we've already spent a significant amount of QA time chasing bugs that were configuration mis-matches, doing it manually was a huge time sink and would be error prone…

When AI Focus Kills Your Product

So I asked – "How can we keep these in sync? Or have any sort of copy ability? Is this on the roadmap?"

No we don't support that, but maybe you can use our MCP to do that?

What? That had been their response to a lot of people lately, I had noticed there'd been a significant dip in focus on maturing the platform and going all-in on messing with their MCP a lot (at least from my perspective), most of their updates seemed about it, a lot of answers were "just use the MCP" without clarity on if the MCP provided the additional exposure to actually do the things we need, consistently and reliably enough and without additional overhead coaxing the LLM to do what we need…

Should we have just used the MCP? It's a deterministic flow we need – so I'm iffy on that one at best, and the first thing we're seeing get knee-capped in the world of AI is automated flows. Human-in-the-loop at least is probably going to be the last that gets priced to the moon.

Want Me To Use AI That Much? We'll Just Use It To Replace Your Platform

Ultimately, even with Claude, their platform would have been worth the money… if it didn't incur additional overhead to do what we needed.

I'm extremely familiar with many payment platforms, we even built our own back at my OrthoBanc days with Zech and interfaced directly with banks. Stripe being one of my favorite due to a really polished developer experience and a pretty good business ops experience, is an easy choice. I'm familiar with the pitfalls of Shopify's billing system (at least a lot of them), so I draft up a plan and get to work with Claude.

It's maybe a weeks worth of work if even that, and we have exactly what I want: Raptify supports Stripe for standalone accounts and Shopify for in-store customers. One platform, two payment providers, Plan data is internal and seeded for devs and test environments, editable in production, supports all the extra bells and whistles, and I don't need anything else fancy because remember: baseline payment requirements is "I just need to get paid", I'm not going to try to do weird unreliable projections based on Shopify's weird payment behaviors.

So… I Let Out A Sigh Of Relief

Today, we get this announcement: https://docs.heymantle.com/migrating-off-mantle/wind-down – Mantle is shutting down, end of services is in September.

I still had questioned if I made the right call, even with Claude, code costs money to maintain (even without the looming AI cost increases popping up), but with Mantle shutting down, I have no choice but to admit: we made the right choice. Porting off of this would have been a nightmare (especially in 90 days) and I feel sorry for those having to deal with this.

And… There is a Void

On the Shopify Dev Discord TeamDijon pointed out:

This causes a void
Alternatives will surface sooner rather than later

And I'm torn on the viability of filling that void. Why did Mantle decide to shut down? Did they know of some lingering change on Shopify's horizon? Did the business model not pan out to be worth the effort? Were there just greener pastures their team was drawn to? Hard to tell right now…

We'll see, but I don't feel those platforms will really be on our radar.

They're Not The Only Ones

I feel I would have stuck around if they leveraged AI to improve their platform instead of trying to add the latest AI-tooling bells-and-whistles to their product. They're not the only product that I feel ignores the thing that is actively making them money, and the vertical that could continue to make more money, to play with the hottest new fun tech stack (don't worry, we have an article about how Engineers get distracted with fun toys at the cost of your company coming up soon).

But without further ado.

Yes Just Use Postgres

The idea to write this came from a Reddit post: Why does PostgreSQL + .NET feel so much better than SQL Server these days?

Here at RoushTech we average shipping a new mainline market product about every 2 years, with smaller products dotted around, it's just how the work comes in, but regardless when it comes down to database choice we always "evaluate what our options are", then we choose Postgres, we really should cut out the middle man on this.

What About Other Engines?

OK, again keeping this fair and sticking to RDBMS platforms, let's talk about our options:

• Microsoft SQL Server - Okay, I'm going to be honest, I love MSSQL… until I have to license it. It's an extremely powerful engine, a good set of tools, some really nice failover options. Two major downsides: we've seen massive performance degradation when running on Linux due to how Microsoft got it to actually run on Linux, and secondly, the biggest one… Licensing. In the past we'd easily drop thousands or tens of thousands on licensing. It's become a major barrier. 2 months of development for an MVP or your SQL server license?
• MySQL/MariaDB - A very outdated engine, InnoDB hasn't seen meaningful improvements in forever, Oracle is effectively doing nothing with it (and no, MariaDB isn't different enough to warrant its own line), and my favorite deal-breaker in why we almost never run it. ALTER TABLE STATEMENTS ARE IMPLICIT COMMITS, that's right! When your software is running a migration, if it fails, it'll leave the DB in an invalid state because every table alter breaks out of your transaction! That's great!
• Oracle - Did you look at Microsoft's license and determine you were a glutton for punishment beyond that?
• [Insert Scale-Out DB Here] - Platforms like CockroachDB are cool, but scale-out DBs are a completely different class, complexities change a lot, design options are limited, latency floors are usually pretty high.
• SQLite - OK I love SQLite but only really great for local/embedded DBs.

OK But How Does Postgres Stack Up?

This is the wonderful part, and some of the really fun parts people miss out on:

• It's extremely performant in a lot of cases, we've shoved a ridiculous amount of traffic through it.
• You can use it as a doc store! Yeah, okay, I usually don't opt for using engines "incorrectly" but Postgres has come a long way, the ability to dig and index into JSON columns is great.
• You can beat the everliving snot out of an RDBMS if you're a half-decent engineer. We've had single-instance Postgres systems doing tens of thousands of non-trivial transactions per second, and yes, that's even after someone trots out the "well this key-value or document store can do 400k/sec" comparison everyone loves, sure, but those 400k are trivial ops on a single key or document. One non-trivial Postgres transaction is doing joins, constraint checks, and atomic writes across multiple tables. They're not the same unit and the comparison only flatters them if you pretend they are.
• Has a good amount of tuning options allowing you some decent influence on performance.
• Has a healthy extension market with a lot of additional bells-and-whistles you can add (PostGIS for spatial, pgvector for embeddings/RAG, TimescaleDB for time-series).
• The MVCC system is complex but powerful.

Where Am I Going To Get Bit?

• I've had the query planner lie to me about costs, just straight up lie, "this is cheap" then thread-spins.
• Like any RDBMS, beware of locking, a sloppy ALTER TABLE statement may be the difference between something that takes 100ms and 100 minutes (or longer). Learn how the engine allocates data.
• There are many ways to set up clusters, each with their own pros and cons.
• Postgres uses a process-per-connection model (every client connection forks its own backend OS process), which gets expensive at scale. PGBouncer is your friend, and your enemy. There is no free lunch with connection limits and port limitations, PGBouncer can make these logistics easier, but port exhaustion is still a thing.
• If you need something truly scale-out, it likely isn't here, but you should also be making $100+m/yr, why are you even here?
• Postgres is case-sensitive by default, unlike basically every other DB engine on the face of the planet. Configure case-insensitive collations on day one or you'll be patching application bugs forever.
• Run VACUUM FULL, you'll have a good time (insert massive amounts of sarcasm here). Imagine a hard drive defrag from back in the day but it locks your hard drive while doing so. MSSQL got online index rebuilds right at least, at least if you're paying for Enterprise.
• Major version upgrades can be annoying, not super bad though.

I Hate To Say It…

But yeah, just use Postgres, our options have narrowed over the years, and I agree, it's annoying, I almost feel like I'm not doing my job, but Microsoft's licensing and Oracle's lack of caring for MySQL did that for me.

So with the new site comes some major new changes, we have some new pages better describing what we do, we have some regional pages up and we'll probably have more in the future, we have a list of our projects publicly (we used to have a hidden portfolio a couple of sites ago)

One of the major changes: public pricing

Okay, but public pricing?

Along with us using Claude with a lot of our development, Claude has helped a bit with this site – Claude constantly complained "Don't put up pricing", "it doesn't allow you to drive higher margin if people know what you charge"

Yes Claude that's the point, we're not like every dev house where your pricing fits your business size (oh, you got lots of money, guess our hourly rate went up…). We work backwards from what we pay our engineers, since that's the basis that we have to clear as a business, we put a few levels of margin on top of that which represent our different discount tiers, and that's it. Nothing else special.

I mean Exhibit A of our MSA that shows our rates is basically the same for everybody (there are some edge cases where people get some slightly tweaked rate sheets but mostly driven by stability of the contract).

Weird, so why?

There is a significant number of customers that appreciate that we just shoot straight, someone asks what we think something will cost, we'll throw some numbers based on our experience, not based on me having to come back and figure out what we can squeeze them for, just honest off-the-cuff assessments of what they're trying to do.

Of course we're generally in agreement: I'm giving examples, details can drive differences, but I get a lot of "I can't get a vendor to just shoot straight with me, Will"… well we should really do that up-front too. If the pricing makes you a bit skittish, if you're unsure of how or why we do things, talk to us, I'm more than happy to discuss how this makes sense.

Or hang around for more articles. Along with industry insights, I'm planning to explain a lot of the ethos behind why we do what we do and where these systems and theories come from, some maybe more hot takes than others…

See ya around!