I think this is a great idea with the wrong pricing model. Look at all the one off payment products that involve code, they're all dead. Just charge a lower but recurring price so I can be sure that you make enough money that you keep working on it. $20/month flat price to keep the license working and source available if you shut down. If people like it and want the barebones Sentry then charge them $40 a month to provide code and host it. Wishing you the best of luck.
ONCE projects do get occasional updates. I don’t use boilerplate projects much, so I can’t speak to them.
My model isn’t a subscription. Think about it like buying rice. You might buy it every week, but that doesn’t mean you’re “subscribed” to rice.
Even if I release a new major version, you’re free not to update. And if it’s a major version, it’s fair to expect it to be paid. After all, major updates usually bring significant improvements. For example, if you played the original DOOM, you had to pay for DOOM 2 too, even though they run on the same engine.
There are so many people buying rice that's not hard for rice producers to forecast how many thousands of tons of rice they have to grow each year. And not many people look at how much they spend for rice year long. For the single box, yes, they do notice. So it's not a subscription but it looks like it is, at least from the point of view of the seller.
Yes but I don't rely on rice I bought a year ago or DOOM as a core component of my business. Trying to work around a business model (subscription saas) requires that you understand what people are buying, and often, especially with you vendors, that is a financial alignment between the two.
If you bought DaVinci Resolve several years ago, you're still able to update to 20.<whatever> and use the same licence key.
Granted they're not interested in taking 225 quid off you for a software licence, they're interested in taking 22 grand off Netflix for a complete edit desk.
That's a fair point. In my case, though, I'm a solo dev without a hardware ecosystem, so major versions help sustain development without forcing subscriptions. What do you think about models like that for indie projects?
The problem with ONCE is that software is never finished. This is why most ONCE software that is still available today is charging a one off licensing fee + update fee (e.g. charge yearly for major updates or 10% of the one off fee per year). This is sustainable, but your model isn't. You will notice down the road in 2-4 years that it's no fun to work for free for users that expect an update because it requires patching or there are breaking changes.
That’s a fair concern, but I see it differently. Software can reach a point of maturity - not “dead” just done. That’s the whole philosophy behind ONCE: build something great, maintain it responsibly, and stop when it’s complete.
https://www.reaper.fm/ uses that pricing and has... let's say fanatical following. You pay once for version X and X+1 just in case you miss out on an update coming in a month. Then you pay again for a big upgrade.
I know you said inspired, but it still feels a bit wrong to just copy paste the exact same landing page style and replace some words on it (https://once.com/campfire)
Yeah, I used it as a starting template. But beyond the layout, the copy and product are completely different. It just helped me get started faster, and I’ve always been open about that. Everything else (including the installer) is fully self-made.
> Wherever you can host something like WordPress, you can host Campfire
I’m going to be pedantic here, but this statement is not true. I host a website on a provider that allows WordPress (PHP) along with MySQL, but
> System requirements & installation
> Campfire is packed as a Docker container image
the web host provider does not allow Docker (it runs on BSD).
I’d suggest improving the system requirements section by actually stating the system requirements. To me the mention of Docker without other details is a black box that I cannot have any intuition for.
I appreciate the feedback. I’ve updated the information to remove the WordPress reference and clarified that the OS must support containerization. Thanks!
Their docs show throughput limits (e.g., 4 CPU = 60 errors/sec), but what happens during error spikes?
If my app crashes and blasts hundreds of errors in seconds, does Telebugs have built-in rate limiting or backpressure? Or do I need to overprovision hardware/implement throttling myself?
With SaaS tools, spike protection is their problem. With self-hosted, I’m worried about overwhelming my own infrastructure without adding complexity.
Hey, Telebugs creator here. Great questions! Right now, Telebugs doesn’t have built-in throttling, so during error spikes, you’d either need to handle it manually or overprovision. I do plan to add throttling in the future, similar to what Sentry does, to protect your infrastructure automatically.
Curious: for those running self-hosted error trackers in production, how do you currently handle sudden error spikes? Any clever tricks or patterns you swear by?
The company I work for runs self hosted sentry. Sentry has something that tells you that events are being dropped due to pressure. I think every engineer in the company knows that this is happening but no one fixes it because no one has the time to look into it.
Thanks for your answer! Would you mind sharing your error volume? I’m also curious, how often do dropped events happen, and how does it impact your workflow? Any workarounds you’ve tried, or features you wish were available? This will help me make sure the feature is implemented in a way that’s actually useful.
I've used it a fair bit. My biggest use was for a computer processing system that recorded gigabytes of data. If it was limited to 60 inserts per second it would have taken months to run!
I do recall having to change some settings to make it really fast, but it wasn't 60/second slow.
Appreciate the answer! You’ve probably worked with raw SQLite drivers. I’m using a framework, which likely runs more transactions by default. I’m fairly confident that with a bit of digging, I can improve the ingestion speed. Good to know and thanks for sharing your experience!
Nice. I’m curious about what kind of customers are buying your product and where did you find them. It’s difficult to compete with someone like Sentry, and even though you have a better pay model, you don’t have the reputation, so I am rather curious about your customers and why they prefer your product. Are they indie devs looking for a cheaper solution?
Thanks! I’m not really competing with Sentry itself. I’m competing with self-hosted Sentry, which is notoriously hard to install and maintain (and has steeper hardware requirements).
I'd say my customers prefer my product because:
- They want self-hosting without the maintenance burden.
- They work in regulated or internal networks.
- They’re tired of subscription pricing.
- I build it in public and post regular updates on my social media.
- They value direct support from the creator.
P.S. I’ve personally worked for a Sentry competitor, so I know the pain points firsthand.
As much as I like the ONCE idea, even 37signals have found it hard to be sustainable. I think they intend to have an improved version of ONCE idea coming out later.
Other than that I hope this project succeed. May be another idea is that you offer paid hosted model as well as the ONCE product. This is similar to a lot of OSS web analytics. People are happy to pay for subscription / services as long as they know they are not locked in. i.e They are happy to pay for $20 - even $2K per month due to Opex rather than Capex reason or saving the manual labour hassle. And they have the choice to move their data to ONCE product when they see fit.
I follow 37signals updates on ONCE, but I don’t recall them mentioning sustainability issues. Could you share a link?
Thanks for the suggestion! A hosted solution could definitely be an option. That said, some people have mentioned that having an indie dev behind it can be a turn-off. I’ll keep exploring ideas that make sense, though.
I want to vaguely recall that they had like 4 products in planning stages for ONCE, released Campfire, then released Writebook for free, and then made Campfire free.
Lately on the podcast I only hear about Fizzy and one other unannounced SAAS that they're putting dev energy behind, nothing about other ONCE products.
I suspect that without a critical mass of usage driving word of mouth the long tail of sales was basically nil, and long-term even fairly small products weren't looking to recoup dev costs any time soon.
Fizzy uses SQLite for multitenancy. I suppose that’s why it takes up so much of their time. Being a fan of SQLite, I hope this approach succeeds. P.S. I know Campfire has made “six figures”
Would love to see it added. I’m running a Flask app using raw SQLite3 without a ORM. I believe I could hack up a Span solution in Sentry to query track like:
import sqlite3
from sentry_sdk import start_span
def execute_query(conn: sqlite3.Connection, sql: str, params: tuple = ()):
with start_span(op="db", description=sql) as span:
span.set_data("db.system", "sqlite")
cursor = conn.execute(sql, params)
return cursor
Telebugs isn’t meant to be a full Sentry replacement. It focuses purely on error tracking. The goal is to avoid feature creep and do one thing exceptionally well, much like classic UNIX tools. That said, you’re not the first to ask about APM features, and it’s motivating me to consider building a separate APM product.
Telebugs creator here. GlitchTip is solid, but Telebugs is built for devs who want something lighter and faster to self-host.
It runs on plain Rails, sets up in about 5 minutes (one command), and stays snappy even on small servers. The UI is modern, minimal, and actively maintained. I keep refining it to stay fast and clean.
The biggest difference is in philosophy. GlitchTip was built by an agency. Telebugs is a solo passion project. I’ve worked on error tracking tools professionally before, and built Telebugs to reflect how I wish those tools worked.
Interesting pricing model, and it seems the pain of Sentry is getting real those days. Many folks need something simpler, that just works. Totally support the idea.
The alternative starting with a G has been mentioned a few times already, so I'll also mention that's been operating in the space and that I happily use : https://www.bugsink.com/. It's trying to solve the exact same pain.
Disclaimer : I know the owner :), so I may be biased. But generally I like to see more niche alternatives to the massive players in the field
Please don't hijack competitors' Show HNs to promote your own thing. A single mention is arguably ok, but beyond that it gets too be too much, especially when related accounts are involved or it crosses into multiple threads.
It works out because sentry has basically gone full solarwinds. Trying to get rid of the small accounts because they only care about the enterprise market anymore
I guess I’ve got a lot of resentment for when I suddenly paid for 100k reserved errors suddenly that I didn’t remember asking for. I probably figured out I have control about it at some point and that’s why I decided to not do the Schlepp of changing the error reporting on all these small projects.
So while I can actually corroborate that your cheapest plan has not changed my takeaway is that changes to billing just make people unreasonably resentful. At least me.
I think this is a great idea with the wrong pricing model. Look at all the one off payment products that involve code, they're all dead. Just charge a lower but recurring price so I can be sure that you make enough money that you keep working on it. $20/month flat price to keep the license working and source available if you shut down. If people like it and want the barebones Sentry then charge them $40 a month to provide code and host it. Wishing you the best of luck.
> Look at all the one off payment products that involve code, they're all dead.
Could you share some examples? I can’t think of any off the top of my head.
--
I really went all-in with the ONCE philosophy because it resonated with me deeply. It felt more like a passion project than cold business strategy.
I think all of the boilerplate projects you can find.
Are ONCE projects getting updates? We will find a year or two?
Your model is a subscription, we just don’t get to know when you decide to have a new major version and plan pricing / spend as a result.
ONCE projects do get occasional updates. I don’t use boilerplate projects much, so I can’t speak to them.
My model isn’t a subscription. Think about it like buying rice. You might buy it every week, but that doesn’t mean you’re “subscribed” to rice.
Even if I release a new major version, you’re free not to update. And if it’s a major version, it’s fair to expect it to be paid. After all, major updates usually bring significant improvements. For example, if you played the original DOOM, you had to pay for DOOM 2 too, even though they run on the same engine.
There are so many people buying rice that's not hard for rice producers to forecast how many thousands of tons of rice they have to grow each year. And not many people look at how much they spend for rice year long. For the single box, yes, they do notice. So it's not a subscription but it looks like it is, at least from the point of view of the seller.
Yes but I don't rely on rice I bought a year ago or DOOM as a core component of my business. Trying to work around a business model (subscription saas) requires that you understand what people are buying, and often, especially with you vendors, that is a financial alignment between the two.
If you bought DaVinci Resolve several years ago, you're still able to update to 20.<whatever> and use the same licence key.
Granted they're not interested in taking 225 quid off you for a software licence, they're interested in taking 22 grand off Netflix for a complete edit desk.
That's a fair point. In my case, though, I'm a solo dev without a hardware ecosystem, so major versions help sustain development without forcing subscriptions. What do you think about models like that for indie projects?
The problem with ONCE is that software is never finished. This is why most ONCE software that is still available today is charging a one off licensing fee + update fee (e.g. charge yearly for major updates or 10% of the one off fee per year). This is sustainable, but your model isn't. You will notice down the road in 2-4 years that it's no fun to work for free for users that expect an update because it requires patching or there are breaking changes.
That’s a fair concern, but I see it differently. Software can reach a point of maturity - not “dead” just done. That’s the whole philosophy behind ONCE: build something great, maintain it responsibly, and stop when it’s complete.
He is selling updates. You pay once for 1.x. That's a fine and okay business model that has been functioning for very long.
https://www.reaper.fm/ uses that pricing and has... let's say fanatical following. You pay once for version X and X+1 just in case you miss out on an update coming in a month. Then you pay again for a big upgrade.
I know you said inspired, but it still feels a bit wrong to just copy paste the exact same landing page style and replace some words on it (https://once.com/campfire)
Yeah, I used it as a starting template. But beyond the layout, the copy and product are completely different. It just helped me get started faster, and I’ve always been open about that. Everything else (including the installer) is fully self-made.
It's not the exact same at all.
> Wherever you can host something like WordPress, you can host Campfire
I’m going to be pedantic here, but this statement is not true. I host a website on a provider that allows WordPress (PHP) along with MySQL, but
> System requirements & installation
> Campfire is packed as a Docker container image
the web host provider does not allow Docker (it runs on BSD).
I’d suggest improving the system requirements section by actually stating the system requirements. To me the mention of Docker without other details is a black box that I cannot have any intuition for.
I appreciate the feedback. I’ve updated the information to remove the WordPress reference and clarified that the OS must support containerization. Thanks!
Their docs show throughput limits (e.g., 4 CPU = 60 errors/sec), but what happens during error spikes?
If my app crashes and blasts hundreds of errors in seconds, does Telebugs have built-in rate limiting or backpressure? Or do I need to overprovision hardware/implement throttling myself?
With SaaS tools, spike protection is their problem. With self-hosted, I’m worried about overwhelming my own infrastructure without adding complexity.
Anyone running this in production?
Hey, Telebugs creator here. Great questions! Right now, Telebugs doesn’t have built-in throttling, so during error spikes, you’d either need to handle it manually or overprovision. I do plan to add throttling in the future, similar to what Sentry does, to protect your infrastructure automatically.
Curious: for those running self-hosted error trackers in production, how do you currently handle sudden error spikes? Any clever tricks or patterns you swear by?
The company I work for runs self hosted sentry. Sentry has something that tells you that events are being dropped due to pressure. I think every engineer in the company knows that this is happening but no one fixes it because no one has the time to look into it.
Thanks for your answer! Would you mind sharing your error volume? I’m also curious, how often do dropped events happen, and how does it impact your workflow? Any workarounds you’ve tried, or features you wish were available? This will help me make sure the feature is implemented in a way that’s actually useful.
That seems like insanely low throughput. What takes it so long?
It uses SQLite as its database.
SQLite is really fast. There's no way that's the bottleneck.
What’s your experience with SQLite? It’s a bit hard to talk about performance without sharing code.
I've used it a fair bit. My biggest use was for a computer processing system that recorded gigabytes of data. If it was limited to 60 inserts per second it would have taken months to run!
I do recall having to change some settings to make it really fast, but it wasn't 60/second slow.
See the "update" in this answer.
https://www.sqlite.org/faq.html#q19
Appreciate the answer! You’ve probably worked with raw SQLite drivers. I’m using a framework, which likely runs more transactions by default. I’m fairly confident that with a bit of digging, I can improve the ingestion speed. Good to know and thanks for sharing your experience!
Nice. I’m curious about what kind of customers are buying your product and where did you find them. It’s difficult to compete with someone like Sentry, and even though you have a better pay model, you don’t have the reputation, so I am rather curious about your customers and why they prefer your product. Are they indie devs looking for a cheaper solution?
Thanks! I’m not really competing with Sentry itself. I’m competing with self-hosted Sentry, which is notoriously hard to install and maintain (and has steeper hardware requirements).
I'd say my customers prefer my product because:
- They want self-hosting without the maintenance burden.
- They work in regulated or internal networks.
- They’re tired of subscription pricing.
- I build it in public and post regular updates on my social media.
- They value direct support from the creator.
P.S. I’ve personally worked for a Sentry competitor, so I know the pain points firsthand.
This is cool; I have been watchjng this for a while and intend to use it soon.
Thank you!
As much as I like the ONCE idea, even 37signals have found it hard to be sustainable. I think they intend to have an improved version of ONCE idea coming out later.
Other than that I hope this project succeed. May be another idea is that you offer paid hosted model as well as the ONCE product. This is similar to a lot of OSS web analytics. People are happy to pay for subscription / services as long as they know they are not locked in. i.e They are happy to pay for $20 - even $2K per month due to Opex rather than Capex reason or saving the manual labour hassle. And they have the choice to move their data to ONCE product when they see fit.
All the best I hope this work out.
I follow 37signals updates on ONCE, but I don’t recall them mentioning sustainability issues. Could you share a link?
Thanks for the suggestion! A hosted solution could definitely be an option. That said, some people have mentioned that having an indie dev behind it can be a turn-off. I’ll keep exploring ideas that make sense, though.
I want to vaguely recall that they had like 4 products in planning stages for ONCE, released Campfire, then released Writebook for free, and then made Campfire free.
Lately on the podcast I only hear about Fizzy and one other unannounced SAAS that they're putting dev energy behind, nothing about other ONCE products.
I suspect that without a critical mass of usage driving word of mouth the long tail of sales was basically nil, and long-term even fairly small products weren't looking to recoup dev costs any time soon.
Fizzy uses SQLite for multitenancy. I suppose that’s why it takes up so much of their time. Being a fan of SQLite, I hope this approach succeeds. P.S. I know Campfire has made “six figures”
Does Telebugs support SQLite3 query performance tracking? E.G. top slowest queries, etc. I don't believe Sentry supports this
Nope, there are no APM features in Telebugs: https://telebugs.com/#okay-but-sentry-offers-apm
Fun fact: Telebugs itself runs on SQLite3!
Would love to see it added. I’m running a Flask app using raw SQLite3 without a ORM. I believe I could hack up a Span solution in Sentry to query track like:
Telebugs isn’t meant to be a full Sentry replacement. It focuses purely on error tracking. The goal is to avoid feature creep and do one thing exceptionally well, much like classic UNIX tools. That said, you’re not the first to ask about APM features, and it’s motivating me to consider building a separate APM product.
How does it compare to GlitchTip which is in the same space?
Telebugs creator here. GlitchTip is solid, but Telebugs is built for devs who want something lighter and faster to self-host.
It runs on plain Rails, sets up in about 5 minutes (one command), and stays snappy even on small servers. The UI is modern, minimal, and actively maintained. I keep refining it to stay fast and clean.
The biggest difference is in philosophy. GlitchTip was built by an agency. Telebugs is a solo passion project. I’ve worked on error tracking tools professionally before, and built Telebugs to reflect how I wish those tools worked.
If you’re curious, here’s a short write-up on why I built it: https://telebugs.com/why
Happy to answer any specific questions!
Is there a license for FOSS projects?
Not at the moment, but I’m open to it! If you have something in mind, feel free to email me at kyrylo@telebugs.com and we can work something out.
Interesting pricing model, and it seems the pain of Sentry is getting real those days. Many folks need something simpler, that just works. Totally support the idea. The alternative starting with a G has been mentioned a few times already, so I'll also mention that's been operating in the space and that I happily use : https://www.bugsink.com/. It's trying to solve the exact same pain.
Disclaimer : I know the owner :), so I may be biased. But generally I like to see more niche alternatives to the massive players in the field
[flagged]
Please don't hijack competitors' Show HNs to promote your own thing. A single mention is arguably ok, but beyond that it gets too be too much, especially when related accounts are involved or it crosses into multiple threads.
Also, please don't use HN primarily for promotion in general. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html.
It works out because sentry has basically gone full solarwinds. Trying to get rid of the small accounts because they only care about the enterprise market anymore
Clearly this is bait but we have done nothing but be supportive of small accounts.
It’s still $29, we still are extremely generous on forgiveness and sponsorships, and we still prioritize the long tail.
70% of our business is smb/mm, and if you knew anything about us you wouldn’t make the statement you said above.
If we have done something to show otherwise I would love to see it so we can address it.
I guess I’ve got a lot of resentment for when I suddenly paid for 100k reserved errors suddenly that I didn’t remember asking for. I probably figured out I have control about it at some point and that’s why I decided to not do the Schlepp of changing the error reporting on all these small projects.
So while I can actually corroborate that your cheapest plan has not changed my takeaway is that changes to billing just make people unreasonably resentful. At least me.
"it can deal"... with 300 events/s easily.
In this Sentry alternatives space there’s also Bugsink (https://www.bugsink.com/). Can heartily recommend it.
Yeah. Free, works, and saves my employer a ton of money after we started switching over to it.
Genuinely hope some of that money is going to Bugsink, because that's the only way we keep seeing those alternatives alive and kicking
They have a hosted, SaaS, version.
It looks like it was built on macOS and not Omarchy, is that even allowed these days? /s
Haha, true. I used to rock Arch Linux back in 2012–2015, so no need for Omarchy for me