💰 Meteor products that make money

announce
22

That is awesome @jamesmillerburgess.

Do you think Meteor helped in delivering this platform on time/budget? also did you experience major performance issues that hindered your growth?

23

So we initially had an ASP .NET application that used jQuery for client side interactivity, and I used Meteor to develop prototypes of a ‘modernized’ version of the application. It definitely made things really easy and fast and it won over our management enough to go ahead with a modernization project.

Later we made the full application and quickly jettisoned some of the unique selling propositions of Meteor (reactivity, isomorphic code) and instead used it as a build tool and used Galaxy as an easy CD solution.

After a while we started to feel that Meteor was probably not a good fit for our particular use case, especially when it came to SEO, and on the development side we suffered from long rebuild times that slowed down our front end guys.

So recently we created the new Gatsby-based application for our marketing/SEO content and once we get around to it we will migrate the app from Meteor to WebPack.

Historically, I’m one of the top contributors to the Meteor code base, so it pains me to see us leave it behind, but it really is the best decision for us. There are certain projects for which Meteor is clearly the best choice - our project just doesn’t happen to be one of them.

5 Likes
24

We’re largely using Meteor just as a build tool as well and have experimented moving off of it, but with the renewed energy into Meteor, we might be buying in a bit harder. That said our api is all GraphQL and front end is React, so we’re not exactly going to be Blazin’ with DDP or anything.

1 Like
25

I’d rather not disclose exact numbers but it’s a lot :slight_smile:

3 Likes
26

Thanks for sharing your journey @jamesmillerburgess very insightful case study.

Correct me if I’m wrong, but that product doesn’t seem to be a typical SaaS application, it looks more like an online public portal for a shipment company, perhaps that’s why an optimized public static site generator with a GraphQL API gateway and microservices backend are better fit, although Meteor development speed, it seems, was the needed catalyst to get the project approved. An ideal framework, in my opinion, would allow you to start as tightly coupled full-stack in the early stages yet has the right flexibility to decouple the clients from the API as things evolve, and I think Meteor is heading in that direction, the frontend and backend are pretty much decoupled now but you start as full-stack to ensure quick delivery.

For the re-build times, I agree, it’s a pain point especially for large React projects. The issue is that these modern front-end frameworks (React, Vue) do a lot of work on refresh, unlike Blaze (handlebars) for example. That is why those communities needed HMR, but for that, I’m rooting for the HMR API initiative by @zodern, and as I said in that thread, the community need to support that effort even fund this initiative, I think it’s critical yet solvable issue.

Lastly, you can still use Gatsby, NextJS, CRA with Meteor as a backend, we’ve several apps like that, unless of course, you’ve the resources internally to refactor and manage the backend, DevOps, and various integrations completely in-house or the appetite for vendor lock-in with things like Firebase.

But once again, thanks for your contribution and sharing your story, I think it was very insightful.

2 Likes
27

So I guess I can be more specific about why we feel Meteor isn’t a good fit for us:

  1. We don’t have a use case for reactivity, which I see as Meteor’s sweet spot
  2. We need SQL support (hence we use Apollo GraphQL rather than Meteor methods)
  3. Our enterprise data is spread across multiple sources and we can’t change this (again a reason to use GraphQL)
  4. We have to host some services on internal infrastructure
  5. We have to support hosting in China (www.shipafreight.com.cn), as it is a major market for us - right now we use AWS China CloudFront for edge networking, but then our Galaxy deployment is still outside China, which significantly impacts performance
  6. We use a monorepo with several non-Meteor packages, but we can’t find a way to make this work with lerna or yarn workspaces. So we are using yalc at the moment, but this has other compatibility issues and complicates our CI setup
  7. Running the complete dev environment is now a strain on even the fastest of hardware, and Meteor is taking up the most resources and causing long rebuild times

Ultimately our project has gotten so big that we have a lot of particular needs requiring custom setup beyond what Meteor supports. We have the resources to configure WebPack and a CD pipeline and feel that the cost of having to do these ourselves is outweighed by alleviating other pain points.

6 Likes
28

Got it, it makes more sense now. I do agree that for your specific use-case (not a typical SaaS, a global public portal for an enterprise) and at that stage/scale of your project, the refactoring and having an API gateway with full control over the server in-house might enable more growth down the road.

I think Meteor is a better fit for entrepreneurs and SaaS developers where the resources/timelines are tight and there is more control over the data sources and scope (like the thread authors making a sum of $110k/month with two developers), basically, it’s better fit for hobbyists, indie hackers, academics, newcomers, startup founders, bootstrapped business, small teams as oppose to large enterprise projects and MDG knew that and wanted to appeal to enterprises hence Apollo, but I think TinyCapital is reaching out to the right audience, and with support for all major view layers, correct marketing and valid Galaxy pricing/features, Meteor will grow.

Congrats on the successful journey and I personally would be very curious to read a blog about the migration effort and insights as well once you reach the other side, I think it’ll help to make Meteor better.

2 Likes
29

https://www.playfactile.com - It’s making money and completely developed using Meteor with blaze. We are continuously enhancing it from last 2.5 years. Recently added option to play the games remotely which is proving very helpful in getting new customers.

4 Likes
30

https://rocket.chat/ - did not count their money but I think (hope) they are still on Meteor.

Good choice for a team chat, BTW.

4 Likes
31

There is Classcraft as well, I think they’re more relevant than ever with the ongoing quarantine.

2 Likes
32

I know of 2 that I know are making money:

1 Like
33

www.insidesherpa.com and www.sunsama.com are both YC companies built on Meteor! Give them both a check!

3 Likes
34

At Join It, we provide membership management software, and we just crossed $40,000/month

I’ve been working on the product for over 4 years now, and I taught myself how to code using Meteor!

While our product certainly could have been built using other stacks, Meteor’s helped me get to a shipped MVP very quickly and that kept me going (I had previous false starts with Ruby on Rails).

And currently, we use Meteor, mongodb, and Blaze.

Our B2B SaaS customers care about the utility that we provide and we’re often replacing a very manual process (tracking Memberships in an excel file) – so they obviously don’t care about the stack that we’re built on as long as the software helps them get their tasks done.

10 Likes
35

I was unable to get Meteor working with any kind of mono repo setup using lerna too. I think that would make a really nice example if someone has it working well.

36

We use yalc, and have preinstall scripts to update the packages and copy the folders in locally when there are dependencies between local packages. Here is an example:

"preinstall": "yarn --cwd ../sf-ui setup && yarn --cwd ../sf-shared setup && npx yalc add sf-ui sf-shared",

But there are a lot of gotchas that we have had to work through with this setup, and doing a yarn install at root has turned into a long recursive reinstall in many folders. :sweat_smile:

37

Great to see all the cool projects here. Very inspiring! :clap:

At Lytesoft we’ve been using Meteor for almost 5 years. I knew little of web development before it but was up and going with Meteor really fast.

We’ve used it to build 2 products which have basically plateaued at the “paying our wages” stage but the focus over the coming months is going to be sales so hopefully we can improve on that. Both are using plain vanilla Meteor + Blaze.

  • Obit - Software for Funeral Directors
  • Sonas - a CRM for Events Managers (still in the process of making a landing page).
2 Likes
38

At Planable we also use Meteor for about 5 years, and it’s been a perfect fit for us. We are a small team and profitable (50K/month revenue). We serve some of the world’s biggest brands and organizations.

What has been great for us:

  • Real-time data handling built-in (still the best option imho to this date), especially for collaborative apps.
  • Backwards compatibility has been super important and painless over the years, we started with Meteor 1.1 & Blaze. Now we run latest Meteor, TypeScript and React.
  • (Evolving) build system that takes care of everything so we don’t have to bother.
  • Galaxy - painless deployments and DevOps.
  • APM - finding issues early and monitor performance
  • Accounts system that is super easy to setup and supports a wide variety of integrations

What we are (still) having issues with:

  • HMR for React, we do a lot of UI development and even though the rebuilds are fast in the latest versions, we still waste a lot of time.
  • Scaling issues (CPU Spikes) due to tailing the Oplog
  • Abandoned packages that we relied on and were a pain to migrate off.
9 Likes
39

This is great btw Costs less than a PR crisis :slight_smile:

40

What do you use for this?

41

At Campus Skills we use Meteor for about 5 years and I cannot find any alternative that will make it possible ( I am a solo developer ).

What I like :

  • PubSub : so easy to just call a method and have the data updated immediately inside your app thanks to a previous publication. In term of demo for customers this is a crazy feature. As things appear on their screen while you talk.
  • Ability to share code between client and server : this is really a key feature for us and save some time and avoid duplicate logic easily without writing shared npm package.
  • I love a simple it is with simpl-schema and uniforms to add forms.
  • APM with monti APM : so easy to set up and great insights
  • Ability to have package that is integrated up to the Database, for example all collection hooks package, you just add so much value with one command.

What can be improve :

  • Build time, especially for UI dev. I start a project with storybook but because of meteor import at some point it is impossible to maintain.
  • Marketing/opinion for outside world : I find it hard sometimes to convince people to still start a project with Meteor ( I do some consulting also ). It is not in the hype right now compare to Vercel and static websites more generally.
  • Really waiting for a more suitable price for galaxy ( after using it for more than three years ), I have switch to wavehosting which is a wrapper aroud mup beanstalk I guess.
6 Likes